Closed Bug 1395774 Opened 2 years ago Closed 2 years ago

Incorrect placement of bopomofo tone marks in vertical writing mode

Categories

(Core :: Graphics: Text, defect, P3)

defect

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox55 --- wontfix
firefox56 --- wontfix
firefox57 --- wontfix

People

(Reporter: kevin.hsieh, Unassigned)

References

(Blocks 2 open bugs, )

Details

(Whiteboard: gfx-noted)

Attachments

(1 file)

User agent:  Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:57.0) Gecko/20100101 Firefox/57.0
Nightly version: 57.0a1 (2017-08-31) (64-bit)

Steps to reproduce:
Open the URL.

Actual results:
Bopomofo tone marks overlap the annotations.

Expected results:
Bopomofo tone marks should be placed next to the annotations. Reference the Safari rendering. Chrome has similar but not identical behavior to Firefox. It's possible that this is a harfbuzz issue.
Flags: needinfo?(jfkthame)
Summary: Incorrect placement of bopomofo tone marks → Incorrect placement of bopomofo tone marks in vertical writing mode
I'd like to add some context.

I discussed with Bobby Tung (the author of the test case, and the contact who is pushing bopomofo-support on Web) about this test case before.

He told me that, the author of this test font found that the GPOS parameters end up being rather arbitrary that the author himself cannot really understand the meaning. But this test font works the same way in Safari as well as InDesign, so presumably we should match their behavior.
I've seen this before, or something very much like it.... ah, I think it was bug 1148660, but the original testcase URL there doesn't seem to exist any longer.

We apparently fixed something in that bug, but the behavior of the testcase there (with current Nightly) doesn't look correct to me; I wonder if it has broken in the meantime? Unfortunately, builds from that time refuse to run on my current system, so it's not easy to re-check what the behavior was at that time and see if we've regressed something.

I'll try on different platforms in a while, and see if that helps...
The minimal Firefox version on macOS 10.12 is 50 IIRC.

I believe this testcase is never fully fixed... I'm not sure what was fixed in bug 1148660, then...
I just checked Firefox 41 and 40... It doesn't seem to me that the rendering of this testcase is changed much :/
(In reply to Xidorn Quan [:xidorn] UTC+10 from comment #3)
> The minimal Firefox version on macOS 10.12 is 50 IIRC.
> 
> I believe this testcase is never fully fixed... I'm not sure what was fixed
> in bug 1148660, then...

Checking back, it seems the simple testcase attached to bug 1148660 (attachment 8610505 [details]) was fixed (compare the rendering in Firefox 41 vs Firefox 40, when the writing mode is toggled to vertical); but then it was subsequently broken again in Firefox 42 by the change in bug 729993. Note that commenting out the line

    hb_buffer_set_cluster_level(buffer, HB_BUFFER_CLUSTER_LEVEL_MONOTONE_CHARACTERS);

in gfxHarfBuzzShaper::Initialize fixes the vertical-mode rendering of attachment 8610505 [details] again.

However, this doesn't appear to help the bopomofo example. I think that primarily needs to be addressed in harfbuzz, or even at the OpenType spec level if it's unclear how the GPOS features ought to be handled in vertical mode.
Flags: needinfo?(jfkthame)
Depends on: 1395926
Priority: -- → P3
Whiteboard: gfx-noted
This is an updated version of the testcase from the URL, with an embedded copy of the bopomofo font where the GPOS offsets have been corrected to what I believe are more appropriate values; see https://github.com/behdad/harfbuzz/issues/532 for more details.

This version renders as expected in current Chrome, and also in Firefox once the fixes for bug 1395926 (which affects the horizontal positioning of the tone marks) and bug 1412355 (which fixes a problem with their clipping) are landed. It does -not- render as expected in Safari, at least on macOS 10.12, but I believe this to be an Apple bug (see discussion in the harfbuzz issue).
This bug seems to be resolved now?
Flags: needinfo?(jfkthame)
Yes, I believe so. This was affected by a combination of at least a couple of different bugs (see comment 6), but all looks good now -> resolving as WFM.
Status: NEW → RESOLVED
Closed: 2 years ago
Flags: needinfo?(jfkthame)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.