Done On Tue, Jan 23, 2024 at 10:50 AM David Saltzman <davidbsaltz...@gmail.com> wrote:
> 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. >>>> >>>>
