Note above that the relative ordering of Thin/Ultralight is different. semilightĪs I recall from past bugs, Apple is doing something similar to what DirectWrite does, it's looking at the style name to classify the weight (mainly due to all the crazy remapping that's used to avoid synthetic bold under GDI). the usWeightClass value).įrom the Microsoft OS/2 table description for usWeightClass:ĥ. I think the Thin/Ultralight problem may be related to the scale that Apple uses, which is not precisely the same at the OpenType scale (i.e.
(fontlist) added (Avenir-HeavyOblique) to family (Avenir) with style: italic weight: 800 stretch: 0 (apple-weight: 11 macTraits: 00000003)Īrgh, looks like there's some wacky weight mapping within appkit, theīook and Roman faces have matching weights! Same for the Black/Heavy (fontlist) added (Avenir-BlackOblique) to family (Avenir) with style: italic weight: 800 stretch: 0 (apple-weight: 11 macTraits: 00000003) (fontlist) added (Avenir-Heavy) to family (Avenir) with style: normal weight: 800 stretch: 0 (apple-weight: 11 macTraits: 00000002) (fontlist) added (Avenir-Black) to family (Avenir) with style: normal weight: 800 stretch: 0 (apple-weight: 11 macTraits: 00000002) (fontlist) added (Avenir-LightOblique) to family (Avenir) with style: italic weight: 200 stretch: 0 (apple-weight: 3 macTraits: 00000001) (fontlist) added (Avenir-MediumOblique) to family (Avenir) with style: italic weight: 600 stretch: 0 (apple-weight: 7 macTraits: 00000001) (fontlist) added (Avenir-Oblique) to family (Avenir) with style: italic weight: 400 stretch: 0 (apple-weight: 5 macTraits: 00000001)
(fontlist) added (Avenir-BookOblique) to family (Avenir) with style: italic weight: 400 stretch: 0 (apple-weight: 5 macTraits: 00000001) (fontlist) added (Avenir-Light) to family (Avenir) with style: normal weight: 200 stretch: 0 (apple-weight: 3 macTraits: 00000000) (fontlist) added (Avenir-Medium) to family (Avenir) with style: normal weight: 500 stretch: 0 (apple-weight: 6 macTraits: 00000000) (fontlist) added (Avenir-Roman) to family (Avenir) with style: normal weight: 400 stretch: 0 (apple-weight: 5 macTraits: 00000000) (fontlist) added (Avenir-Book) to family (Avenir) with style: normal weight: 400 stretch: 0 (apple-weight: 5 macTraits: 00000000) Result: a logfile listing all fonts on the system This can be done with the built-in logging, no need for extra patches!Ĭd /Applications/Firefox.app/Contents/MacOSĮxport NSPR_LOG_FILE=/path/to/fontlist.out > # HelveticaNeue-CondensedBlack: appkit weight 11, css weight 800 > # HelveticaNeue-CondensedBold: appkit weight 9, css weight 700 > # HelveticaNeue-BoldItalic: appkit weight 9, css weight 700 > # HelveticaNeue-Bold: appkit weight 9, css weight 700 > # HelveticaNeue-UltraLightItalic: appkit weight 2, css weight 100 > # HelveticaNeue-ThinItalic: appkit weight 3, css weight 200 > # HelveticaNeue-LightItalic: appkit weight 3, css weight 200 > # HelveticaNeue-MediumItalic: appkit weight 7, css weight 600 > # HelveticaNeue-Italic: appkit weight 5, css weight 400 > # HelveticaNeue-UltraLight: appkit weight 2, css weight 100 > # HelveticaNeue-Thin: appkit weight 3, css weight 200 > # HelveticaNeue-Light: appkit weight 3, css weight 200
> # HelveticaNeue-Medium: appkit weight 6, css weight 500 > # HelveticaNeue: appkit weight 5, css weight 400 (catching up on reviews) from comment #13) But given that Light and Thin are apparently indistinguishable even at the appkit level, the problem here is not just with our mapping.)ĪFAICT, the best chance of fixing this - provided the OS/2 tables actually have correct, distinct weight values in them! - is probably to scrap our reliance on the appkit descriptors, and instead read the font table directly. On my 10.7 system, at least, HelveticaNeue-Light has an OS/2 weight of 300, but we end up mapping its appkit weight of 3 to 200 for CSS, which seems somewhat broken to me.
(I'd still be curious to know what's in the weight field of the OS/2 table of those fonts, if someone with FontForge would be willing to take a look. Which one you get is essentially arbitrary it probably depends on either the alphabetical order of their names, or the order they happen to get enumerated by NSFontManager, I forget exactly. This explains the behavior here: the Light and Thin faces are ending up with identical properties in CSS terms, and so we can't distinguish between them on the basis of CSS font-weight.
Avenir loopcad invalid signature series#
Book series (LNCS, volume 10159) AbstractĪt PKC 2006, Chevallier-Mames, Paillier, and Pointcheval proposed a very elegant technique over cyclic subgroups of \(\mathbb )\).Ugh - note how the HelveticaNeue-Light and -Thin faces are showing the SAME value for "appkit weight", which is the value the Cocoa font manager reports to us.
0 kommentar(er)
