W3C home > Mailing lists > Public > www-style@w3.org > October 2011

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

From: fantasai <fantasai.lists@inkedblade.net>
Date: Mon, 03 Oct 2011 17:31:03 -0700
Message-ID: <4E8A53C7.6050302@inkedblade.net>
To: www-style@w3.org
On 09/30/2011 03:08 PM, Eric Muller wrote:
> 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 approach makes a lot of sense to me.

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

Great. I remember discussing this issue with Nat back in July. :)

If I understand correctly, this means legacy fonts (which would be, all the fonts
in existence today) would not be using most of their 'vert' glyphs, but that going
forward we will have a reliable, understandable system for vertical typesetting.
If so, I believe this is the right approach for Unicode.

It does leave open the question of how typesetting systems are to deal with legacy
fonts, which do not support the new feature and are expecting 'vert' to be applied
more liberally. But having Unicode define a clean forward path here does scope the
problem for us to a more manageable level.

Received on Tuesday, 4 October 2011 00:31:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:05 UTC