Re: ttfautohint's functionality from the removal of the infinality patch
> As long as v38 is different from v40, some part of it is closer than v40 to > MS/Apple's. Also fact. Also.. You are making it sound like we are handicapping FreeType. Then Phoronix or Slashdot will sensationalize it. OMG! OMG! OMG! Major FreeType regression! This is FUD! This is zero evidence that v40 is worse, Yes. I assert for you (and beating Phoronix to it): v40 has been the default for SIX YEARS and it is good!
Re: ttfautohint's functionality from the removal of the infinality patch
> "Better" is your personal opinion. Anyway, I think some of others' "personal > opinion" (different from yours) is simply based on familiarity - some people > are just more familiar with MS/Apple rendering, and therefore prefer it. In > the end of the day, FreeType is not MS/Apple font scaler. Fact. > > As long as v38 is different from v40, some part of it is closer than v40 to > MS/Apple's. Also fact. Not necessarily! This might be different in the opposite direction. The "fact" that v38 is closer to Microsoft has to be shown. Also, replication of Microsoft was *never* stated as an Infinalit goal. BTW https://github.com/pdeljanov/infinality-remix ... still no mention of Microsoft as gold standard. I am just saying what I know: Infinality was never *closer* to Microsoft than v40.
Re: ttfautohint's functionality from the removal of the infinality patch
On Friday, 25 August 2023 at 05:38:14 BST, Alexei Podtelezhnikov wrote: > Infinality (v38) was substituted by v40 in 2.13.1. Anybody requesting > v38 got v40 instead... and nobody even noticed. That is the whole > point of the exercise: v40 is perfectly capable and better than just > good enough. Now the code is physically gone for good. It is much > better to improve faster and lighter v40 moving forward than dwelling > on unmaintained, poorly understood, and riddled with exceptions v38. "Better" is your personal opinion. Anyway, I think some of others' "personal opinion" (different from yours) is simply based on familiarity - some people are just more familiar with MS/Apple rendering, and therefore prefer it. In the end of the day, FreeType is not MS/Apple font scaler. Fact. As long as v38 is different from v40, some part of it is closer than v40 to MS/Apple's. Also fact.
Re: ttfautohint's functionality from the removal of the infinality patch
Hi Hin-Tak On Fri, Aug 18, 2023 at 2:06 PM Hin-Tak Leung wrote: > I see the infinality patch is already gone (next release, 2.13.2 I guess - > bits of it was removed in 2.13.1 already). Infinality (v38) was substituted by v40 in 2.13.1. Anybody requesting v38 got v40 instead... and nobody even noticed. That is the whole point of the exercise: v40 is perfectly capable and better than just good enough. Now the code is physically gone for good. It is much better to improve faster and lighter v40 moving forward than dwelling on unmaintained, poorly understood, and riddled with exceptions v38. > FWIW, fontval will carry the reverse diff. Why? Or, more precisely, why do you think that either v38 or v40 were ever designed to mimic the corresponding versions of Microsoft engine? That was never the case. *Both* of FreeType implementations were based on principles described in https://learn.microsoft.com/en-us/typography/cleartype/truetypecleartype. Both! but neither was actually tested to reproduce Microsoft precisely. Much like we have no idea how Microsoft does ClearType filtering, except for some public papers. If anybody, Adobe helped here a lot more. Microsoft is multisampling for antialiasing, we don't. Therefore, FreeType != Microsoft in any sense, including v38 != 38 (GETINFO version). Alexei
Re: ttfautohint's functionality from the removal of the infinality patch
On Sun, 20 Aug 2023 at 17:41, Hin-Tak Leung wrote: > On Sunday, 20 August 2023 at 18:28:54 BST, Dave Crossland > wrote: > > > Since almost all new fonts are vf, I'm no longer seeing ttfautohint in > common usage, but I don't think it's effected by this. > > That's not necessarily true - people with poorer monitors are also likely > to be less technically competent, and therefore unlikely to ever actually > report any issues. > > (I am just saying that, it is actually quite dangerous and partial for > people with expensive high-def monitors to decide what is and what isn't > "generally" relevant ...) > Almost all new fonts are vf, and there are no libre tools for hinting VFs
Re: ttfautohint's functionality from the removal of the infinality patch
On Sunday, 20 August 2023 at 18:28:54 BST, Dave Crossland wrote: > Since almost all new fonts are vf, I'm no longer seeing ttfautohint in > common usage, but I don't think it's effected by this. That's not necessarily true - people with poorer monitors are also likely to be less technically competent, and therefore unlikely to ever actually report any issues. (I am just saying that, it is actually quite dangerous and partial for people with expensive high-def monitors to decide what is and what isn't "generally" relevant ...)
Re: ttfautohint's functionality from the removal of the infinality patch
Since almost all new fonts are vf, I'm no longer seeing ttfautohint in common usage, but I don't think it's effected by this.
Re: ttfautohint's functionality from the removal of the infinality patch
On 19.08.23 14:27, Werner LEMBERG wrote: And dropping support, and/or compatibility/ awareness of intended usages of outcome in other *cough* microsoft *cough* hinting models? Well, the Infinality stuff was basically unmaintained; it essentially consisted of a large bunch of exceptions for some special fonts. Alexei and I agree that we no longer need this. There was not a single voice objecting to its removal, by the way... Great! Given that freetype still somehow has the role of a free software reference interpretation of the loose MS instructed gridfit description, it can only be welcomed if freetype-specifics get out of that. What exactly do you mean with 'freetype-specifics'? The Infinality patch aimed to implement v38 of the MS TrueType interpreter as close as possible, and for the supported fonts it worked quite well. Werner But the attempt to mimic MS rasterizer behavior is already a freetype specific. Recall that in 2023, ttfont designers (or their software at least) are still forced to talk "VM bytecode" to tell about scale dependet point updates, even if they do not target MS rasterizer at all. Gruss Jan Bruns
Re: ttfautohint's functionality from the removal of the infinality patch
>>> And dropping support, and/or compatibility/ awareness of intended >>> usages of outcome in other *cough* microsoft *cough* hinting >>> models? >> >> Well, the Infinality stuff was basically unmaintained; it >> essentially consisted of a large bunch of exceptions for some >> special fonts. Alexei and I agree that we no longer need this. >> There was not a single voice objecting to its removal, by the >> way... > > Great! > > Given that freetype still somehow has the role of a free software > reference interpretation of the loose MS instructed gridfit > description, it can only be welcomed if freetype-specifics get out > of that. What exactly do you mean with 'freetype-specifics'? The Infinality patch aimed to implement v38 of the MS TrueType interpreter as close as possible, and for the supported fonts it worked quite well. Werner
Re: ttfautohint's functionality from the removal of the infinality patch
On 18.08.23 23:27, Werner LEMBERG wrote: And dropping support, and/or compatibility/ awareness of intended usages of outcome in other *cough* microsoft *cough* hinting models? Well, the Infinality stuff was basically unmaintained; it essentially consisted of a large bunch of exceptions for some special fonts. Alexei and I agree that we no longer need this. There was not a single voice objecting to its removal, by the way... Great! Given that freetype still somehow has the role of a free software reference interpretation of the loose MS instructed gridfit description, it can only be welcomed if freetype-specifics get out of that. Gruss Jan Bruns
Re: ttfautohint's functionality from the removal of the infinality patch
>> It's not clear what you are actually asking. ttfautohint is an >> incarnation of FreeType's auto-hinter, translated into TrueType >> bytecode, more or less. This is not related to interpreting >> bytecode. > > But does it contain hidden assumptions about how bytecodes are > interpreted (by specific renderer, and specific version of > now-simplified renderer )? No hidden assumptions – everything is documented :-) https://freetype.org/ttfautohint/doc/ttfautohint.html#stem-width-and-positioning-mode Werner
Re: ttfautohint's functionality from the removal of the infinality patch
On Friday, 18 August 2023 at 22:27:26 BST, Werner LEMBERG wrote: > > Are we getting into a situation where ttfautohint is hinting for the > > (limited) "good enough" light hinting model of recent freetype? > It's not clear what you are actually asking. ttfautohint is an > incarnation of FreeType's auto-hinter, translated into TrueType > bytecode, more or less. This is not related to interpreting bytecode. But does it contain hidden assumptions about how bytecodes are interpreted (by specific renderer, and specific version of now-simplified renderer )? > Well, the Infinality stuff was basically unmaintained; it essentially > consisted of a large bunch of exceptions for some special fonts. > Alexei and I agree that we no longer need this. There was not a > single voice objecting to its removal, by the way... I agree there is no general usage for it. For the purpose of fontval's backend, until a genuine Microsoft backend happens (if ever), I suspect that the infinality stuff behaves closer to Microsoft renderer towards Microsoft hinted fonts. So if the goal is not "good enough hinting" but "matching Microsoft behavior", it has to stay. So FWIW, I am just mentioning that I will carry a reverse diff in future version of Fontval, if another release ever happens...
Re: ttfautohint's functionality from the removal of the infinality patch
> Yesterday's opentype font meeting touched upon hinting and > ttfautohint briefly. I see the infinality patch is already gone > (next release, 2.13.2 I guess - bits of it was removed in 2.13.1 > already). Question is, does its removal impact the functionality of > ttfautohint? No. > Are we getting into a situation where ttfautohint is hinting for the > (limited) "good enough" light hinting model of recent freetype? It's not clear what you are actually asking. ttfautohint is an incarnation of FreeType's auto-hinter, translated into TrueType bytecode, more or less. This is not related to interpreting bytecode. > And dropping support, and/or compatibility/ awareness of intended > usages of outcome in other *cough* microsoft *cough* hinting models? Well, the Infinality stuff was basically unmaintained; it essentially consisted of a large bunch of exceptions for some special fonts. Alexei and I agree that we no longer need this. There was not a single voice objecting to its removal, by the way... Werner
