freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[ft-devel] Skia, IDEF, GETVAR and GETDATA


From: Hin-Tak Leung
Subject: [ft-devel] Skia, IDEF, GETVAR and GETDATA
Date: Tue, 26 Jul 2016 23:55:59 +0000 (UTC)

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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]