[mpeg-OTspec] Fwd: Proposed Draft UTR #50, Unicode Properties for Vertical Text Layout now available

[Eric Muller]

On 10/5/2011 2:18 PM, Thomas Phinney wrote:
> Any chance somebody like you, who is intimately familiar with all the 
> moving parts involved, could summarize the implications for fonts?

Let me give it a try.


Most characters have the same "shape" in horizontal and vertical text, 
with the only difference between horizontal and vertical being that the 
orientation of the character may be different. In a typical Japanese 
text, the kana remain upright in vertical lines, while latin characters 
will sometimes appears sideways. See Figure 25 of JLREQ, 
http://www.w3.org/TR/jlreq/#fig1_20-en; in that case, a typical layout 
engine will simply use vmtx and align the y axis of the design space 
with the line for the kana, and use hmtx and align the x axis of the 
design space with the line for the latin. In short, some glyphs are 
rotated and other are not (which are rotated depend on your choice of 
coordinate system for the line.) While the rotation is mostly 
predictable on a character basis, there are few characters which can be 
used in both orientations (e.g. U+00AE ® REGISTERED SIGN can follow 
kana/kanji or sideways latin, and should accordingly be upright or 
sideways).

A few characters have a different shape between horizontal and vertical. 
For example, U+301C 〜 WAVE DASH is not only shown sideways, but it's 
also mirrored; or the arrangement of the kanas in U+3300 ㌀ SQUARE 
APAATO is changed so that they read as two vertical lines rather than 
two horizontal lines. TR50, section 5.4, shows representative glyphs in 
horizontal and vertical lines for all those cases. A layout engine 
cannot achieve those transformations on its own, and in OpenType, we 
really want to have a GSUB feature that does that. In fact, we have one, 
'vert'.

If you look at 'vert' in typical fonts, you will see that when a glyph 
is substituted, the substitute incorporates a rotation of the ink, not 
just an adaptation (i.e. not just the mirroring for U+301C). The layout 
engine must use the vmtx of the resulting glyph and must align the y 
axis of the design space with the line. In fact, the rotation is all 
that is done for a number of characters (e.g. the brackets).

What we end up with are two places where the rotation can be made: the 
layout engine could do it, and the font could do it. Of course, if both 
do it, or neither do it, we end up with the wrong answer. In other 
words, we need some cooperative work between layout engine and fonts, 
and the current description of 'vert' does not provide that, and current 
fonts do different things.

Long time readers of this list will have an impression of déjà vu: bidi 
mirroring.


I think the specific requirements are:

- the document author can control the orientation of any character 
occurrence; the implication for us is that fonts cannot impose the 
orientation.

- on the other hand, fonts need to be able to select "ink" appropriate 
for vertical text, for any character (and not just those where a 
different ink is absolutely necessary)

- we need to get good results with existing fonts (i.e. we cannot ignore 
the existing 'vert' implementations and start from scratch with an 
entirely new approach). On the other hand, it's a non-requirement to 
work with a font which is not designed from vertical use at all (e.g. 
has no vmtx)

In addition, I would much prefer that we also satisfy the general 
requirement:

- layout engines do not have rely on whether a GSUB feature has replaced 
a glyph or not


My proposal would be:

- layout engines apply the 'vert' feature to glyphs resulting from 
characters with the UTR#50 East Asian Orientation property value T, and 
possibly to the SB as well. They have to use the vmtx metrics and align 
the y axis of the design space for the glyphs, regardless of whether 
'vert' changed the glyph or not.

- layout engines can obey the author's request for a specific 
orientation for the other characters, just by selecting htmx or vmtx 
metrics and doing the corresponding axis alignment.

- to give the font control over the ink, we need a new feature (or may 
be two), to be applied to upright (or upright and sideways respectively) 
glyphs. This feature will be constrained to *not* include any rotation, 
so that the layout engine does not have to do different things if the 
font decided or not to modify the glyph

The key here is that the 'vert' implementations are very consistent 
across fonts *on the T and SB characters*.  They all transform, they all 
include a rotation. Of course, we will need to update the description of 
'vert' to capture that common behavior.

While in principle we need two new features (somehow, the font has to be 
informed of the final orientation of the glyph), it is quite possible 
that we would discover that there is not a compelling reason to modify 
the ink of sideway glyphs.



You may also recall 'vrt2'. I think this is not really usable here. That 
feature was meant to relieve the layout engine of any decision about 
rotation (apply it, always use vmtx), and put the font entirely in 
control. Consequently, the first requirement is impossible to satisfy, I 
think.



Two more points:

- IMHO, the notion of vertical line is not exactly the same as "a line 
presented vertically in its frame". A column header may simply be an 
horizontal line that rotated. Also, I have an example of a Japanese 
book, written vertically, where most of the lines are vertical lines, 
but a few are horizontal lines stacked along with the vertical lines. 
Those few lines contain many formulas and would simply not work if built 
as ordinary vertical lines. You end up with horizontal shapes in those 
lines. Of course, there is a strong correlation between the paragraph 
stacking and the inside of the lines.

- furthermore, vertical line means different things in different places. 
In English, all the letters are upright in a vertical line (think shop 
signs; and yes there is an occasional TCY [tate chu yoko, horizontal in 
vertical] for short words)


Eric.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20111006/116bf6c2/attachment.html>