> > it might be useful to add (also) either compile-time or runtime switch to > hb-based gpos-kerning >
I just pushed an update to the merge request to add a config flag TT_CONFIG_OPTION_GPOS_KERNING and set it to default to disabled when HarfBuzz is available. Users of HarfBuzz can/should use hb_shape instead to get full shaping support. Let me know if you have further thoughts/feedback on that. On Mon, Jan 22, 2024 at 1:41 PM Hin-Tak Leung <ht...@users.sourceforge.net> wrote: > 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 > doesn't bitrot? > > If that's done, there is a problem of which to use by default... but then > we already have conditionals on harfbuzz being available, etc, so it is > probably easy enough to just piggyback on that conditional. > > On Monday, 22 January 2024 at 20:35:17 GMT, David Saltzman < > davidbsaltz...@gmail.com> wrote: > > > 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. > >
