[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ft-devel] New Infinality Release

From: Infinality
Subject: Re: [ft-devel] New Infinality Release
Date: Mon, 17 Dec 2012 11:04:11 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0

Have you actually done binary searches in TTFs to find signatures?
Well, only using the code here, not with a hex editor. I have seen hits in some TTF files where I would not have expected them. May speak to the issues you mentioned below.

Given that the new ttfautohint bytecode signature is that short, as
are some other snippets in Greg's whitepaper, I think it is best if
you extend the code so that the function number is also checked to
avoid false hits.

Yes, this makes sense for functions where we know the number, such as ttfautohint and 0. But, I think the whitepaper states that on (at least some) functions, the number varies, which is why you need the detection code in the first place. In practice, I haven't seen many (if any) of the disabled functions have an impact (probably due to the fact that they are making calls to things like SHPIX that are already "fixed" by my code. So, we can probably disable some of the checks if necessary, however I know the ttfautohint check needs to be there. I'll add one for the new ttfautohint too.

Regarding the problems with the opcode patterns, what did you see that was incorrect? From scanning them (quickly) it seemed like it was mostly correct (perhaps missing the end IF, etc.) I will take a look. Thanks for looking into that and cleaning it up.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]