[XeTeX] Problem with font features in tables

[Ross Moore]

Hi Will, and Michael,

On 04/02/2009, at 12:19 PM, Will Robertson wrote:

> On 2009-02-04 05:04:12 +1030, "Michael Lynch"
> <michael.s.lynch at googlemail.com> said:
>
>> \newcommand{\fullcaps}[ 1
>> ]{{\addfontfeatures{Letters=Uppercase,Numbers=Uppercase} 
>> \MakeTextUppercase{#
>> 1}}}
>>
>> These both seem to work fine, particularly when used in body text.
>
> By the way, in this case, you don't need the "Letters=Uppercase"
> feature; few fonts support it and \MakeTextUppercase does the same
> thing for you anyway.
>
>> However, for my document, they are both used for the first time in  
>> a table.
>> The problem occurs when my "fullcaps" command has not been used in  
>> the body
>> text first. If I run it on my sample document (Test.tex), it does not
>> produce "full caps" numerals as I'd expect. If however, I include a
>> \phantom{\fullcaps{}} command prior to the first table, it works  
>> as I'd
>> like! This isn't a problem to do, and seems to have no effect on  
>> the final
>> layout, but I wondered if anyone could explain why it does this?
>
> Hmmm. This is REALLY REALLY weird.

No, it's not that weird.

Here's an observation that may help you sort it out.

BTW, I've done some testing using Cambria font,
which has all the features that Michael used.

The original call to  \setmainfont[...]{Cambria} results
in a \font\<font-csname> = ....  call, where

   \<font-csname>  is  \EU1/Cambria(0)/m/n/10 .

Then the call to  \abbracr  results in a cs-name of

    \EU1/Cambria(1)/m/n/10

If this call to  \abbracr  was made in the body-text,
then the subsequent  \fullcaps would use

    \EU1/Cambria(2)/m/n/10

BUT,
  when the  \abbracr  was scoped to the table-cell,
  then the subsequent  \fullcaps  tries to reuse

    \EU1/Cambria(1)/m/n/10

This is a font cs-name that has a non-empty value,
so the \font command is not issued, and you just get
the same attributes as were used with  \abbracr .


With \tracingall  declared, you can see the font cs-names
being generated --- if you can bear trudging though the
enormous  .log  file that results.


> The problem only happens with tabularx, not tabular.

Hmm; you're right, and that is quite curious.
The different behaviour may have something to do with
the fact that the contents of a cell in  tabularx
get read 3 times !!


>
> I'm going to have to look into it...and it might be a while until I  
> get to it.

You'll need to look at how that number (0) or (1) or (2)
is generated. Something is of local scope when it needs
to be \global .

>
> Thanks for letting me know,
> Will

Hope this helps,

	Ross

------------------------------------------------------------------------
Ross Moore                                       ross at maths.mq.edu.au
Mathematics Department                           office: E7A-419
Macquarie University                             tel: +61 (0)2 9850 8955
Sydney, Australia  2109                          fax: +61 (0)2 9850 8114
------------------------------------------------------------------------