[XeTeX] Vertical writing of CJK and fontspec (rawfeature=vertical) misbehaving

[Michiel Kamermans]

Hi,

I was reading the threads on vertical writing of CJK and came across the 
fontspec [RawFeature=vertical] approach, which appeals quite a bit 
(since it involves reasonably intuitive commands). However, the approach 
discussed in 2007 breaks in two subtle ways. Firstly, when phonetic 
guide text in the form of the ruby commands, alignment is out of 
whack... I tried the following code with XeTeX, Version 
3.1415926-2.2-0.999.7 (MiKTeX 2.7), fontspec 2008/08/09 v1.18 and 
CJK/ruby 2008/12/29 4.8.2:

------ start of code
\documentclass{article}

\usepackage[overlap, CJK]{ruby}
\renewcommand{\rubysep}{0em}

\usepackage{graphics,fontspec}
\newfontfamily\cjkvert[RawFeature=vertical]{Kozuka Mincho Pro}
\setmainfont{Kozuka Mincho Pro}

\newcommand{\vertical}[1]{
\noindent
\begin{minipage}{\textwidth}
\hfill % ensure right-alignment
\rotatebox{-90}{\cjkvert #1}
\end{minipage}}

\begin{document}

This is a paragraph of regular text. It is not remarkable in any way, 
except perhaps in that it uses default western left-to-right horizontal 
typesetting.

\smallskip
\vertical{\ruby{続}{つづ}いて、これが\ruby{日本語}{にほんご}の\ruby{縦 
書}{たてが}きの\ruby{文}{ぶん}です。}

And this is another paragraph that is not remarkable in any way. It is 
followed by the previous line without rotation.

\hbox{\cjkvert \ruby{続}{つづ}いて、これが\ruby{日本語}{にほんご}の\ruby 
{縦書}{たてが}きの\ruby{文}{ぶん}です。}
\smallskip

And finally, the same line in plain old horizontal typesetting:

\ruby{続}{つづ}いて、これが\ruby{日本語}{にほんご}の\ruby{縦書}{たてが} 
きの\ruby{文}{ぶん}です。

\end{document}
------ end of code

In this, some parts of the sentence are left (or bottom?) aligned, some 
parts are top (or right?) aligned. But not in a way that seems 
consistent to me. It's not the case that only text wrapped in ruby 
commands is right-aligned, and text without it is left-aligned, for 
instance. I'm not sure what would cause this, but since the regular line 
looks fine, it might be some interplay between cjk/ruby and fontspec.

In addition, from what I can tell it also seems that fontspec is not 
applying the "vertical" concept not quite right. When I compare what 
fontspec does with the font to what the "official" vertical style is 
supposed to look like (on windows in some programs explicitly usable by 
picking the same font but with '@' in front of its name) and there are 
some differences. I have attached an image of what the font looks like 
in vertical mode according to wordpad, which is correct, and it would 
seem that the fontspec behaviour is to rotates glyphs 90 degrees inside 
their bounding box, something which for Japanese is going to yield 
exceedingly wrong results, since all interpunction, as well as 
'half-size' syllabic writing is either placed differently in addition to 
being rotated, or is scaled differently (in "きゃ", the second glyph is 
half height in horizontal writing, but will be half-width instead, and 
right-aligned, in vertical writing).

So the question is really, is something going wrong, or is this a 
'feature' and is the feature not doing what the name suggests it's 
doing? If something's going wrong, then this can be considered a bug 
report, but if fontspec's doing what it's supposed to be doing then 
there might be a bigger problem in that fontspec claims to be using a 
"vertical" feature, when instead it's using a "rotated" feature.

I'm not familiar with how windows detects that fonts have corresponding 
vertical versions (only windows fonting aware applications see that 
these exist, for instance; Open Office doesn't see them, but Wordpad and 
Photoshop do), but if this is a TTF/OTF feature that it's picking up on, 
then perhaps fontspec might need some additional knowledge of how to 
properly extract this vertical information from fonts.

Regards,

- Mike "Pomax" Kamermans
nihongoresources.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vertical.png
Type: image/png
Size: 4722 bytes
Desc: not available
URL: <http://tug.org/pipermail/xetex/attachments/20091126/1070c8ca/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.pdf
Type: application/pdf
Size: 12164 bytes
Desc: not available
URL: <http://tug.org/pipermail/xetex/attachments/20091126/1070c8ca/attachment-0001.pdf>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: test.tex
URL: <http://tug.org/pipermail/xetex/attachments/20091126/1070c8ca/attachment-0001.pl>