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

[Lóránt Pintér]

I'm not sure I completely understand this feature. Would this help with shaping around line-endings as well?

-- 
Lóci

On 2012.10.25., at 3:17, Behdad Esfahbod <behdad at behdad.org> wrote:

> 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
> _______________________________________________
> HarfBuzz mailing list
> HarfBuzz at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/harfbuzz