These are chat archives for caryll/otfcc

3rd
Apr 2017
Cosimo Lupo
@anthrotype
Apr 03 2017 15:39
hey Belleve! I was wondering how did you manage to write table parsers/compilers for the VTT private tables (TSI0, TSI1, TSI2, TSI3 and TSI5) for otfcc? They somehow differ from the ones in fontTools, for which Just van Rossum (the original author of fontTools) said there was no specification, and he could not remember how he wrote that stuff more than 15 years ago...
I just hit a bug with the fonttools implementation of TSI* tables, and noticed that otfcc works fine with this VTT font of mine. Do you have have any document or specifications that you can share with us, besides the C source code?
Belleve Invis
@be5invis
Apr 03 2017 15:52
I have an internal doc. Greg Hitchcock gave me that.
Cosimo Lupo
@anthrotype
Apr 03 2017 15:52
hmm interesting...
Belleve Invis
@be5invis
Apr 03 2017 15:54
you forgot that i recently started work for MS. for some asian project
Cosimo Lupo
@anthrotype
Apr 03 2017 15:54
ah! good for you :)
Cosimo Lupo
@anthrotype
Apr 03 2017 17:35
@be5invis there's one thing I don't understand about otfcc' TSI table reader. (Although this situation is unlikely) what happens if the last of the glyph programs in the TSI0/1 -- i.e. the one immediately before the magic gid 0xFFFE that separates glyph programs from the last four extra programs (prep, cvt, "reserved" (0xFFFC) and fpgm) --, has a length >= 0x8000 ? Would it then be assumed to have textLength = predictedTextLength = len(data) - textOffset? In other words, would it eat up the rest of the TSI1 table, including any remaining extra programs?
Belleve Invis
@be5invis
Apr 03 2017 17:38
Yes, it will. This behavior is described in the Spec.
Cosimo Lupo
@anthrotype
Apr 03 2017 17:38
also, if textLength == 0x8000 has a special meaning (i.e. compute current entry's length by subtracting nextOffset - currentOffset), is a textLength > 0x8000 even valid?
hm.. it doesn't make much sense to me, but if you say so
Belleve Invis
@be5invis
Apr 03 2017 17:41
The spec said that any length >= 0x8000 means that the length should be predicted from the context.
Cosimo Lupo
@anthrotype
Apr 03 2017 17:42
ok, thank you for clarifying that! Hey @behdad, when we are in Berlin, could we ask some MS guy to give us a copy of that TSI tables spec? :P
Belleve Invis
@be5invis
Apr 03 2017 17:49

• If the length stored in the record is less than 32768, then the actual length is the length noted in the record.
• If the length stored in the record is 32768 (0x8000), then the actual length is computed as follows:
• For the last “extra” record (the very last record of the table), the length is the difference between the total length of the TSI1 table and the textOffset of the final record.
• For the last “normal” record (the last record just prior to the record containing the “magic number”), the length is the difference between the textOffset of the record following the “magic number” record and the textOffset of the last “normal” record.

• For all other records with a length of 0x8000, the length is the difference between the textOffset of the record in question and the textOffset of the next record.

quote

Cosimo Lupo
@anthrotype
Apr 03 2017 17:49
thank you!
Belleve Invis
@be5invis
Apr 03 2017 17:50
the code infers the length of the last "normal" record as the difference of the first "extra" record's offset and its own offset

the

uint32_t predictedTextLength = textPart.length - textOffset;

is just a fallback option for the last Extra.

blob
@anthrotype but why are you caring about them?
Belleve Invis
@be5invis
Apr 03 2017 17:55
making TTFAUTOHINT to support VTT?
Cosimo Lupo
@anthrotype
Apr 03 2017 18:37
Why do we care? Because at DaMa we still do manual TrueType hinting using VTT, and use fonttools to dump/merge the VTT sources as xml (the VTT own xml export option does not dump the full data).