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

On 10/1/2011 3:16 AM, Koji Ishii wrote:
>
> 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?
>

Yes, and in fact all the brackets, fullwidth or not.

> 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?
>

Not the only one: wavy dash is also the same rotation/mirroring.

The key from the point of view of UTR50 is that it's not just the 
horizontal version upright or sideways, it's some other transformation. 
Whether that transformation can be seen as a rotation + something else 
(prolonged sound mark, wavy dash) or not (square katakana symbols, era 
names) is a distinction that UTR50 does not need nor try to go into.

Similarly, the implementations are not too concerned. It there is a 
transformation, we have to go though a feature, and all that matters to 
the layout engine is to know what orientation to use for the resulting 
*glyph* - the orientation of the *ink* in that *glyph* is irrelevant.

> 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?
>

Yes, but I propose to give them back that ability via a new feature (to 
be defined) in exchange of constraining them a bit, in such a way that 
the layout engine can guarantee the final orientation of the *ink*.

> 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.
>

'vert' is applied to T characters, the resulting *glyph* is displayed 
upright (if the ink has to look sideways, as for wavy dash and prolonged 
sound mark, then the resulting glyph must integrate that rotation, just 
as is done today in 'vert')

The new feature would be applied more liberally, to all the U glyphs. 
But we could have two features, the second being applied to the S 
glyphs; this would be the most general, we just need to figure out if we 
really need that generality.

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

I think this works, it's mostly a matter of baselines, isn't it?


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

UTR50 is not going to speak about the implications for fonts.

> 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.
>

Yes, the timing is a concern. I don't have a good suggestion. The good 
news is that UTR50 is fairly well aligned with JIS and JLREQ, so it's 
not too bad, hopefully.


Eric.