<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 10/5/2011 2:18 PM, Thomas Phinney wrote:
<blockquote class=" cite"
id="mid_CAO6Fj1V5gAoymTJZK5UHEOhzupDUn-z1FWrJMuv3zRv6HnEv4A_mail_gmail_com"
cite="mid:CAO6Fj1V5gAoymTJZK5UHEOhzupDUn-z1FWrJMuv3zRv6HnEv4A@mail.gmail.com"
type="cite"><font face="verdana,sans-serif">Any chance somebody
like you, who is intimately familiar with all the moving parts
involved, could summarize the implications for fonts?</font></blockquote>
<br>
Let me give it a try.<br>
<br>
<br>
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, <a class="moz-txt-link-freetext" href="http://www.w3.org/TR/jlreq/#fig1_20-en">http://www.w3.org/TR/jlreq/#fig1_20-en</a>; 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).<br>
<br>
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'.<br>
<br>
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).<br>
<br>
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.<br>
<br>
Long time readers of this list will have an impression of déjà vu:
bidi mirroring. <br>
<br>
<br>
I think the specific requirements are:<br>
<br>
- the document author can control the orientation of any character
occurrence; the implication for us is that fonts cannot impose the
orientation.<br>
<br>
- 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)<br>
<br>
- 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)<br>
<br>
In addition, I would much prefer that we also satisfy the general
requirement:<br>
<br>
- layout engines do not have rely on whether a GSUB feature has
replaced a glyph or not<br>
<br>
<br>
My proposal would be:<br>
<br>
- 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.<br>
<br>
- 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.<br>
<br>
- 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<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
<br>
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.<br>
<br>
<br>
<br>
Two more points: <br>
<br>
- 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.<br>
<br>
- 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)<br>
<br>
<br>
Eric.<br>
<br>
<br>
</body>
</html>