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

[Derek B. Noonburg]

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
>

fonts.zip
Description: Zip archive