Dear Derek, I have not expected that the tricky font detection technique was still worthful to discus after the expiration of bytecode interpreter patent :-)
I'm interested in the example which current detection cannot detect correctly. The current detection is just a comparison with the checksums of "known" tricky fonts, and, if there is yet another tricky font, it should be appended the the blacklist. Regards, suzuki toshiya Derek B. Noonburg wrote: > On 17 Jan, Werner LEMBERG wrote: >>> Unfortunately, I don't think it will be possible to detect the >>> tricky fonts. >> I think it *is* possible. The method, as implemented by Toshiya-san, >> compares various SFNT table checksums. Among them is the `cvs ' >> table, and modifying this table is essentially impossible without >> interpreting and changing the bytecode. Ditto for `fpgm'. I dare to >> say that even a subsetted font with a single glyph contains the >> original `cvs ' and `fpgm' tables unmodified, which should enable >> FreeType to discover its trickyness. >> >> Do you have counterexamples to this assumption? > > Very interesting... I wasn't aware that FreeType used that technique. I > just looked through the code and found tt_check_trickyness_sfnt_ids -- I > assume that's the code you're referring to. I didn't trace through the > code; do I need to do anything special to enable those checksum tests? > > I have at least one PDF file with Chinese TrueType fonts that render > correctly with the native hinter and incorrectly without it. I'll > extract those fonts and see what the cvt and fpgm tables look like. > > I'll also be happy to make the fonts available for testing. > > - Derek > > > _______________________________________________ > Freetype-devel mailing list > Freetype-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/freetype-devel _______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
