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

[Khaled Hosny]

On Mon, Dec 23, 2013 at 12:41:24AM -0500, Behdad Esfahbod wrote:
>
> API ITEM: Glyph Variants:
> 
> get_glyph() currently takes unicode codepoint as well as variation selector.
> The current semantics is that if variation selector is not 0, you are supposed
> to load the correct glyph for the variation selector, and return FALSE if that
> fails, at which point we call get_glyph() again with variation selector set to
> 0.  It has been suggested that we move to two separate callbacks: get_glyph()
> and get_glyph_variant().  It would be slightly faster to do so, but that would
> spread the get_glyph logic into two callbacks instead of one, which would be
> more error-prone in implementations.  So I'm not sure if it's worth it.
> Client code update is small.

I agree with Jonathan here, separate functions seems clearer/less mythic
to me (I had to check the git log/mailing list archives several times
after the semantics change to verify my callbacks follow it, as I always
forget what it was).

> API ITEM: Vertical Orientation:

Related to vertical typesetting, many applications layout vertical text
horizontally, rotate individual vertical glyphs then rotate the
whole page (so un-rotating the vertical glyphs and rotating the
horizontal ones), it seems this easier to handle than implementing
special support for vertical layout (XeTeX, LibreOffice do so, and I
think WebKit/Blink does something similar). So I think it would be nice
to have a buffer (shape?) flag that tells HarfBuzz to apply vertical
features but keep everything laid out horizontally, WDYT?

> API ITEM: hb_feature_t breakdown:
> 
> This was discussed a couple month ago.  Currently hb_feature_t is defined to:
> 
> typedef struct hb_feature_t {
>   hb_tag_t      tag;
>   uint32_t      value;
>   unsigned int  start;
>   unsigned int  end;
> } hb_feature_t;
> 
> Ideally I like to break that down to:
> 
> typedef struct hb_feature_t {
>   hb_tag_t      tag;
>   uint32_t      value;
> } hb_feature_t;
> 
> typedef struct hb_range_t {
>   unsigned int  start;
>   unsigned int  end;
> } hb_range_t;
> 
> 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 think the simplification of the common case is worth the effort, but
I’d rather have a hb_feature_range_t than having to deal with two arrays
(but if needed, we can have a separate hb_shape_with_ranges() or so for
that).

Regards,
Khaled