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

[css3-writing-modes] Add one more category to Appendix C Vertical Typesetting Synthesis

From: Koji Ishii <kojiishi@gluesoft.co.jp>
Date: Tue, 16 Aug 2011 11:33:16 -0400
To: "www-style@w3.org" <www-style@w3.org>
Message-ID: <A592E245B36A8949BDB0A302B375FB4E0CF5176EF8@MAILR001.mail.lan>
I fixed a couple of bugs in my script and re-generated the fixed version of the table for the glyph orientation from the current spec along with vert/vrt2 tables from major fonts[1].

By looking at the table, I'd like to propose to add one more category to the current definitions of Appendix C Vertical Typesetting Synthesis.

Current spec[2] classifies all Unicode code points into 3 categories; upright, sideways, and "upright using vertical font settings if available or sideways if they are not."

The "vertical font settings" is defined as below:

> In OpenType, vertical font settings are provided by the vhea, vmtx,
> and VORG tables, as well as the vert and vrt2 GSUB features. If any
> of these are present, the font is considered to have vertical font
> settings available.

The spec handles all these tables equally. The 'vhea' table is a font-wide table. The 'vmtx' is per-glyph, but it looks like most fonts define values for every glyph, and table structure assumes to do so. On the other hand, the 'GSUB' and 'GPOS' table (I guess we missed 'GPOS' here) have per-glyph entries, so my basic question is we should not treat all these tables equally.
The proposed fourth category is: "use vertical alternate glyphs if available, or sideways if they are not."

This is similar to the third category, but this category allows fonts to adjust baseline for sideways glyphs for specific code points.

Code points to put into this category are what people tend to think its baseline positioning is particularly important; dashes, arrows, blocks, etc.

>From the table, following code points are the candidates:
U+00B0: Only Kozuka has 'vert' for U+00B0.
U+2190-3, U+21C4-6, U+21E6-9: Three fonts have 'vert' for these.
U+2500-4A: Two or three fonts have 'vert' for these.
U+27A1, U+2B05-7: One-two fonts have 'vert' for these.

Not all fonts have 'vert' for all code points, but unlike the 3rd category, this category is safe to put these code points in terms of 'consistent glyph orientation across browser/OS/fonts', since UA can draw them sideways if GSUB/GPOS for the code point are not available.

We may also want to consider moving some of 3rd category code points to this category. An example is Pc or Pd categories. U+002D HYPHEN-MINUS is in this category, so the UA must draw it upright if the font has a 'vhea' or 'vmtx' table, but we probably don't want to do that unless the font has GSUB for U+002D.

We probably want to group them and make the definition dependent on Block or General Category rather than code points (like Pc, Pd, arrows, blocks to be in this category,) I'm going to work on more details, but I'd like to ask anyone else's opinion to this proposal.

[1] http://lists.w3.org/Archives/Public/www-archive/2011Aug/att-0017/vert.htm
[2] http://dev.w3.org/csswg/css3-writing-modes/#vertical-typesetting-details

Received on Tuesday, 16 August 2011 15:33:44 GMT

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