Was testing the macintosh build of Font Validator 2.0 - finally! -, and comparing with 1.0 (i.e. the older binary-only Font Validator) and etc, and of course an interesting candidate to test is the Skia font on the mac...
So I noticed that Skia.ttf has an IDEF for 0x91 in the fpgm table - how does that impact recent work on GX fonts? This sounds like "have your cake and eat it too" - having an IDEF for 0x91, and actually use opcode 0x91 differently depending on circumstances. The FV 1.0 behavior (or the MS rasterer) is rather inconsistent - it seems to both know that 0x91 is reserved, and let people define IDEF 0x91. Skia.ttf, LaoUI.ttf, LaoUIb.ttf all triggers two sets of errors: one about IDEF re-using reserved op-codes, and another about Apple-only instructions. I have not noticed the two sets of errors are talking about the same thing, as the errors for IDEF re-using opcode happens when it is defined, while the error for apple-only instructions happens when it is used; and the two have different offsets. FV 2.0 does things properly, and didn't implement the former (i.e. 0x91 0x92 isn't reserved). I think I should go and do that though, as IDEF 0x91/0x92 is bad, and if one gets two sets of errors, sounds great... How does Skia.ttf behave on windows? presumably the 0x91 IDEF within still push/pop the right number of arguments like the GETVAR instruction? _______________________________________________ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
