1363458 - Incorrect re-ordering of Tibetan script Characters

Status: RESOLVED WORKSFORME

(Core :: Layout: Text and Fonts, defect, P3)

Description

[Christopher J. Fynn]

Attachment: Incorrect Rendering of Tibetan vowel mark sequence 0F71 0F74

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

Steps to reproduce:

It appears where there is a sequence of any Tibetan consonant character followed by the Tibetan vowel mark characters U+0F71 U+0F74 these two characters are getting incorrectly re-ordered as U+0F74 U+0F71 causing the glyph for the character U+0F71 to be displayed on a dotted circle rather than directly under the consonant glyph (base character)


https://sites.google.com/site/chrisfynn2/home/tibetanscriptfonts/thetibetanwritingsystem/consonantkawithsanskritvowels

This problem does not occur when the same page is rendered with other browsers and did not occur with earlier versions of Firefox



Actual results:

sequence of characters (e.g. ཀཱུ  or ཨཱུ) incorrectly rendered with the second character U+0F71 being rendered on a dotted circle 




Expected results:

the glyph for the  character U+0F71 should be rendered immediately under the base character and before (above) the following character U+0F74

Comment 1

[Jonathan Kew [:jfkthame]]

Does this still occur with the latest Nightly (Firefox 55.0a1)? IIRC, there have been some recent fixes in harfbuzz related to Tibetan marks...

Comment 2

[Loic]

WFM with FF53 32b/64b on Win 7. Like Chrome.

Comment 3

[Christopher J. Fynn]

(In reply to Jonathan Kew (:jfkthame) from comment #1)
> Does this still occur with the latest Nightly (Firefox 55.0a1)? IIRC, there
> have been some recent fixes in harfbuzz related to Tibetan marks...

Yes bug is still there with 55.0a1 (2017-05-10) (64-bit)

Comment 4

[Christopher J. Fynn]

Attachment: Bug 1363458 test snippet

Comment 5

[Jonathan Kew [:jfkthame]]

Interesting.... AFAICS, this seems to be specific to the Jomolhari font; it doesn't reproduce with Microsoft Himalaya.

Anyhow, this should really be reported as a harfbuzz issue. I can reproduce the same behavior in a standalone build of the hb-view tool.

Comment 6

[Loic]

Does Christopher need to narrow down a regression range as he said the bug was not present in earlier versions of Firefox?

Comment 7

[Jonathan Kew [:jfkthame]]

A Firefox regression range would be less useful than a harfbuzz one. The way to get this fixed in Firefox is to fix it upstream, and then merge from there.

So the best thing would be to file an issue at https://github.com/behdad/harfbuzz and continue investigation/discussion there.

Comment 8

[Elie Roux]

I think this corresponds to this bug:

https://github.com/behdad/harfbuzz/issues/417

which has a pull request on

https://github.com/behdad/harfbuzz/pull/443

Comment 9

[Jonathan Kew [:jfkthame]]

I'm unable to reproduce this in current Nightly; I believe it should be fixed thanks to harfbuzz updates. Christopher, can you confirm this with a current Firefox Nightly version?

Comment 10

[Christopher J. Fynn]

I can confirm this is fixed in 56.0.2. Many thanks

(BTW Sorry for the late response - I'm in Nepal and often away from internet access.)


- Chris

Comment 11

[Jonathan Kew [:jfkthame]]

OK, thanks for confirming; let's close this.