Re: Creating a FreeType GitLab merge request

2024-01-22 Thread David Saltzman
> > this seems to duplicate functionality in harfbuzz, and also a mere subset, > for that matter? > Yes, that's a good question. For the product I'm working on, we wanted to add kerning support, and we already used FreeType but not HarfBuzz, and our font had GPOS kerning but not a kern table. We

Re: Creating a FreeType GitLab merge request

2024-01-22 Thread Hin-Tak Leung
FWIW, this seems to duplicate functionality in harfbuzz, and also a mere subset, for that matter? It is rather a dead-end development direction? I think the question is, at what point do you stop? AFAIK, this kind of functionality was removed quite intentionally from freetype and moved to

Re: Creating a FreeType GitLab merge request

2024-01-22 Thread Alexei Podtelezhnikov
> On Jan 22, 2024, at 12:45, Hin-Tak Leung wrote: > > FWIW, this seems to duplicate functionality in harfbuzz, and also a mere > subset, for that matter? On the other hand, the dysfunctional kerning API, which exists, is misleading. Partial GPOS support to fulfill the API promise is not a

Re: Creating a FreeType GitLab merge request

2024-01-22 Thread Hin-Tak Leung
Yes, that sounds quite reasonable. Yes, harfbuzz is big and not everybody needs/wants all of it. To guard against bitrot, it might be useful to add (also) either compile-time or runtime switch to hb-based gpos-kerning looking up along the same code path, just to make sure that this new code

Re: Creating a FreeType GitLab merge request

2024-01-22 Thread David Saltzman
Thanks Alexei. I found the issue on the wiki ; apparently new accounts have forking disabled by default, and new users need to file user verification tickets to get verified before being