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