Re: [ft-devel] gamma correction and stem darkening

[suzuki toshiya]

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
>>> address@hidden
>>> https://lists.nongnu.org/mailman/listinfo/freetype-devel