[HarfBuzz] Flags for start/end of text/line

[Behdad Esfahbod]

Hi,

A while back I added support for dottedcircle insertion in HarfBuzz.  That
happens in two cases:

  - In Indic module, when a cluster is not wellformed.  This seems to be
functioning good enough.

  - At the beginning of text, when text starts with a combining mark.

The latter caused the same bug in GNOME, Firefox, and Chromium: if a combining
mark is not supported by the default font, it gets associated with a fallback
font, and the mark is shaped in the fallback font in isolation.  This would
then cause a dottedcircle to be inserted because a mark starts the run text.
To address this bug, I added "textual context" support, where the client can
tell HarfBuzz what text precedes, and what follows, the text being shaped.
This "fixed" the problem in GNOME after I changed Pango to pass that
information to HarfBuzz.

However, this concerns me now, because I imagine most users won't pass the
textual context information in, and will hit the same bug.  So I like to
explore addressing it in a way that the simplest usecase won't be affected by
the bug.

At the same time, I started looking at adding AAT/morx support to HarfBuzz,
and looks like morx has different modes for when text is paragraph/line
start/end.  OpenType has similar features, but only for optical alignment.

So it made me wondering whether I should add a set of flags to hb_shape() to
let user specify whether the text run is paragraph/line start/end.  If we add
that, the default (no flags) would mark the run being "in the middle", and
dottedcircle won't be inserted.  The flags also address the AAT/morx
requirement.  Whether we should automatically enable OpenType line start/end
optical alignment is not very clear to me yet, but that would be a possibility.

So, what do people think?  Should I go ahead and do that?  If yes, I need to
think the logical/visual distinctions and implications.  And, should I change
the hb_shape() / hb_shape_full() API?  Or add new parallel API, or what?  I
used to have placeholder for shaper-options in the API but removed it for
simplicity.  If I add now, it would be a small headache for all users, but
will keep it open for use to add more binary flags in the future.  In the
interest of breaking users sooner than later, I thought I bring it up now.

If we add that API, we can also add more flags, like "don't remove invisible
characters", or "don't add dottedcircle", though the value of the latter is
not quite clear to me.  I definitely don't want to expose too much of the
internal workings, so I'm not sure whether I want to expose "don't do fallback
positioning", but I'm still undecided.  Leaving it possible to add up to 32
flags by one ABI change sounds compelling though.

Cheers,
behdad