[HarfBuzz] HarfBuzz 1.0 API; the message you were hoping would never come

[Khaled Hosny]

On Thu, Jan 02, 2014 at 01:04:32PM +0800, Behdad Esfahbod wrote:
> On 13-12-30 08:26 PM, Jonathan Kew wrote:

[…]

> Which, reminds me that when we added buffer flags for BOT/EOT, we also tagged
> preserve-default-ignorables along those, but that one isn't really a buffer
> flag.  It's a shape flag.  So I like to add a new hb_shape_flags_t, move
> preserve-default-ignorables there, and add compatibility decomposition there,
> perhaps some other high level shaping options?  Disable fallback shaping /
> positioning for example?  Can be useful for testing fonts if nothing else.

+1 (disabling fallback shaping etc. would be very desirable when “pure”
OpenType layout is needed like font testing, as you say, or for HarfBuzz
integrated in font editors or similar).

[…]

> >> And either define hb_feature_range_t that has a hb_feature_t and a hb_range_t
> >> inside, or change hb_shape() (and variants) to take an array of hb_feature_t
> >> as well as hb_range_t.  Both approaches have their benefits, though I'm more
> >> interested to know whether such a big change is considered possible or too
> >> much of a change.  Updating client code is trivial for the most part,
> >> especially with hb_feature_range_t, though, harder to #ifdef.
> > 
> > I'd quite like clients that only use "global" features (i.e., they always call
> > harfbuzz with text runs that have uniform styling) to be able to avoid
> > creating ranges at all. (This would currently apply to both firefox and xetex,
> > I believe, though I have some thoughts about changing it in FF some day.)
> 
> Currently true, but no client really should do that in an ideal world...

I’d love to support feature ranges in XeTeX but it is too much work
(and involves quite some hacking deep inside TeX) that I doubt I’ll ever
do it myself.

Regards,
Khaled