Dear Derek,
Thank you very very much for finding new tricky font!
I will commit your patch soon.
Regards,
mpsuzuki
Derek B. Noonburg wrote:
> After some more investigation, this appears to be a simple case of a
> different version (or modification?) of a known tricky font.
>
> There are three font subsets in that PDF file. All three have the same
> cvt, fpgm, and prep checksums. The cvt and prep checksums match
> DFKaiShu, but the fpgm checksum and length are different.
>
> I'm attaching those three fonts.
>
> And here's a patch:
>
> *** freetype-2.6.2/src/truetype/ttobjs.c 2015-11-28 10:08:52.000000000
> -0800
> --- freetype-2.6.2b/src/truetype/ttobjs.c 2016-01-18 11:15:37.982092742
> -0800
> ***************
> *** 246,252 ****
> tt_check_trickyness_sfnt_ids( TT_Face face )
> {
> #define TRICK_SFNT_IDS_PER_FACE 3
> ! #define TRICK_SFNT_IDS_NUM_FACES 17
>
> static const tt_sfnt_id_rec sfnt_id[TRICK_SFNT_IDS_NUM_FACES]
> [TRICK_SFNT_IDS_PER_FACE] = {
> --- 246,252 ----
> tt_check_trickyness_sfnt_ids( TT_Face face )
> {
> #define TRICK_SFNT_IDS_PER_FACE 3
> ! #define TRICK_SFNT_IDS_NUM_FACES 18
>
> static const tt_sfnt_id_rec sfnt_id[TRICK_SFNT_IDS_NUM_FACES]
> [TRICK_SFNT_IDS_PER_FACE] = {
> ***************
> *** 270,275 ****
> --- 270,280 ----
> { 0x5A30CA3BUL, 0x00009063UL }, /* fpgm */
> { 0x13A42602UL, 0x0000007EUL } /* prep */
> },
> + { /* DFKaiShu2 */
> + { 0x11E5EAD4UL, 0x00000350UL }, /* cvt */
> + { 0xA6E78C01UL, 0x00008998UL }, /* fpgm */
> + { 0x13A42602UL, 0x0000007EUL } /* prep */
> + },
> { /* HuaTianKaiTi */
> { 0xFFFBFFFCUL, 0x00000008UL }, /* cvt */
> { 0x9C9E48B8UL, 0x0000BEA2UL }, /* fpgm */
>
> - Derek
>
>
> On 2016 Jan 17, suzuki toshiya wrote:
>> 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
