From: Philippe Verdy (email@example.com)
Date: Wed May 18 2011 - 05:25:43 CDT
2011/5/18 Ken Whistler <firstname.lastname@example.org>:
> On 5/17/2011 1:04 PM, fantasai wrote:
> I'm looking for this information in order to complete this appendix:
> Well, that is part of the conceptual problem we are having here, then.
> That draft appendix refers to the concept of "vertical scripts in Unicode
> as if that concept were actually defined normatively in Unicode 6.0,
> and the problem is merely acquiring the precise listing somehow.
> But Unicode 6.0 (or any earlier version) does *not* define "vertical
> This is handled better in the css3 text by the beginning of Section 5,
> which divides scripts into three types, defined right there:
> horizontal-only Scripts that have horizontal, but not vertical, native
> Includes: Latin, Arabic, Hebrew, Devanagari
> vertical-only Scripts that have vertical, but not horizontal, native orientation.
> Includes: Mongolian, Manchu
> bi-orientational Scripts that have both vertical and horizontal native orientation.
> Includes: Han, Hangul, Japanese Kana
> I think the horizontal-only definition is fine.
I don't think so. There's still the need to make a distinction between
scripts that have a horizontal-only "native" orientation.
- Latin (also Greek, Cyrillic, Coptic, Hebrew and many others) can
still have two types of "non-native" vertical orientation : with or
without rotation (and without rotation there are still some specific
issues when rendering some small groups of characters like pairs of
- Arabic (including the specfic Urdu style which has its own
presentational features regarding alignment) and Devanagari and a few
others, can only be rotated when rendered vertically, due to their
These same "joining" scripts are also concerned with the issue of
justification. For example how to insert kashidas and how to align
them (this is more complex with the Urdu style in the Arabic script).
I'm not even sure that the current OpenType specifications are
sufficient to handle this last case consistantly with all font
families and styles for joining scripts, and it would probably be
simpler to just elongate or condense complete horizontal spans of text
using a transform matrix (but with a bad effect on weight, that could
be corrected by using an inverted matrix before applying font hinting,
but then with issues regarding the caching of prerendered glyphs...)
But then, if we want to be more complete, there's also a similar case
with Latin, Greek, Cyrillic, and others in the first subcategory
above, if they are rendered in a cursive (joined) style: a
justification only based on spacing or repositioning of individual
glyphs will not work. Can a CSS implementation detect when a font uses
a cursive or joining style, and adapt its rendering algorithm ?
Note that justification does not affect much the horizontal-only
scripts that are to be rendered vertically without rotation. We could
still assume that document authors will not want to use this style
with cursive fonts or joining scripts.
But there's currently no warranty that this will not happen (due to
the way the fonts families are tested, and the possible presence of
font fallbacks). How can we then ensure that the rendered text will be
readable ? Can the renderer reliably autodetect the cursive/joining
type of the selected font without some additional properties encoded
in fonts themselves ? If not, how to restrict the use of full
justification between pairs of glyphs using uniform kerning ?
This archive was generated by hypermail 2.1.5 : Wed May 18 2011 - 05:29:14 CDT