[XeTeX] Anomalies in using feature-enabled OT fonts

Takayuki YATO (ZR) zrbabbler at yahoo.co.jp
Sun Nov 21 10:52:45 CET 2010


> No, 
Does it mean "But XeTeX does not work on your logic"? Then it's
true, because that's that I've got :)
> the glyph at slot 97 is still normal lower case a glyph (unless
> you
> are using an old smallcaps font, but that is another story), when you
> select a +smcp or any other feature, the engine will then use the
> smallcap glyph from its slot (which is not 97 normally) whenever it
> encounters a lower case a character. The `a notation is just another
> way
> to pass numbers to TeX (the same is "XXXX notation) and it does not
> change its value when you change fonts; `a is always resolved to 97.

But I still want to note that your description is just another
logical model. Consider the following two facts:
  * Characters in XDV and PDF text streams are specified using
    glyph id, not character code (thus non-tfm fonts embedded in
    PDF always have Identity CMap).
  * The feature smcp (and other many features) acts on glyph
    sequences, again not character sequences, as the OpenType
    specification says.
>From the inspection I think the real story goes like this: XeTeX
(in its last stage of output process) converts from character code
97 to glyph id 93 by looking up the cmap table of the font, and
then if smcp feature is enabled, *glyph id* 93 is substituted by
another glyph id 1130; and finally glyph id 1130 is recorded on
the output document.

In that setting, which is the glyph id corresponding to the
character code 97 in the smcp-enabled font, 93 or 1130? I expect
the answer is 1130....

That's why I prefer the "distinct-font" model. But anyway now
I think the current behavior of \fontcharwd should not be touched
now that there are people who expect it.

Best regards,

Tak Yato (Takayuki YATO; aka. ZR)

Yahoo! Toolbar  -  For your Internet Safety

More information about the XeTeX mailing list