Bug 86071

<rdar://problem/11422958>

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

Created attachment 142117 [details] testcase, test text orientation with various other property settings

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.

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.

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

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.

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.