Incorrect placement of bopomofo tone marks in vertical writing mode

[kahsieh]

Neither Chrome nor Firefox correctly place bopomofo tone marks next to the annotations for the test case at https://bobbytung.github.io/BopomofoLayoutTest/case02/index.html, where the tone marks' positions are adjusted using vkrn.

Expected result:

Chrome:

Firefox:

Safari (gets the placement correct except there's extra space where the tone mark would be if its position were not adjusted):

Minimal testcase:
testcase.zip

See also:
https://bugzilla.mozilla.org/show_bug.cgi?id=1395774

[jfkthame]

The font uses mark attachment in the 'vkrn' feature to place the tone marks relative to the base glyphs. However, it looks to me like the GPOS attachment positions in the test font don't really make sense for the desired placement. We have anchors on the base glyphs such as

        <BaseRecord index="0">
          <BaseAnchor index="0" Format="1">
            <XCoordinate value="100"/>
            <YCoordinate value="-1500"/>
          </BaseAnchor>
        </BaseRecord>

where the y-coordinate suggests a mark placed well below the base character to which it is attached, and the x-coordinate shifts it just a bit to the right.

The desired result, OTOH, is for the mark to be raised up somewhat relative to the base, and shifted quite a long way to the right. And sure enough, if I modify the font to have base anchors that reflect this, e.g.:

        <BaseRecord index="0">
          <BaseAnchor index="0" Format="1">
            <XCoordinate value="800"/>
            <YCoordinate value="500"/>
          </BaseAnchor>
        </BaseRecord>

then the harfbuzz (hb-view) and Chrome results look a lot like the "expected" image. (Firefox currently has a bug in how it interprets the position offsets from harfbuzz, so it gets the horizontal offset wrong, but that's a separate issue for us to fix.)

Modifying the font in this way, then, will give the desired result in harfbuzz-based applications. Unfortunately, however, it breaks the result in Safari, which ends up with something similar to the "bad" Chrome result.

I think this means that Safari has a bug in how it applies mark attachment in vertical mode, such that it swaps vertical and horizontal offsets; this example font was developed by "trial and error" such that it works under Safari's misinterpretation of the attachments, but this results in bad rendering for harfbuzz-based apps. But we'll need to check this with Ned at Apple.

[behdad]

cc @nedley

[jfkthame]

I also tried setting the BaseAnchor to (0, 0) on all the glyphs. The mark anchors are also at (0, 0). Hence, we'd expect to see the attached marks overlaying their base characters. And indeed, this is what happens in Chrome. But in Safari, the marks "attached" at (0, 0) appear to be about 1em below and to the right of their base characters. It looks like Safari is doing something quite weird with attachments in vertical mode.

[nedley]

Have you checked Safari on High Sierra?

[jfkthame]

No, I'm still on Sierra. If behavior has changed in HS, that could potentially be very good news.

[marklh9]

Hi,
When running hb-shape with updated Bopomo GPOS font, I got the following result.
./hb-shape --direction t ~/Downloads/bopomo-new.otf ㄗㄠˇㄢ
[gid25=0@-500,-880+0,-1000|gid34=1@-500,-880+0,-1000|gid46=2@-500,-880+0|gid36=3@-500,-880+0,-1000]

The tone mark (gid46) has neither h advance nor v advance. Its y-offset does not look like it has been attached to an anchor. That makes the later character overlapped with the tone mark, as can be seen by hb-view. @jfkthame you mentioned that Firefox had the correct result except x-offset with updated font in #532 (comment) . How is that possible? Can you tell me how applications should render the tone mark in this case? Do I need information other than x and y offsets to render the tone mark correctly?

Sorry for these naive questions.
Best regards.

[jfkthame]

I think you need to explicitly enable the 'vkrn' feature.

[jfkthame]

(and then add --margin 200 or something like that to the hb-view command, so the shifted tone mark is visible)

[jfkthame]

FWIW, here's a sample with a "hacked" version of the bopomofo font that renders as I'd expect in both Chrome and Firefox Beta (or Nightly) .... not in current release Firefox (57) due to a bug, but that's fixed for FF 58 and later.

bopomofo-test.zip

[marklh9]

@jfkthame It also worked in LibreOffice with minor tweaks. Thank you!

[bobbytung]

Dr. Ken Lunde recommend to use OpenType GPOS 'vert' for long-term solution. So we updated test case here: https://bobbytung.github.io/BopomofoLayoutTest/

Works with Firefox 58 and Chrome 65.

Might work with LibreOffice as well. @marklh9

[marklh9]

@bobbytung The new font works fine with LibreOffice 6.0. Users do not have to set vkrn feature manually now. Thank you!

[kahsieh]

@nedley It looks like both the old vkrn and new vert test cases work correctly in Chrome and Firefox but don't work correctly in Safari (11.0.3 / 13604.5.6) on High Sierra. Do you know what's going on with Safari's attachments?

[nedley]

@kahsieh This isn’t the proper venue for discussing it. You can file a bug at bugreport.apple.com.

[kahsieh]

@nedley Thanks, will do

[behdad]

Please reopen if anything is left to be done in HarfBuzz.