86071 2012-05-10 01:59:24 -0700 Incorrect behavior of upright text in vertical writing modes 2017-07-11 18:47:00 -0700 1 1 1 Unclassified WebKit Text 528+ (Nightly build) Unspecified Unspecified UNCONFIRMED http://people.mozilla.org/~jdaggett/tests/text-orientation-with-ligatures.html InRadar P2 Normal --- 93304 0 eoconnor webkit-unassigned itshustletime jdaggett kojii phiw2 siqinbilige webkit-bug-importer oldest_to_newest 620385 0 eoconnor 2012-05-10 01:59:24 -0700 See the test at the linked URL. In vertical writing modes, upright text should be centered [the text in (2) is incorrectly aligned to the left]. In vertical writing modes, upright text should remain upright, even when the author has enabled ligatures with text-rendering: optimizeLegibility or with font-feature-settings [(4) and (5) exhibit the incorrect behavior]. 620387 1 webkit-bug-importer 2012-05-10 02:00:19 -0700 <rdar://problem/11422958> 624092 2 kojii 2012-05-15 08:02:03 -0700 This is a tough one. I can't see the file at URL right now due to 500 error, I can come back to check later, but here're some quick info. text-rendering: optimizeLegibility lets WebKit use complex code path, and a test[1] indicates that it requires a fix in Core Text: > The complex text code path mis-renders because of API deficiency. > There is no way to tell CoreText to use upright horizontal glyphs > when rendering a vertical line. One possible fix is not to use complex code path if vertical flow and upright even if text-rendering is set to optimizeLegibility, but I haven't look into its other implications yet. If this fix has some undesirable side-effect and therefore is not applicable, we have to find a way to fix upright in complex code path, but this is really a tough one. OS X needs Core Text to fix as mentioned above. Complex code path is likely to fail on Windows too, because Uniscribe, the shaping engine we use in complex code path, has the same limitation as Core Text, but I don't think MS is going to fix this because Uniscribe is already deprecated. Probably we have to move on to DirectWrite, the successor of Uniscribe, or other open source shaping engine. If we go this way, I guess it'll be a long way. For font-feature-settings, I can't see which value the test file is using, but from what I heard from John before, I suspect it's about ligatures. This is also a tough one in regards to figuring out the correct behavior. 1.3.4 of Adobe Technical Notes #5901[2] says: > Although the conventional ordering of these features is ‘liga’ > followed by ‘vert’ and ‘vrt2’, this font’s vertical-only hiragana > ligatures necessitates a different ordering, specifically ‘vert’ > and ‘vrt2’ followed by ‘liga’. so the order of 'liga' and 'vert' are font-dependent, at least in some fonts. I asked this to a guy who created this font before, but didn't get back yet. I'll check with him again. [1] http://svn.webkit.org/repository/webkit/trunk/LayoutTests/fast/writing-mode/text-orientation-basic.html [2] http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/font/pdfs/5901.Kazuraki_Tutorial.pdf 624823 3 142117 jdaggett 2012-05-15 18:31:51 -0700 Created attachment 142117 testcase, test text orientation with various other property settings 624841 4 jdaggett 2012-05-15 18:48:01 -0700 Koji, the bug here is the inconsistency between the different modes and fonts, the orientation changes based on whether features that enable "complex" rendering mode are enabled or not and whether the font is judged to be "Japanese" or not. Whether the 'fi' ligature shows in the upright case isn't really the issue here. I think you're jumping to conclusions that this is necessarily a bug in CoreText/Uniscribe. My guess is that it has to do with the Webkit code that is calling those API's. In general, font features are executed in the order given in the font. But that's not the issue here. 625105 5 kojii 2012-05-16 01:02:09 -0700 Got the file, thank you for attaching. (In reply to comment #4) > Koji, the bug here is the inconsistency between the different modes and fonts, the orientation changes based on whether features that enable "complex" rendering mode are enabled or not and whether the font is judged to be "Japanese" or not. Whether the 'fi' ligature shows in the upright case isn't really the issue here. Maybe I still don't get what issue you want to discuss in this bug, since there are several problems mixed in the test file. Which one are you talking about? Since I'm not sure if I understand the above sentence (sorry, due to my English skill,) please allow me to go through: #1 is ok, right? #2 is left aligned on Mac, look fine on Windows + bug 48459. I guess this is a bug in Mac port. #3 is ok, right? It uses complex code path, but still ok because it doesn't apply upright. #4 behaves differently between Mac and Win. Both are broken in different ways, but this is the one I mentioned. Not using complex code path when vertical + upright + optimizeLegibility is a possible fix but I'm not sure if that's the right fix as written above. Otherwise we need CT/Uniscribe support to fix this. #5 is broken differently on Mac and Win. I didn't know WebKit supports font-feature-settings already, this could be the same bug as #2 or different bug, I'm not sure at this point. It renders the same as #2 on Mac but differently on Win. So, it looks to me that #2 and #5 are probably easy fix at platform level code, and probably fixes are different and therefore they're separate bugs. #4 is yet another bug, the tough one I mentioned below. For #2, calculating glyph position offset in upright orientation relies on CT on Mac port, and Win port reads OpenType tables directly because of the lack of such API, so this could possibly a bug in CT. I guess #5 will be ok on Mac if #2 was fixed, but we need another fix for #5 on Win. I can't make a good connection between what you wrote above and the view I looked as above. What did I miss? WebKit categorizes each font to one of two categories by if the font has vertical metrics or not. And if it tries to draw CJK code points using fonts without vertical metrics, it does a little hack so that it can render good on some Chinese fonts. But it doesn't do things differently by whether a font is Japanese or not. Is this the question you're asking? > In general, font features are executed in the order given in the font. But that's not the issue here. Oh, I didn't know that. I looked for OT specs without luck to find the ordering. Thank you for telling me about this. 625116 6 jdaggett 2012-05-16 01:27:01 -0700 As noted in the testcase text, the bugs shown in the testcase are: 1. The text orientation of the letters "ABC" are different in (4), (5) compared to (2) 2. In (4) and (5), the orientation of "Tow" varies based on the font (with Hiragino Mincho, sideways, with Times, upright) 3. The glyphs for "final" in (2) should be centered 625203 7 kojii 2012-05-16 02:57:32 -0700 Thanks for the clarifications. I looked into further. #2 turned out to be a bug in CTFontGetVerticalTranslationsForGlyphs. This API supposed to return vertical origins, but its X component of return value is incorrect for some glyphs (probably proportional glyphs?) if the font has vertical metrics. We could either wait OS X to fix this bug, or disregard X position of the returned value and calculate by ourselves. Note that the API returns values for font-size of 1 on Snow Leopard and we have a workaround for the bug, but this bug reproduces on both Snow Leopard and Lion. Also note that this looks good on iOS Safari, maybe iOS doesn't use the API, or the API on iOS doesn't have the bug. #4 is complex code path + upright combination. The current implementation really doesn't support this combination well. #5 shows different results by builds. A patch was landed to switch to the complex code path by setting any font feature settings on last August, so it used to behave the same as #2 but it's now the same issue as #4. On OS X, complex code path + upright hits CT bug. On Windows, it hits Uniscribe limitations. This is a separate issue from #2. We could either workaround not to use these APIs on such cases, or wait for these APIs to fix. 625256 8 kojii 2012-05-16 04:22:35 -0700 I hope it's already clear but I guess I should add a note that, orientation is inconsistent in #4/#5 because we really can't render it correctly, and Mac is currently falling back to sideways in that case. Win doesn't do the fallback and results in glyph overlaps. It's a side effect of the root problem, and is not intentional. 142117 2012-05-15 18:31:51 -0700 2012-05-15 18:31:51 -0700 testcase, test text orientation with various other property settings text-orientation-with-ligatures.html text/html 2655 jdaggett PCFET0NUWVBFIEhUTUw+CjxodG1sPgo8aGVhZD4KPHRpdGxlPnRleHQtb3JpZW50YXRpb24gdGVz dDwvdGl0bGU+CjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9o dG1sOyBjaGFyc2V0PXV0Zi04IiAvPgogIAo8c3R5bGUgdHlwZT0idGV4dC9jc3MiPgoKYm9keSB7 CiAgbWFyZ2luOiA1MHB4OwogIGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBGdXR1cmEsIFZlcmRhbmEs IHNhbnMtc2VyaWY7Cn0KCmg0IHsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgfQoKZGl2LnZlcnRpY2Fs IHsKICBtYXJnaW4tdG9wOiAyZW07CiAgaGVpZ2h0OiAxODAwcHg7CiAgLXdlYmtpdC13cml0aW5n LW1vZGU6IHZlcnRpY2FsLXJsOwp9CgpkaXYudmVydGljYWwgcCwgcC5ob3Jpem9udGFsIHsKICBm b250LXNpemU6IDYwcHg7CiAgZm9udC1mYW1pbHk6IEhpcmFnaW5vIE1pbmNobyBQcm9OLCBNZWly eW87CiAgbWFyZ2luLWxlZnQ6IDFlbTsKfQoKc3Bhbi50aW1lcyB7CiAgZm9udC1mYW1pbHk6IFRp bWVzLCBzZXJpZjsKICBjb2xvcjogIzA2MDsKfQoKc3Bhbi5yZWQgeyBjb2xvcjogcmVkOyB9CnNw YW4uZ3JlZW4geyBjb2xvcjogZ3JlZW47IH0Kc3Bhbi5vcmFuZ2UgeyBjb2xvcjogb3JhbmdlOyB9 CgpzcGFuLm51bWJlciB7CiAgZm9udC1mYW1pbHk6IEhpcmFnaW5vIEtha3UgR290aGljIFByb04s IE1laXJ5bzsKICBmb250LXdlaWdodDogYm9sZDsKfQoKI3Rlc3QxIHsKICAtd2Via2l0LXRleHQt b3JpZW50YXRpb246IG5vcm1hbDsKfQoKI3Rlc3QyIHsKICAtd2Via2l0LXRleHQtb3JpZW50YXRp b246IHVwcmlnaHQ7Cn0KCiN0ZXN0MyB7CiAgdGV4dC1yZW5kZXJpbmc6IG9wdGltaXplTGVnaWJp bGl0eTsKfQoKI3Rlc3Q0IHsKICB0ZXh0LXJlbmRlcmluZzogb3B0aW1pemVMZWdpYmlsaXR5Owog IC13ZWJraXQtdGV4dC1vcmllbnRhdGlvbjogdXByaWdodDsKfQoKI3Rlc3Q1IHsKICAtd2Via2l0 LXRleHQtb3JpZW50YXRpb246IHVwcmlnaHQ7CiAgLXdlYmtpdC1mb250LWZlYXR1cmUtc2V0dGlu Z3M6ICJsaWdhIiBvbjsKfQoKPC9zdHlsZT4KCjwvaGVhZD4KPGJvZHk+Cgo8aDQ+VGV4dCBPcmll bnRhdGlvbiB0ZXN0czwvaDQ+CjxwPkV4YW1wbGVzOiAKKDEpIDxzcGFuIGNsYXNzPSJyZWQiPmRl ZmF1bHQ8L3NwYW4+IAooMikgPHNwYW4gY2xhc3M9ImdyZWVuIj51cHJpZ2h0PC9zcGFuPiAKKDMp IDxzcGFuIGNsYXNzPSJyZWQiPmRlZmF1bHQ8L3NwYW4+IHdpdGggbGlnYXR1cmVzL2tlcm5pbmcg ZW5hYmxlZCAKKDQpIDxzcGFuIGNsYXNzPSJncmVlbiI+dXByaWdodDwvc3Bhbj4gd2l0aCBsaWdh dHVyZXMva2VybmluZyBlbmFibGVkCig1KSA8c3BhbiBjbGFzcz0iZ3JlZW4iPnVwcmlnaHQ8L3Nw YW4+IHdpdGggbGlnYXR1cmVzIGVuYWJsZWQgdmlhIGZvbnQtZmVhdHVyZS1zZXR0aW5ncy4KRGFy ayBncmVlbiB0ZXh0IGlzIHNob3duIHVzaW5nIFRpbWVzLCBvcmFuZ2UgdGV4dCBhcmUgZnVsbC13 aWR0aCBjb2RlcG9pbnRzLgo8L3A+CjxwPkdseXBoIG9yaWVudGF0aW9uIGluICg0KSwgKDUpIGlz IHdyb25nIGFuZCBnbHlwaHMgaW4gKDIpIHNob3VsZCBiZSBjZW50ZXJlZC4gIFRoZSBKYXBhbmVz ZSBmb250IHNuaWZmaW5nIGhldXJpc2l0aWMgaXMgc2NyZXd5LjwvcD4KPGRpdiBjbGFzcz0idmVy dGljYWwiPgo8cCBpZD0idGVzdDEiPjxzcGFuIGNsYXNzPSJyZWQgbnVtYmVyIj4mI3gyNzc2Ozwv c3Bhbj4gQUJDIFRvdyA8c3BhbiBjbGFzcz0idGltZXMiPlRvdzwvc3Bhbj4gZmluYWwgPHNwYW4g Y2xhc3M9Im9yYW5nZSI+772B772C772DPC9zcGFuPiDprYXlipsgJiN4MzMwMDsgJiN4MzM3Zjs8 L3A+CjxwIGlkPSJ0ZXN0MiI+PHNwYW4gY2xhc3M9ImdyZWVuIG51bWJlciI+JiN4Mjc3Nzs8L3Nw YW4+IEFCQyBUb3cgPHNwYW4gY2xhc3M9InRpbWVzIj5Ub3c8L3NwYW4+IGZpbmFsIDxzcGFuIGNs YXNzPSJvcmFuZ2UiPu+9ge+9gu+9gzwvc3Bhbj4g6a2F5YqbICYjeDMzMDA7ICYjeDMzN2Y8L3A+ CjxwIGlkPSJ0ZXN0MyI+PHNwYW4gY2xhc3M9InJlZCBudW1iZXIiPiYjeDI3Nzg7PC9zcGFuPiBB QkMgVG93IDxzcGFuIGNsYXNzPSJ0aW1lcyI+VG93PC9zcGFuPiBmaW5hbCA8c3BhbiBjbGFzcz0i b3JhbmdlIj7vvYHvvYLvvYM8L3NwYW4+IOmtheWKmyAmI3gzMzAwOyAmI3gzMzdmPC9wPgo8cCBp ZD0idGVzdDQiPjxzcGFuIGNsYXNzPSJncmVlbiBudW1iZXIiPiYjeDI3Nzk7PC9zcGFuPiBBQkMg VG93IDxzcGFuIGNsYXNzPSJ0aW1lcyI+VG93PC9zcGFuPiBmaW5hbCA8c3BhbiBjbGFzcz0ib3Jh bmdlIj7vvYHvvYLvvYM8L3NwYW4+IOmtheWKmyAmI3gzMzAwOyAmI3gzMzdmPC9wPgo8cCBpZD0i dGVzdDUiPjxzcGFuIGNsYXNzPSJncmVlbiBudW1iZXIiPiYjeDI3N2E7PC9zcGFuPiBBQkMgVG93 IDxzcGFuIGNsYXNzPSJ0aW1lcyI+VG93PC9zcGFuPiBmaW5hbCA8c3BhbiBjbGFzcz0ib3Jhbmdl Ij7vvYHvvYLvvYM8L3NwYW4+IOmtheWKmyAmI3gzMzAwOyAmI3gzMzdmPC9wPgo8L2Rpdj4KPHAg Y2xhc3M9Imhvcml6b250YWwiPkFCQyBUb3cgPHNwYW4gY2xhc3M9InRpbWVzIj5Ub3c8L3NwYW4+ IGZpbmFsIDxzcGFuIGNsYXNzPSJvcmFuZ2UiPu+9ge+9gu+9gzwvc3Bhbj4g6a2F5YqbICYjeDMz MDA7ICYjeDMzN2Y7PC9wPgoKPC9ib2R5Pgo8L2h0bWw+