> > 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 first tried just using FreeType's kerning API, before learning that wouldn't work because of kern tables vs GPOS. So then we tried integrating HarfBuzz, since that seemed to be the standard solution. However, after integrating that, even with HB_TINY and some custom modifications to trim it, that was too large and slow for this device; this is on an embedded device with limited flash/ram/processing speed. We have no plans to add languages that require more advanced shaping that would require HarfBuzz anyway, so it'd inevitably add a lot of unnecessary overhead. Another option was to use a script to modify the font to convert the GPOS table to a kern table, then use unmodified FreeType's kerning function; that option worked as well, though the font files ended up larger. So for a product like this, it's valuable to have GPOS kerning support in FreeType.
it is also not unheard of to maintain a semi-permanent set of patches for > freetype deemed unsuitable for upstreaming > We do have our own copy of FreeType anyway, so we could just maintain the patch there and drop this merge request for open sourcing the GPOS kerning implementation if it's decided against taking it. It wouldn't impact us either way, but a co-worker asked to upstream this one for anyone else who may benefit from it. On the other hand, the dysfunctional kerning API, which exists, is > misleading > Yes, if FreeType's kerning API had just worked for our GPOS font, that would've saved us from going down this rabbit hole of kern tables and GPOS tables, and we could've remained blissfully ignorant with everything just working easily. So it would be nice to save others from that :). Another anecdote is that we also then realized that a previous product which had added kerning support through the FreeType API with its old font ended up losing kerning after the font was swapped out for one with kerning in the GPOS table, and we had shipped that update without noticing the loss; so FreeType supporting GPOS kerning as well could help prevent issues like that. The line could be drawn exactly there at the existing API. the scope of the > change should be clearly defined. > Drawing the line at the existing API, so leaving the scope at kerning-only and not planning to add support for other GPOS features like x-placement etc, sounds good to me. David On Mon, Jan 22, 2024 at 12:01 PM Alexei Podtelezhnikov <apodt...@gmail.com> wrote: > > > > On Jan 22, 2024, at 12:45, Hin-Tak Leung <ht...@users.sourceforge.net> > 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 bad > idea. The line could be drawn exactly there at the existing API. > > I agree that the scope of the change should be clearly defined. > >
