See the URL. According to the author, the font used in this page includes some GPOS adjustment on vertical text, but it doesn't work properly on Gecko. On WebKit/Blink, the GPOS works properly while they leave a space for moved marks.

The first problem I notice in the testcase is that the bopomofo tone marks are rendered "sideways" rather than "upright". This is because the default for 'text-orientation' value is 'mixed', and the characters used for the tones have Vertical_Orientation property 'R' in Unicode. Perhaps we should special-case this for the characters used for bopomofo tones; but in the meantime, applying text-orientation:upright will at least keep these glyphs in the proper orientation, and give some chance of OpenType features applying as intended. (While the base glyphs are upright and the tones are sideways, there's a text run boundary between them, and no reasonable way for OT features to be applied across the boundary.) Once that issue is resolved, there may well still be problems with positioning, but it's not clear to me what the correct result should be. The tone mark positioning I see in Chrome Canary doesn't look very good, to my (non-Chinese-reading!) eye. The 'vkrn' feature is clearly doing *something*, as disabling it affects the rendering, but AFAICT the text looks better *without* it applied. This seems to be the case in both Firefox and Chrome, although with the feature enabled, the two produce quite different results. Presumably at least one of them is wrong...

Probably they adjusted the font again. It rendered better in Blink when I post this bug. But, yes, making |text-orientation| upright seems to partially make things work. I'm not sure whether we should handle those tone marks specially, since I don't think they are only for bopomofo.

It's clear that we handle GPOS positional adjustments incorrectly in vertical-upright textruns. Compare testcases: (a) data:text/html,<div style="font:36px times new roman;padding:100px;">abc&%23x30e;&%23x306;&%23x308; (b) data:text/html,<div style="font:36px times new roman;padding:100px; writing-mode:vertical-rl;">abc&%23x30e;&%23x306;&%23x308; (c) data:text/html,<div style="font:36px times new roman;padding:100px; writing-mode:vertical-rl;text-orientation:upright;">abc&%23x30e;&%23x306;&%23x308; In cases (a) and (b), the diacritics stack correctly (though in (b) we clip, presumably because the overflow area isn't computed properly for the shifted diacritics). But in (c), they're positioned way off to the side, and stacked in the wrong direction.

Here's a testcase to exercise GPOS positioning (assuming Times New Roman and Arial are available -- so should work on OS X and Windows, at least). With vertical writing mode and upright orientation, the various diacritics are wildly mispositioned.

In the testcase above, note how in vertical-upright mode, the GPOS-positioned marks are incorrect; only those rendered using precomposed glyphs (the dot under b, and the hook over e) come out correct. This is admittedly a relatively obscure case, but clearly we're applying GPOS offsets incorrectly. This patch fixes things so that it renders properly even in vertical mode.