RE: [css3-writing-modes] The original issues of font-dependent glyph orientation

I heard from Taro that the current draft has T, and along with your explanation, I started to understand what you’re trying to do. If I understand correctly, that can make consistent glyph orientation without relying on font information, and it’s great if it works flawlessly.

If I understand correctly, you want, say, U+FF08 FULLWIDTH LEFT PARENTHESIS to set S, correct?

A few concerns came up in my mind:

1.    U+30FC KATAKANA-HIRAGANA PROLONGED SOUND MARK requires both rotation and transformation, so UA has to render it upright and font must have vert GSUB to render it correctly. Maybe this is the only exception?

2.    Font designers had freedom to adjust glyphs for vertical flow today, and your proposal let them give up doing so in some code points, right? They can change glyphs for U and T, but not for S (is U allowed to change?) I’m going to try to figure out if it’s really okay with them. For instance, if U+FF08 is S, they can no longer adjust shapes of parenthesis in vertical flow. I don’t have good idea how much real use cases there are, but I suppose it’s worth to figure out.

3.    It doesn’t work with non-square fonts, does it? Does it work with 10% narrow fonts, or proportional fonts like Kazuraki?

Maybe I went too far as I haven’t seen the draft yet.

I’m kind of mixed feelings about this. It’s really great to have a spec like UTR 50, and your idea seems to be great. I’m honored to be in the loop of such a great discussion. On the other hand, John Daggett said it’s going to finish within a few months, but given its impact and given feedback from typographers tend to take long, I’m worried CSS takes really long to reach stable state. Since EPUB is shipping, if CSS takes long to be stable, contents and implementations without interoperability can spread out very fast. It’s actually starting, people just take the current WebKit and says it’s EPUB3 compatible. Web-based ebook readers appearing supporting only WebKit. In that sense, I wish CSS Writing Modes Level 3 takes quick and less impact spec, and do the ground-breaking job in Level 4.

Well, it’s CSS/EPUB story, I’m not sure how much you participate in them. I just wanted to share my thoughts with you.


Regards,
Koji


From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf Of Eric Muller
Sent: Saturday, October 01, 2011 7:09 AM
To: www-style
Subject: Re: [css3-writing-modes] The original issues of font-dependent glyph orientation

On 9/28/2011 11:22 AM, Koji Ishii wrote:

If you look at font tables[1], they match to their input systems; MS Gothic, Meiryo, and Kozuka Gothic on Windows has vert feature for U+2015 but not for U+2014, while Hiragino on Mac has vert feature for U+2014 but not for U+2015.

My take is that the 'vert' feature is ill-defined, but that we need to implement a decent layout on top of it, the way it is today. (there are other similar cases, e.g. U+00B0 ° DEGREE SIGN, which do not have the added complication of the confusion between U+2014 and U+2015).

My proposal is essentially to restrict the application of 'vert' to those cases where it is absolutely necessary (e.g. square katakana, ideographic stop, etc), and in particular not use it for the dashes where it's not that useful. Hopefully, all the common fonts have done (in the same way) the cases where it's absolutely necessary to go through a feature, and differ only on those cases where we don't really need to apply 'vert'.

In more concrete terms, the UTR 50 draft now has three orientations: U, S, and T (for Transformed). T is for square katakana symbols, the weavy dash and a handful of others. The T are defined purely in terms of Unicode. Think in terms of Unicode code charts: What the charts show today is a representative glyph for horizontal lines.  Let's say we want to produce the code charts for vertical lines: most cases will the same glyph either Upright (=as is) or Sideways (= rotate 90 degree clockwise), but a few are Transformed.

Not surprisingly, the 'vert' feature does the same thing on Ts in all fonts (well, all those that support vertical Japanese text). So restricting 'vert' to the Ts gives a reliable system.

This will also give us decent layout. We can get great layout by adding a new feature, which will be restricted to change the shape of glyphs but not incorporate a rotation aspect. Because of that restriction, this new feature can be applied liberally and give a lot of freedom to the font designer, without putting the layout engine in a loose-loose situation.

Note that 'vert' does not have this restriction of "free to change the shape, but do not rotate". This is precisely what makes it so hard to use when it's not done the same across fonts. Since we cannot come back on that, we have to either use 'vert' only in the most restricted circumstances, or to react to whether it actually changed the glyph (which I find way too problematic).

Eric.