[Webkit-unassigned] [Bug 86071] Incorrect behavior of upright text in vertical writing modes

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=86071





--- Comment #5 from Koji Ishii <kojiishi at gmail.com>  2012-05-16 01:02:09 PST ---
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.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.