[XeTeX] Anomalies in using feature-enabled OT fonts

Takayuki YATO (ZR) zrbabbler at yahoo.co.jp
Sat Nov 20 10:15:11 CET 2010


Hello all,

I have found some strange behaviors in XeTex when it uses
OpenType fonts with features applied.

1. Glyph metric in (rotated-)vertical typesetting

% Here I use LaTeX only because I want to use \fbox. etc.
\documentclass[a4paper]{article}
\begin{document}
\fboxsep=0pt
\font\ixmHoriz="IPAexMincho:script=hani"                % horizontal
\font\ixmVert="IPAexMincho:script=hani;vertical;+vrt2"  % vertical
\font\ixmHorizSup="IPAexMincho:script=hani;+sups"       % superscript
\def\drawBaseline{\makebox[0pt][l]{\rule{.8\linewidth}{.4pt}}}
% The vertical font will show disastrous result.
\par\noindent\drawBaseline\ixmHoriz
\fbox{あ}\fbox{I}\fbox{一}\fbox{ヶ}\fbox{!}
\par\noindent\drawBaseline\ixmVert
\fbox{あ}\fbox{I}\fbox{一}\fbox{ヶ}\fbox{!}
% This example goes well.
\par\noindent\drawBaseline\ixmHoriz
\fbox{1}\fbox{2}\fbox{3}
\par\noindent\drawBaseline\ixmHorizSup
\fbox{1}\fbox{2}\fbox{3}
\end{document}

  When typesetting the example aboce, you will see the vertical font
  has the exactly same metric as the horizontal one, which is far
  from the reality. This problem does not seem to happen with featres
  other than vertical, as shown in the result with the superscript
  (sups) feature.

2. \fontcharwd / \fontcharht / \fontchardp

  It seems that when \fontcharwd etc. are used with feature-enabled
  fonts XeTeX seems to report the metric value in the original font
  (before the feature is applied). This behavior is against the
  specification of these commands.

% plain XeTeX
\def\measure#1{%
  #1 % print the character
  \immediate\write16{% output to terminal
    <#1>:
    wd=\the\fontcharwd\font`#1\space\space/
    ht=\the\fontcharht\font`#1\space\space/
    dp=\the\fontchardp\font`#1}}
\font\tgpNorm="TeX Gyre Pagella"       % default
\font\tgpSmcp="TeX Gyre Pagella:+smcp" % small-caps
% There two lines should not report the same measurement....
\tgpNorm\measure{a}\measure{f}\measure{g}
\tgpSmcp\measure{a}\measure{f}\measure{g}
\bye

  Compiling this source writes to terminal:

<a>: wd=5.0pt / ht=4.69pt / dp=0.0pt
<f>: wd=3.33pt / ht=7.0pt / dp=0.0pt
<g>: wd=5.56pt / ht=4.69pt / dp=2.83pt
<a>: wd=5.0pt / ht=4.69pt / dp=0.0pt
<f>: wd=3.33pt / ht=7.0pt / dp=0.0pt
<g>: wd=5.56pt / ht=4.69pt / dp=2.83pt

  Here the values appearing on last three lines are totally
  inappropriate as for small-caps glyphs, whereas the typeset
  result shows actually small-caps glyphs.

3. \XeTeXcharglyph

  The same issue as described in 2 applies to \XeTeXcharglyph.
  Because the command is specific to XeTeX, this behavior could
  be declared to be right. Buy anyway it would be nice if there
  is a way to get the right value for feature-enabled fonts.

% plain XeTeX
\def\report#1{%
  \char#1\ 
  \immediate\write16{\the\XeTeXcharglyph#1}}
\font\ixmNorm="IPAexMincho:script=latn"       % default
\font\ixmSups="IPAexMincho:script=latn;+sups" % superscript
% C should be equal to B, not A.
\ixmNorm \report{"32}% A  (U+0032:DIGIT TWO)
\ixmNorm \report{"B2}% B  (U+00B2:SUPERSCRIPT TWO)
\ixmSups \report{"32}% C
\bye

  Compiling this source writes to terminal:

21
139
21

(Attached the source files with their output results on XeTeX in
up-to-date TeX Live 2010.)

Best regards,


Tak Yato (Takayuki YATO; aka. ZR)

--------------------------------------
Yahoo! Toolbar  -  For your Internet Safety
http://pr.mail.yahoo.co.jp/toolbar2/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: example.zip
Type: application/x-zip-compressed
Size: 18569 bytes
Desc: 1208677727-example.zip
URL: <http://tug.org/pipermail/xetex/attachments/20101120/595a136d/attachment-0001.bin>


More information about the XeTeX mailing list