These are chat archives for caryll/otfcc

4th
Apr 2017
Cosimo Lupo
@anthrotype
Apr 04 2017 09:00
@be5invis you said that "the spec said that any length >= 0x8000 means the length should be predicted from context", but at least from the snippet you quoted it only says "If the length stored in the record is 32768 (0x8000), then..." and does not say anything about it being > 0x8000.
Belleve Invis
@be5invis
Apr 04 2017 09:01
well it is a fallback
Cosimo Lupo
@anthrotype
Apr 04 2017 09:02
i would say it's undefined, and should probably be rejected as invalid
Cosimo Lupo
@anthrotype
Apr 04 2017 09:39
and what happens if nextTableOffset < textOffset? You get a negative length?!
Belleve Invis
@be5invis
Apr 04 2017 09:41
The entries must be in glyphIndex order and textOffset order—except for the magic number entry.
Cosimo Lupo
@anthrotype
Apr 04 2017 09:41
excellent, thanks
is there any predefined order for the last four extra programs? because, fonttools was relying on the fact that fpgm is always the last, but apparently that's not always the case. At least not from the TSI tables generated by VTT 6.20 after running the Light Latin Autohinter
both fonttools and otfcc writes the four program in this order: PREP, CVT, RESERVED and FPGM
which reflects the order of their ids: 0xFFFA, 0xFFFB, 0xFFFC and 0xFFFD
Belleve Invis
@be5invis
Apr 04 2017 09:45
"in glyphIndex order" means that for extra entries they should also be ordered.
Though when reading, OTFCC only requires that textOffset is ordered and extra is after normal.
Cosimo Lupo
@anthrotype
Apr 04 2017 09:45
thanks
and that allows otfcc to properly handle the case when the extra programs are not sorted by id
as in the case of this tables generated by VTT 6.20, which have the extra indexes as following
[('ppgm', 2470, 97618), ('fpgm', 32768, 100088), ('cvt', 5003, 191976), ('reserved', 0, 196980)]
I wonder why they changed that, that assumption was working fine with earlier VTT versions
Belleve Invis
@be5invis
Apr 04 2017 09:48
OTFCC does not have any support for Polymorphics
i.e. VF.
supporting that requires some refactor, especially replacing all pos_t (currently a double) with some data structure.