Closed Bug 1297365 Opened 8 years ago Closed 8 years ago

Position of Hebrew Cantillation incorrect

Categories

(Core :: Graphics: Text, defect)

47 Branch
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla51
Tracking Status
firefox51 --- fixed

People

(Reporter: ynovetsky, Assigned: jfkthame)

Details

(Keywords: fonts, testcase)

Attachments

(5 files)

Attached file 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.
Attached image Firefox Screenshot
Attached image Chrome Screenshot
As one can see, in Chrome the position of the cantillation is correct.
Component: Untriaged → Graphics: Text
Product: Firefox → Core
Keywords: fonts, testcase
Attached image FF48-Win7.png
WFM with FF 48.0.1 on Win 7 64b. Could you update to FF48 and test again, please.
Flags: needinfo?(ynovetsky)
(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.
(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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(ynovetsky)
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.
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.
Assignee: nobody → jfkthame
Status: NEW → ASSIGNED
How will fixing this bug relate to Bug 778565 (if at all)?
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.
Attachment #8784054 - Flags: review?(jmuizelaar) → review+
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
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla51
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: