Sounds good; I'll look at walking over the feature list for 'kern' features when I get a chance and push an update. (That may not be today, as I'll need to do other work).
On Tue, Jan 23, 2024 at 10:45 AM Behdad Esfahbod <beh...@behdad.org> wrote: > 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. >>> >>>
