I'd like to share some updates on CSS Writing Modes Level 3 at the CSSWG F2F last week with whom interested in.
Last June, the CSSWG resolved to refer Unicode UTR#50[1] for glyph orientation rules in vertical flow. We have been working with UTC since then, but as it turned out to be a much bigger work than originally expected, and as the Asian market for vertical flow emerges, the WG resolved to define its own glyph orientation rules in the CSS Writing Modes Level 3 specification. We expect this work to be quick in order to prevent un-interoperable contents and products spread widely. We will also work with UTC so that it is as much compatible with future UTR#50 as possible. Once the spec is done, some Japanese e-book reader vendors are going to implement the spec in their fork of WebKit. If no one here is working on it at the point when their work is done and is stabilized, I'd like to seek for the possibility of upstreaming their patches. They're currently busy to ship their products and are not trying to meet the quality criteria WebKit requires, but I think we can manage it to work out. I'd appreciate reviewers' support at that point in advance. =================== UPRIGHT IN COMPLEX CODE PATH Please allow me to take this opportunity to share my thoughts on one open issue in the current implementation; vertical flow + upright orientation + complex code path. This is going to be long and probably not of everyone's interests, please skip if this is not of your interests. CSS defines two glyph orientations: sideways and upright. There are more values defined in the text-orientation property[2], but those values are a mix of the two, so you can assume that these two orientations are the primitives. On the implementation side, WebKit uses two code paths to render text: simple and complex. WebKit uses complex code path when a run contains complex scripts, or when the text-rendering property[3] is set to optimizeLegibility. The combination of these two variables results in 4 code paths. Sideways in either code paths are rather simple. We can render by applying affine transforms against horizontal text flow. There are some issues in baseline and text-decoration and such, but you're mostly done. Upright in simple code path is for East Asian typography. It requires some additional code in each port. Mac port has implemented this, and I've submitted patches for Apple Win[4] and Chrome Win[5]. (currently I'm waiting for reviews for bugs that block these patches, appreciate your supports on this! :) The last combination -- upright in complex code path -- is an open issue if I understand correctly. LayoutTests/fast/writing-mode/text-orientation-basic.html indicates that we do not support this combination yet (it says the test is expected to fail,) and my patches mentioned above don't support it either (I wrote this in the bug comments.) There are a few levels of technical difficulties to make this combination to work. Also market demands for this combination isn't high (at least in Asian scripts, I'm not very familiar with markets in complex scripts, so I may be wrong here) so I think it makes sense to postpone this issue until we have a good solution. The good solution I think requires a couple of things to happen. First, we have to figure out what the correct behavior is. This is still under discussion in CSSWG and in Unicode. CSSWG may put something we believe is appropriate at some point into the spec, but I think it's quite possible that Unicode may figure out more issues later and it may change when UTR#50 goes final. Unicode may even find issues after final and produce following revisions. It's quite usual for UTC/UAX to find issues later and updates revisions. Given such situation, in the "quick" work CSSWG is going to make, I personally don't expect we can come up with the correct specifications (note that this is my personal view, not the view of the CSSWG.) But within a certain amount of time, I hope CSSWG and Unicode can come up with a good spec together. Second. Once we figured out the correct spec, there's an implementation issue. Currently, WebKit relies on external shaping engines to layout glyphs in complex code path. In short, shaping engines work like this: WebKit passes a run of text, baseline, and font handle to the shaping engine. The shaping engine then reads font tables and do the calculations to return the position of each glyph, so that WebKit can render glyphs correctly. In this model, since it's the shaping engine who decides where to put glyphs, it's not easy for WebKit to set glyph positions for the upright orientation. We need to change the way the shaping engine calculates the positions. There's an API boundary issue here. One possible solution to fix this quickly is, we could split a run into grapheme clusters, pass each to shaping engines, and transform the returned positions before we render. We also need to reverse the order (to bottom-to-top) depending on the directionality. This is what we think is the right behavior at this point, but I'm not very positive to take this fix. This fix breaks the API boundary, and requires all ports to copy the code. Also as I wrote above, I think there will be more spec issues to figure out, and it's quite possible that future UTR#50 may come to different conclusions. The right way to fix this issue I believe is to fix the shaping engine to support upright orientations. This is probably doable for most Linux ports where shaping engines are also open source, such as Harfbuzz. But this is a challenge for OS X and Windows where we do not have control over. On OS X, ATSUI is deprecated and the functionality is moving to Core Text, which supports both complex scripts and Asian vertical flow today. Core Text doesn't support this combination today though. I don't know what the OS X's plan is in this regard, but I hope someday OS X can support the combination, and I think it's fair to wait for that. Windows is in a little more complex situation. Uniscribe, the Microsoft's shaping engine Apple/Chrome Win ports use, is deprecated and Microsoft is moving to DirectWrite. Since guys from DirectWrite are working on UTR#50, it's quite likely that future versions of DirectWrite support this combination. Once that happened, Chrome Win uses GDI + Uniscribe today, so it has to move to DirectWrite to fix this issue. The work is under discussion[6][7]. Hopefully, by the time DirectWrite supports upright complex scripts, Chrome Win can finish the move. Apple Win is in a little more complex situation because it uses Core Graphics + Uniscribe today. It has to figure out which option works the best; port Core Text to Windows, move to DirectWrite and figure out how it can work well with Core Graphics, switch to other shaping engines such as Harfbuzz, or entirely move to DirectWrite. It's probably too early to make the decision because there are too many unknown factors at this point. So. In summary, I think we should postpone support for vertical + upright + complex code path for now. This may results WebKit-based browsers to fail some tests in CSS Writing Modes when it comes, but I suspect there's no big demand here and we do not have to worry about such documents spread quickly. On the other hand, we need to keep working on the future directions for how to support this feature. Once all these are figured out and worked out, I think we can also eliminate the two code paths and merge them into single code path. That'd be a little long way though. Thank you for reading a long mail, I'd appreciate feedbacks if any. [1] http://www.unicode.org/reports/tr50/ [2] http://dev.w3.org/csswg/css3-writing-modes/#text-orientation [3] http://www.w3.org/TR/SVG/painting.html#TextRenderingProperty [4] https://bugs.webkit.org/show_bug.cgi?id=48459 [5] https://bugs.webkit.org/show_bug.cgi?id=51450 [6] https://bugs.webkit.org/show_bug.cgi?id=83512 [7] http://code.google.com/p/chromium/issues/detail?id=124406 Regards, Koji _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
