On 02/19/2013 05:47 PM, Khaled Hosny wrote: > On Tue, Feb 19, 2013 at 05:34:40PM -0500, Behdad Esfahbod wrote: >>> Is there maybe a way to tell HarfBuzz to ignore ligatures if they span that >>> color boundary? Or is there maybe a way to (quickly) assess if "liga" would >>> be >>> applied to a range of characters? >> >> We don't have a good answer for this right now. The way I want to eventually >> fix this in Pango is different: it is to pain the ligature glyph half in each >> color. I think you can do the same using <canvas>. Just use a gradient with >> a sharp color switch for the ligature. It's a royal pain, but I think that's >> the most desirable rendering. I may be wrong. > > Gecko is (was?) using clipping to partially draw each part of the > ligature: > http://robert.ocallahan.org/2006/10/partial-ligatures_24.html
Thanks for the pointer. Yes, that is also what GTK+ used to do (that code got rewritten so I don't know what it does now) for selection, but not for color attributes. Note that attributes like underline are also affected in the same way. >> As for *where* to cut the ligature, here's what you need: >> >> * Count the number of cursor positions *inside* the ligature. For the "fi" >> ligature it's one. And we have one cursor position before the ligature, so >> in >> this case we need to cut it in two pieces, >> >> * The common heuristic then is to cut the advance width of the ligature >> (well, cluster really) into two equal pieces. If you want to be fancy, you >> can call hb_ot_layout_get_ligature_carets(), and if the number of carets >> matches what you expect (1 in this case I believe?), you can use the returned >> caret positions instead of equally dividing the ligature. I haven't seen >> anyone implementing this though, as it gives very marginal improvements over >> the heuristic. > > It can make quite some different with some Arabic ligatures, but few > fonts implement it because few (no?) engines support it :) Correct. Maybe you can give me a font... ;) Note that BTW, a similar issue exists when kerning text. Most fonts implement kerning by adjusting the advance width of the first glyph. What this means however is that for a pair like "Te", if the e moves way under the T, essentially we will get a very narrow selection width for the "T", and unchanged width for the "e". That's less than ideal. In HarfBuzz we split the kerning half-and-half for old-style TrueType kern pairs. But don't do something like that for GPOS kerning since, well, with GPOS the font designer has full control on what to do. Maybe we should do the same for GPOS kerning tables that only have adjustment for the first glyph and not the second? Donno. May be a nice improvement. What do others think? behdad > Regards, > Khaled > -- behdad http://behdad.org/ _______________________________________________ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz