1297365 - Position of Hebrew Cantillation incorrect

Status: RESOLVED FIXED

(Core :: Graphics: Text, defect)

Description

[Inkbug]

Attachment: testcase.html

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160623154057

Steps to reproduce:

View the text in the testcase file.


Actual results:

Some of the cantillation marks were placed incorrectly.
Specifically, all cantillation marks placed under or above an Aleph with a Qamatz (אָ) or a Pataḥ (אַ) are shifted to the left, so they are not under the the letter anymore.

Comment 1

[Inkbug]

Attachment: Firefox Screenshot

Comment 2

[Inkbug]

Attachment: Chrome Screenshot

As one can see, in Chrome the position of the cantillation is correct.

Comment 3

[Loic]

Attachment: FF48-Win7.png

WFM with FF 48.0.1 on Win 7 64b.

Could you update to FF48 and test again, please.

Comment 4

[Jonathan Kew [:jfkthame]]

(In reply to Loic from comment #3)
> Created attachment 8783945 [details]
> FF48-Win7.png
> 
> WFM with FF 48.0.1 on Win 7 64b.
> 
> Could you update to FF48 and test again, please.

According to comment 0, it looks like the reporter is on Win10. The issue here will almost certainly be dependent on the specific font versions, so testing Win7 isn't comparable -- it's a safe bet that the fonts have undergone major updates between Windows versions.

Comment 5

[Jonathan Kew [:jfkthame]]

(In reply to Loic from comment #3)
> Created attachment 8783945 [details]
> FF48-Win7.png
> 
> WFM with FF 48.0.1 on Win 7 64b.

Actually, it doesn't work all that well; your screenshot shows a bunch of places where marks overprint each other, instead of rendering separately. But this is a different failure than the OP's issue, and almost certainly happens because of a lack of adequate GPOS mark positioning in the fonts on Win7.

On Win10, I see the same (bad) result as the reporter, with both Release and Nightly versions.

Comment 6

[Inkbug]

Note that in the testcase, the first example is using the Keter YG font (available for free here: http://culmus.sourceforge.net/taamim/KeterYG.zip). If one installs that font, one shouldn't have problems reproducing the issue, at least based on font version.

Comment 7

[Jonathan Kew [:jfkthame]]

OK, I see what's happening here. This only affects cases where there is a "presentation form" encoded for the base letter + dagesh or vowel point, such as aleph+patah -> U+FB2E, and then a cantillation mark is also added.

In bug 728866, we added code that makes gecko explicitly choose the presentation-form character for such combinations, because in old fonts such as those shipped with WinXP this gives better rendering (because those fonts had no OpenType mark-positioning support).

Unfortunately, the newer fonts (such as those on Win10, or the Keter YG font mentioned above) which rely on OpenType mark positioning in preference to presentation-form codepoints do not seem to include mark positioning rules for cantillation marks on the presentation-form glyphs; they only support this for the (preferred) decomposed base + mark sequences.

Therefore, when gecko composes the base+dagesh/vowel into a presentation-form glyph, we no longer get the benefit of mark positioning for the following cantillation mark. :(

Fortunately, I think we have a solution. The "fix" (hack) in bug 728866 gets applied to all Hebrew text, but since we did that, the same behavior has been implemented within harfbuzz, but in a more focused way: it only applies these compositions if the font being used does *not* have a GPOS 'mark' feature. Therefore, it will still work for old WinXP fonts, but it won't affect the new Win10 ones.

So all we need to do is remove the gecko-level version of this hack, and rely on the more narrowly-focused version within harfbuzz; this will allow the newer fonts to behave as designed.

Comment 8

[Jonathan Kew [:jfkthame]]

Attachment: Remove legacy Hebrew presentation-form composition rules from gecko, and rely on harfbuzz internally applying these only to fonts that need them

Comment 9

[Inkbug]

How will fixing this bug relate to Bug 778565 (if at all)?

Comment 10

[Jonathan Kew [:jfkthame]]

It's possible it will help (in some cases?), though it will depend on the exact details of what is supported by the fonts concerned.

I've started a try build with this patch (https://treeherder.mozilla.org/#/jobs?repo=try&revision=1bc740e4bf5c), so you could try testing with that once it's ready.

Comment 11

[Jonathan Kew [:jfkthame]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/dcd8aa8312fe0c6cd4195e418538ca4cdf695957
Bug 1297365 - Remove legacy Hebrew presentation-form composition rules from gecko, and rely on harfbuzz internally applying these only to fonts that need them. r=jrmuizel

https://hg.mozilla.org/integration/mozilla-inbound/rev/f7de27ec1079a5b4029292e6589c72463db85b0d
Bug 1297365 followup - Update font used in bidi-004 reftest for current OS X and Windows; mark test as fuzzy on Linux due to inconsistent glyphs in Hebrew font used. no_r=me

Comment 12

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/dcd8aa8312fe
https://hg.mozilla.org/mozilla-central/rev/f7de27ec1079