Created attachment 8865962 [details] 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
Component: Untriaged → Layout: Text
Product: Firefox → Core
Does this still occur with the latest Nightly (Firefox 55.0a1)? IIRC, there have been some recent fixes in harfbuzz related to Tibetan marks...
WFM with FF53 32b/64b on Win 7. Like Chrome.
(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)
Attachment #8866573 - Attachment mime type: text/plain → text/html
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.
Does Christopher need to narrow down a regression range as he said the bug was not present in earlier versions of Firefox?
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.
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
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?
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
OK, thanks for confirming; let's close this.
Status: UNCONFIRMED → RESOLVED
Last Resolved: a year ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.