Hi David, As mentioned on the issue, the main thing I like to see you address is, instead of walking all subtables, only walk subtables from 'kern' features.
behdad On Tue, Jan 23, 2024 at 10:43 AM David Saltzman <davidbsaltz...@gmail.com> wrote: > 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. >> >>
