Re: [ft-devel] A few more problematic fonts

[Hin-Tak Leung]

------------------------------
On Thu, Nov 21, 2013 05:44 GMT Werner LEMBERG wrote:

>
>> You already fixed this one - this was the one with the long path for
>> ftdump.  Thanks.  128 Bytes was really too low - only windows CDs
>> have 128 unicode char limit these days... I think linux's is at
>> least 1024 bytes.
>
>Ok, changed to 1024.

I googled it - the proper posix way 
(http://pubs.opengroup.org/onlinepubs/009695299/basedefs/limits.h.html)
is to run "getconf PATH_MAX /", and on my current system (fedora 19 x86_64)
returns 4096!

>> I found that this font seems to have bad embedded bitmap - [...]
>
>Thanks, will check that.
>
>> I can send you the font itself - it is 19MB, but bzips to 6.3MB so
>> just about e-mailable if you wants it.
>
>Please do!

I'll send that private, to follow.

>> With the latest code, I found that one needs hinting ON and
>> anti-alias OFF for the glyphs to look correct.  Hope this helps.
>
>Hinting ON is a necessary requirement, since FreeType's auto-hinter
>doesn't apply TrueType hinting before auto-hinting the font -- note
>that ftview contains special code to circumvent the check for `tricky
>fonts'; normally, the rendering would be correct out of the box.
>
>Anti-alias OFF makes it work, right.  Switching to the v35 bytecode
>interpreter (key `H' in recent ftview versions) makes it work, too,
>thus my request for Infinality's help.

Yes, with git HEAD, v35 works, v38 breaks (while anti-alias ON). Anti-alias
OFF also works. I assume v38 is newer and still work-in-progress?

Earlier - well, the system ftview, which is 2.5.0.1 - doesn't toggle to 
anything,
and its v35 does not work.