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

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

From: Nat McCully <nmccully@gmail.com>
Date: Fri, 12 Aug 2011 11:40:01 -0700
Message-ID: <CAGf0Lus+d5KAOPzjW1FxvrhnZ+bUwCPvh9NfftPXetGQvM+RXw@mail.gmail.com>
To: Koji Ishii <kojiishi@gluesoft.co.jp>
Cc: John Daggett <jdaggett@mozilla.com>, "www-style@w3.org" <www-style@w3.org>
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.

--Nat

On Thu, Aug 11, 2011 at 11:41 PM, Koji Ishii <kojiishi@gluesoft.co.jp>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]
> http://lists.w3.org/Archives/Public/www-archive/2011Aug/att-0013/vert.htm
>
> 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?
>
> [2]
> http://dev.w3.org/csswg/css3-writing-modes/#vertical-typesetting-details
> [3] http://dev.w3.org/csswg/css3-writing-modes/#script-orientations
> [4]
> http://lists.w3.org/Archives/Public/www-archive/2011Aug/att-0014/vert.htm
>
> Regards,
> Koji
>
Received on Friday, 12 August 2011 18:40:30 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:43 GMT