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
<[email protected]> 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 <[email protected]>
wrote:
On Jan 22, 2024, at 12:45, Hin-Tak Leung <[email protected]> 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.
