Incorrect re-ordering of Tibetan script Characters

RESOLVED WORKSFORME

Status

()

P3
normal
RESOLVED WORKSFORME
2 years ago
a year ago

People

(Reporter: chris.fynn, Unassigned)

Tracking

53 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

2 years ago
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

Updated

2 years ago
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...
Flags: needinfo?(chris.fynn)

Comment 2

2 years ago
WFM with FF53 32b/64b on Win 7. Like Chrome.
(Reporter)

Comment 3

2 years ago
(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)
Flags: needinfo?(chris.fynn)
(Reporter)

Comment 4

2 years ago
Created attachment 8866573 [details]
Bug 1363458 test snippet
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.

Comment 6

2 years ago
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.

Comment 8

a year ago
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
Priority: -- → P3
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?
Flags: needinfo?(chris.fynn)
(Reporter)

Comment 10

a year ago
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
Flags: needinfo?(chris.fynn)
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.