[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freetype-devel
Subject:    Re: [ft-devel] Skia, IDEF, GETVAR and GETDATA
From:       Werner LEMBERG <wl () gnu ! org>
Date:       2016-07-27 4:13:43
Message-ID: 20160727.061343.779894223313438937.wl () gnu ! org
[Download RAW message or body]


> So I noticed that Skia.ttf has an IDEF for 0x91 in the fpgm table -
> how does that impact recent work on GX fonts?

You get better hinting for Skia if the interpreter supports the 0x91
opcode natively.

> - having an IDEF for 0x91, and actually use opcode 0x91 differently
> depending on circumstances.

Well, Skia uses IDEF as defined in the standard, that is, providing a
dummy version for 0x91 if the interpreter misses support for this
opcode.

> 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.

It shouldn't trigger errors but warnings only.  For Skia, the warning
can be safely ignored since the IDEF does the `right' thing.  For
LaoXX.ttf, the font developers should add a note to the documentation
that the fonts won't work as expected on Macs.  At least with recent
versions of FreeType, however, they will work fine because the 0x91
opcode is active only for GX fonts – no idea whether this is the case
on Macs also.

> How does Skia.ttf behave on windows? presumably the 0x91 IDEF within
> still push/pop the right number of arguments like the GETVAR
> instruction?

Yes, I think so.


    Werner
_______________________________________________
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

[prev in list] [next in list] [prev in thread] [next in thread]