Proposals for usWeightClass | usTypoWeightClass

[Levantovsky, Vladimir]

Dear all,

I am preparing the input contribution to the next MPEG meeting (held Feb. 22-26) where I will summarize all the proposed amendments including updates to “Feature descriptions” suggested by John Hudson and Ken Lunde, and clarifications and corrections suggested by Sairus in his email below. Among the suggested changes – there were two options proposed for AHG consideration on how to overcome issues 2 and 3 identified in the email. I’d appreciate your input on what the preferred solution (either defining a new version of the OS/2 table with the additional “usTypoWeightClass” field or using a new flag in the unused portion of the “fsSelection” field, as outlined below) should be.

I plan to finalize the draft input contribution for your review today, and would appreciate you input on this matter. Sairus, if you have any additional information (or your personal preferences) that you would like to communicate to the group, please do so.

Thank you very much,
Vladimir


From: mpeg-OTspec at yahoogroups.com [mailto:mpeg-OTspec at yahoogroups.com] On Behalf Of Sairus Patel sppatel at adobe.com [mpeg-OTspec]
Sent: Thursday, November 19, 2015 8:33 PM
To: mpeg-OTspec at yahoogroups.com; opentype-list at indx.co.uk
Subject: [mpeg-OTspec] Proposals for usWeightClass | usTypoWeightClass





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/20160212/68892dcb/attachment.html>