Proposals for usWeightClass | usTypoWeightClass

[Sairus Patel]

There are several aspects of OS/2.usWeightClass http://www.microsoft.com/typography/otspec/os2.htm#wtc that have been problematic for many years now:


1. Granularity: Only 9 values are listed (though other values aren’t explicitly prohibited). A finer granularity is desired in order to express the full richness of typographic weight variance. Note that the CSS4 draft https://drafts.csswg.org/css-fonts-4/ allows font-weight values in the range [1..999].


2. “GDI skewing”: Values < 250 are sometimes set to 250 by the font designer to avoid GDI synthetic emboldening. Other issues with weight class on the upper limit and with style linking may be involved as well. See https://rawgit.com/adobe-type-tools/afdko/master/FDK/Technical%20Documentation/WinWeights.html, which may be a bit dated, but much is still valid. Also see John Daggett’s post: https://lists.w3.org/Archives/Public/www-style/2015Jan/0076.html.


3. Sometimes an OS or font engine will not trust the weight class values (perhaps in part, because of #2 above) & resort to heuristics. Mozilla has reported that Apple uses heuristics & doesn’t seem to use the recorded weight class (see John’s post above).


I propose the MAIN PROPOSAL below, which addresses issue #1.


I seek feedback on the POSSIBLE ADDITIONAL PROPOSAL and its VARIANT below, which address issues #2 and #3: are these issues worth solving, & is this the best way to do it?



=== MAIN PROPOSAL (addresses issue #1):


{ Add this clarification to usWeightClass, to the end of the “Description” section: }


Only values from 1–999 are valid.


{ Add this clarification to the start of the “Comments” section of usWeightClass, before the table: }


There may be legacy platform limitations on certain usWeightClass values. The following are commonly set values:



=== POSSIBLE ADDITIONAL PROPOSAL to also address issues #2 and #3:


{ Bump OS/2 version to 6. Add this new field to the end of the table: }


usTypoWeightClass

Format: USHORT

Description: Typographic weight class. Only values of 1–999 are valid. Common values are as listed in the table for the usWeightClass field. The usWeightClass field may have been historically set in some fonts inaccurately, to work around various legacy platform-specific limitations. usTypoWeightClass is free from platform limitations and reflects the true visual weight of the font.


=== VARIANT of POSSIBLE ADDITIONAL PROPOSAL:


Another way to address #2 and #3 instead of a new usTypoWeightClass field:


We could add a  one or more flags to OS/2.fsSelection to indicate, for example, that usWeightClass of 250 really means a weight class of 100. The problem with this approach is that several such flags may be needed since several such values have been distorted (100, 200, perhaps some in the upper range as well), & a mapping needs to be agreed upon e.g. 250 => 100, xxx => 200, … It would be a font and font engine change anyway, so we may as well make it explicit, following the model of the sTypoAscender & similar fields.


===


Sairus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20151120/cdb42158/attachment.html>