Re: [ft-devel] [FYI] MingLiU identifier

[mpsuzuki]

Dear Werner,

Attached is a patch detecting tricky fonts
by the combination of cvt/fpgm/prep tables
(as a fallback for nameless font in PDF),
by hardwired blacklist, no change in public
API. The increase of the code size by this
patch is about 2K bytes (-g -O2). This is
acceptable size?

Regards,
mpsuzuki

On Mon, 22 Nov 2010 13:48:01 +0900
address@hidden wrote:
>If further discussion is needed, I will remove the code
>for FT2-client to manipulate the blacklist, and commit
>MingLiU identification by hardwired blacklist with sfnt
>table tag/length/checksum.
>
>Regards,
>mpsuzuki
>
>On Wed, 17 Nov 2010 22:41:10 +0900
>address@hidden wrote:
>
>>On Wed, 17 Nov 2010 07:55:17 -0500
>>David Bevan <address@hidden> wrote:
>>>> In general scope, I think, you raised a concern that
>>>> the checksum in TTF header is too simple (it's a sum
>>>> of 32-bit values of the table) to guarantee the identity.
>>>> It's reasonable.
>>>
>>>My concern is that the (small) tables may actually be
>>>the same in a variety of fonts.
>>
>>Ah, I see. Your concern is not the conflict of the
>>checksum (or other hash value), but the conflict of
>>the table itself. To identify more correctly, other
>>tables (that are preserved in the subsetting) should
>>be compared... I'm understanding correctly?
>>
>>>> If I check the fonts bundled to Microsoft Windows,
>>>> Mac OS (Classic & OS X), and distributed in GNU/Linux
>>>> distribution and I find no conflict, is it sufficient
>>>> guarantee? 
>>>
>>>That seems reasonable.
>>
>>OK, I will try.
>>
>>>> If not, I cannot access wider coverage
>>>> of the fonts, so, the possible solution would be...
>>>> 
>>>> 1) identify by family name comparison is used too,
>>>>    and add a fallback by sfnt table checksum.
>>>> 
>>>> 2) in addition to the tag-name of the table and
>>>>    the checksum, the length should be checked.
>>>>
>>>> 3) if it's still insufficient... should we use
>>>>    our own hash value instead of the checksum
>>>>    in sfnt header.
>>>
>>>Only 1) would address my concern.
>>
>>1) is already implemented in my proof of concept patch.
>>
>>http://lists.nongnu.org/archive/html/freetype-devel/2010-08/msg00019.html
>>
>>Regards,
>>mpsuzuki
>>
>>_______________________________________________
>>Freetype-devel mailing list
>>address@hidden
>>http://lists.nongnu.org/mailman/listinfo/freetype-devel
>

mps20101122b.diff.rz
Description: Binary data