RE: [css3-writing-modes] "vert" OpenType feature tag and glyph orientation

Yeah, you're right and I was wrong. By looking at fonts further, I understood that glyphs in vert are supposed to be rendered at upright. I was confused by visual orientation and orientation from UA developer perspective. U+002D issue mentioned below should be handled at different levels.

Thanks for the information.


From: Nat McCully []
Sent: Saturday, August 13, 2011 3:40 AM
To: Koji Ishii
Cc: John Daggett;
Subject: Re: [css3-writing-modes] "vert" OpenType feature tag and glyph orientation

The 'vert' table glyphs are not applicable to use when the glyph is not upright. We only turn them on when we have determined the glyph is upright in vertical beforehand. A new table is the way to go, to make apps more consistent and get around poor font construction.

On Thu, Aug 11, 2011 at 11:41 PM, Koji Ishii <<>> wrote:
> The main point I was trying to make is that vertical layout shouldn't
> depend on font data, not because 'vrt2' is "wrong" so much as it's not
> consistent or it reflects an arbitrary choice made on a font by font
> basis.  What Eric and I discussed was a simple property defined for all
> Unicode codepoints that can be used to make decisions about the default
> orientation.  I think it's important to distinguish the property from the
> rules used to define default orientation, since it's easier to adjust
> rules as problems arise.
Thanks for the clarification, it helps to clarify the differences between us.

In my opinion, layout should be done in collaboration of layout apps and fonts, and as far as I understand, that's the basic concept of 'vert' table. 'vrt2' went ahead and tried to let fonts to do everything, and I guess you and Eric are trying to develop a new method in opposite side of 'vrt2' where apps does everything. I think you need a new font format or table to do that because fonts don't have all the data layout apps need, and my point is as long as we rely on 'vert' table, I think we should delegate some work to font data.

We're actually relying on font data by using vertical alternate glyphs, right? What I don't understand is what kind of benefits we're trying to pursue by ignoring some of vertical alternate glyphs defined in the fonts.

I agree that it's a good thing to develop a good rule for layout apps. But font developers should also be allowed to adjust glyphs and/or positions when they think is necessary, and my concern is current our efforts may prohibit that.

> I don't quite follow the "CSSVT" classification that you list in your
> table of Unicode codepoints [1]. You have "horizontal", "sideways",
> "sideways (default)", "upright" and "use-font".  What are the
> meaning/intent of these categories?  Basic numbers are "sideways
> (default)" but simple Latin letters are "horizontal", along with Greek
> and Cyrillic.  What's the distinction you're making?  And how are you
> distinguishing between "sideways", "horizontal" and "use-font" in the
> U+2100:21FF range of symbols.
> [1]
I'm sorry for the lack of explanations and cryptic value names. I followed all the statements in Appendix C: Vertical Typesetting Synthesis[2] and Appendix B: Bi-orientational Transformations[3], distinction of the terminologies is to know which part of the spec determined the orientation to help debug my script and the spec itself. I should make them clearer before posting, sorry about that.

I modified value names so that all code points are classified to: sideways, upright, or use-font. "use-font" means "either upright using vertical font settings if available or sideways if they are not" in the spec, and reason to determine so was moved to parenthesis. Is this clear?



Received on Tuesday, 16 August 2011 03:08:15 UTC