In the presence of complex font behavior such as ligatures and Indic-style reordering of glyphs, the association between underlying characters (and style information such as color) and the final rendered glyphs is not always handled consistently. This leads to inconsistent user experience when selecting substrings of the text, and inconsistent display where parts of the string are styled differently (e.g., with color or underlining). The attached test document uses colored spans to illustrate the behavior. Screenshots of the results as displayed on OS X (from left to right: Firefox 3.0.7; Minefield trunk using ATSUI with the clustering patch from bug 481948; Minefield trunk using Core Text), Linux, and Windows will also be attached. Some comments on the results: In both the Devanagari examples, FF 3.0.7/Mac displays the text as just two clumps, and colors each with the color of its first *character* (not glyph). The 3rd line uses various control-character tricks to try and simulate an "ideal" rendering, but would be difficult or impossible to achieve in practice, depending on the use of ligature glyphs in the font. Note how in the case of the Latin ligature, it is painted in two halves, even though it is a single glyph; this works OK for a simple "horizontal ligature" but would be less satisfactory in cases where the components are combined vertically or in other non-linear ways. Minefield/ATSUI shows some differences: in the second Devanagari test, the constituent colors are visible, but are being used on the wrong glyph, indicating poor character/glyph association. And the Latin "fi" is painted in a solid color. I consider this a regression from bug 481948 and will try to fix it. (Note, however, that without the patch from 481948, we have more serious Indic display issues, with glyphs completely disappearing!) Minefield/CoreText also shows differences: in the first Devanagari test, its result is arguably better, as the color of the cyan letter has been maintained properly. The final clump (in magenta here) is colored according to its base character rather than its diacritic, even though the diacritic was earlier in the text; there's not really any "right" solution to this, although using the color of the base is perhaps more natural. The second Devanagari test shows part of the same problem as with ATSUI, though there is no green segment. On Linux, the first Devanagari test shows the characters are being treated as two clusters, and the second cluster is painted in two parts; however, the resulting colors are not well associated with the underlying characters - the originally-cyan "JA" is largely blue, the originally-blue "RA" (rendered as the REPH diacritic) is entirely cyan, and so is the "A" vowel, whose original magenta has disappeared (despite this being a spacing character, unlike the REPH). The second Devanagari test shows similar behavior, with the first three letters forming a cluster that is then painted in vertical stripes. It's not ideal (the first KA, at least, is a separate glyph and could in theory be painted in its true color), but at least it is logical. On Windows, we see similar behavior to the Mac FF 3.0.7 result, with no attempt to divide up the Indic clusters into multiple regions. (Ignore the fact that the "ideal" line doesn't work on all platforms; some shaping engines refuse to play the necessary tricks for this. On CoreText, though, it shows a drawing problem as the JA glyph gets incorrectly double-painted.) So there are several issues worth looking at here: * ATSUI rendering regressions from bug 481948, shown in middle Mac screenshot * Inconsistency between ATSUI and CoreText behavior, shown in right-hand Mac screenshot * Failure to associate characters with glyphs through reordering (the CoreText image shows that there is at least some potential for this) * Failure to divide up clusters consistently (a Devanagari cluster is painted in a single solid color on OS X and Windows, but in sections on Linux, while a Latin ligature is painted in sections on all platforms) None of these issues currently show up through any existing reftests, AFAIK, but it should be possible to create some tests that catch various aspects of all this.

Is it really worth striving for cross-platform consistency here while we're not even guaranteed to get consistent shaping? I think I'd rather invest in Harfbuzz as a cross-platform shaping solution.

In practice, I wouldn't expect to invest a lot in other directions - especially not Pango, as I expect HB to supersede that. We'll probably want to keep CoreText and Uniscribe paths around for quite a while, at least, so those may be more worth looking at; and we may need to think a bit more about what we really need from HB in order to handle this as well as we can - currently, we don't have a clear, testable set of requirements, as shown by the fact that all these variations pass our existing tests. I think I should try to fix the ATSUI regressions that this exercise has shown up, and probably the CoreText glitch as well, especially as I'm currently very familiar with those pieces of code, but I'm not proposing to tackle the entirety of this in one go. It came out of wanting to do some deeper testing of the patches I've been writing, and realizing that things are not very well defined or tested at the moment.

Marked this as random on OS X in the reftest list for now, as it will fail under ATSUI if we go ahead and land bug 481948. (Ideally, I'll get that fixed soon.)

(In reply to comment #7) > Created an attachment (id=372732) [details] > patch adding a reftest for two-colored ligature > > Marked this as random on OS X in the reftest list for now, as it will fail > under ATSUI if we go ahead and land bug 481948. (Ideally, I'll get that fixed > soon.) This test is now included in the reftest attachment for bug 481948, and passes ok with the latest version of the patch there.