[HarfBuzz] Ligatures and color changes

[Behdad Esfahbod]

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/