Bug 138213 – Text positioning is wrong in ComplexTextControllerCoreText if left-most glyph has non-zero glyph position offsets

• Status: RESOLVED
• Resolution: FIXED
• Component: Layout and Rendering

[Behdad Esfahbod]

As explained here:
https://code.google.com/p/chromium/issues/detail?id=352736

I said:

On the CoreText path, the issue still exists, AND it's both vertical and horizontal mispositioning.  The root of the problem is similar though: GlyphBuffer doesn't have the position of the leftmost glyph.  So fixing it would need wiring up a startPosition the way the HarfBuzz shaper does.

In fact, ComplexTextControllerCoreText.mm uses CTRunGetAdvancesPtr instead of CTRunGetPositionsPtr.  That itself has the bug.  From the CTRunGetAdvancesPtr docs:

"""Note that advances alone are not sufficient for correctly positioning glyphs in a line, as a run may have a non-identity matrix or the initial glyph in a line may have a non-zero origin; callers should consider using positions instead."""

Here's a test case, test on Safari and Firefox: http://behdad.org/urdu

[Behdad Esfahbod]

Ned, since you are listening:

I noticed that if I have a, eg RLE, at the beginning of a run of text, CoreText outputs a glyph with id 65535 there.  I imagine this is to help with cluster mapping...

One way to fix this bug for Webkit and others at the same time is, if the first glyph in buffer out from CoreText has non-zero offsets, prepend one of those invisible glyphs there.

[Myles C. Maxfield]

We already track the location of the run as a whole (using CTRunGetInitialAdvance). Seems that we could just add in the position of the first glyph (unless that is what CTRunGetInitialAdvance is already doing)

[Behdad Esfahbod]

Correct.  That's similar to what we (Blink) did in our other controller:

  https://codereview.chromium.org/180893004

More recently, we changed GlyphBuffer API to carry both advances and offsets.

[Myles C. Maxfield]

Reduction: لے آ

[Myles C. Maxfield]

Created attachment 240714 [details]
Reduction

[Myles C. Maxfield]

The problem here is that CoreText is encoding the additional horizontal space in the glyph that it is attributing to the space character. WebKit sees this and ignores the advance that CoreText supplies, and instead uses the spaceWidth() which we had cached at font creation time.

[Myles C. Maxfield]

Selection doesn't work because ComplexTextController::advance() doesn't take the initial advance into consideration when computing widths

[Behdad Esfahbod]

(In reply to comment #6)
> The problem here is that CoreText is encoding the additional horizontal
> space in the glyph that it is attributing to the space character.

Well, root of problem is that CTRunGetAdvancesPtr() (and even CTRunGetPositionsPtr) returns displacement from one glyph position to the next glyph position.  So it loses the difference between the advance of current glyph and next glyph's offset from its origin.


> WebKit
> sees this and ignores the advance that CoreText supplies, and instead uses
> the spaceWidth() which we had cached at font creation time.

Interesting!

[Behdad Esfahbod]

Ok so it occurs to me that there are two separate problems here, resulting in the same wrong behavior:

  - Use of CTRunGetAdvancesPtr instead of CTRunGetPositionsPtr.  This loses the positioning of the left-most glyph in a run,

  - Replacement of glyph displacement from a space glyph to the glyph to its right, which loses the positioning of the glyph to the right of a space character.

Those are separate issue.

This normally doesn't show itself up because in left-to-right text, the leftmost glyph or the glyph to the right of space are typically base-characters and have a positioning of 0,0 relative to the glyph position.  In right-to-left text, when the last character in a word or run is a combining mark, and if the font has mark-to-base glyph positioning (GPOS feature 'mark'), then the left-most glyph or glyph to the right of space have non-trivial positioning that is lost.  We originally observed this with normal Arabic fonts.

With this Noto Nastaliq font, this happens more because the font decomposes Arabic letters with dots or other "diacritics" into multiple glyphs, the left-most one (in right-to-left order) acting like a combining mark.

Hope that helps.  Let me know if I can be of more help.

[Myles C. Maxfield]

The patch at https://bugs.webkit.org/show_bug.cgi?id=138348 fixes one of the problems here.

[Dave Crossland]

Created attachment 283779 [details]
Comparison of Safari 9 and Chrome 51

This issue remains unresolved after several years :( 

Comparison of OS X 10.11.5, Safari Version 9.1.1 (11601.6.17), and Chrome Version 51.0.2704.103 (64-bit), rendering http://behdad.org/urdu/ (note the shaping on the right end of the last line...)

[Myles C. Maxfield]

(In reply to comment #9)
> Ok so it occurs to me that there are two separate problems here, resulting
> in the same wrong behavior:
> 
>   - Use of CTRunGetAdvancesPtr instead of CTRunGetPositionsPtr.  This loses
> the positioning of the left-most glyph in a run,
> 
We use CTRunGetInitialAdvance() which gets this.

[Myles C. Maxfield]

The overlapping glyphs problem showed in the screenshot is being fixed in https://bugs.webkit.org/show_bug.cgi?id=160892. After that patch lands, I'd appreciate it if you could take a look at a WebKit nightly build to see if this problem is fixed, or if there is more to do here.

[Myles C. Maxfield]

(In reply to comment #13)
> The overlapping glyphs problem showed in the screenshot is being fixed in
> https://bugs.webkit.org/show_bug.cgi?id=160892. After that patch lands, I'd
> appreciate it if you could take a look at a WebKit nightly build to see if
> this problem is fixed, or if there is more to do here.

Any word?

[Behdad Esfahbod]

Sorry Myles, I dropped the ball on this.  Don't have a Mac nearby.  If http://behdad.org/urdu/ renders similar to what Firefox or Chrome does, it's good.

Thanks,