RE: [css-fonts] Is it possible to select a vertical variant in a font?

I'm sorry for the late reply, I was OOF for a while.

I completely agree with John that vertical writing, tatechu-yoko, and all other usage of vertical glyphs should be part of those specifications, and should not be considered separately in CSS fonts.

I also agree that it'd cover more than 90% of cases where vertical glyphs are needed.

My case is the same as what Ken described. I want to use vertical glyphs in horizontal writing mode. It's not in vertical writing, it's not tatechu-yoko. There are few cases that might be useful, so I think designing use of the vertical glyphs as an independent feature and turning it on automatically where it's needed would be a good solution for all.

I also understand a global standard cannot cover everything, so the case this is useful may be too small and you may not want to include that in CSS. But as long as the usage is not zero, there will be people around who's going to use "@" hack and giving Mac/Linux users bad experiences.

You guys must be looking all over the world and decide which requests to take, but I wish you to keep in mind that there are some people who wish to use vertical glyphs independently from vertical writing features.

Koji Ishii

-----Original Message-----
From: Ken Lunde [] 
Sent: Friday, June 18, 2010 1:00 AM
To: John Daggett
Cc: Ishii Koji; John Hudson;; David Lemon
Subject: Re: [css-fonts] Is it possible to select a vertical variant in a font?


You wrote:

> As fantasai has already written, the use of vertical variants should 
> probably be based on the 'writing-mode' property.  Like other 
> language/script sensitive features in OpenType, using vertical 
> variants is a *requirement* for rendering vertical text in Japanese, 
> it's not a stylistic choice as is the case with other proposed 
> font-variant-xxx properties.

Correct. When the "writing-mode" property is vertical, the 'vert' (or 'vrt2') GSUB feature should be enabled for the entire run of text, and should not be a user-selected feature. The application knows when the text run is vertical, and can invoke the feature.

But, as your own needs dictate, it is convenient to be able to render vertical glyphs when the "writing-mode" property is horizontal, such as to discuss the topic of vertical writing. When I typeset "CJKV Information Processing" Second Edition, I had the advantage of being able to use InDesign's Glyph Panel to enter vertical glyphs, because there is no specific UI for applying the 'vert' GSUB feature in that application. Without the convenience of something comparable to InDesign's Glyph Panel, direct support for the 'vert' (or 'vrt2') GSUB feature would be useful.

Likewise, it'd be ideal to be able to override (or turn off) the 'vert' GSUB feature in vertical writing for selected characters, such as to display horizontal forms when the primary text run is vertical.

> How to support tatechuyoko, the display of Latin text and numerals 
> horizontally in vertical text runs, is a more subtle question.  This 
> usually involves substitution of half-width or third-width forms.
> In the example below note the rendering of '90' and '65' using 
> half-width glyphs and '100' using third-width glyphs:
> ikkei-heikin.png
> In the same example, 1 euro = 111 yen is printed with '111' displayed 
> inline (i.e. not using tatechuyoko).
> The XSL 1.1 spec defines one possible solution, adding the 
> 'tb-lr-in-lr-pairs' value of the 'writing-mode' property:
> I don't think this is quite the right solution, it misses the fact 
> that tatechuyoko is primarily used for Latin characters and numerals 
> (there are no half-width Kanji glyphs usually) and there's a 
> contextual choice of half-width/third-width forms to be made somehow, 
> either explicitly or inferred based on some rule.

I agree that tatechuyoko is a special case, and needs to be handled via different controls. The reason we added the third- and quarter-width digits to Adobe-Japan1-4 was precisely for this use.


-- Ken

Received on Friday, 25 June 2010 01:28:26 UTC