[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?
- [ft-devel] Skia, IDEF, GETVAR and GETDATA,
Hin-Tak Leung <=