[XeTeX] Re: [MacTeX] XeTeX 0.4 available

[Jonathan Kew]

Hi Ross,

On 21 Apr 2004, at 1:27 am, Ross Moore wrote:
>
> To fit with the way LaTeX sets up the document font for all
> the usual styles and faces, then the above coding should
> probably be broken up, to appear within several different files;
> e.g.
>
> 1.  \usepackage{aatfonts}
>
> with contents such as:
>
> \renewcommand{\encodingdefault}{U}
> {\obeyspaces%
>    \gdef\ItalicShape{ Italic}%
>    \gdef\BoldFace{ Black}%
>    \gdef\SmallCaps{:Letter Case=Small Caps}%
>   ...
>   ... further stylistic declarations ...
>   ...
> }%
>

Just a heads-up, in case it isn't obvious yet (depending how many 
different fonts you've looked at): Note that the names of font styles 
and features are defined by the fonts themselves, and there is no 
guarantee that they'll be consistent between different families.

So something like \gdef\BoldFace{ Black} may work for Hoefler, but for 
most other faces, you'd want to define \BoldFace as { Bold}. But then 
you might run across a face where the regular and bold faces are 
labeled as Medium and Heavy, or whatever.

Similarly, the naming of features and settings comes from the font 
itself, and is not well standardized. Even in Apple's own fonts, I've 
seen them change over time between things like "Uppercase" and "Upper 
Case"; or a designer might give the "Small Caps" feature the name "Caps 
and Small Caps" instead. The possibilities are endless.... making it 
difficult to predefine standard names.

(Of course, this is a strength as well as a weakness; the arbitrary 
variations may be just a nuisance, but the fact that all this is 
defined by the font designer gives tremendous flexibility, with the 
ability to create and use and expose in the user interface all sorts of 
features that Apple may never have considered.)


>> Second, what's the deal with the bug with variations on 10.3.3?  Is 
>> this an Apple problem?  In any case, is it likely to be fixed 
>> sometime soon?
>
> Good question. I'd guess that it is Apple's problem.
>

Yes, it is. The same failure can be demonstrated by generating a PDF 
from Apple's WorldText app (/Developer/Applications/Utilities/Built 
Examples/WorldText) using Skia variations on 10.3.3. It looks fine on 
screen but making a PDF (e.g., Print Preview) shows the bug. Something 
broke pretty late in the process of developing the 10.3.3 update. Apple 
is aware of the issue.

> With a good font-mechanism in place, such as above,
> we will be in a position to collect many examples which fail,
> and then present such evidence to Apple.
> The more examples we have, the more likely that they will act
> quickly.
>

Yes; though you may struggle to find many variation fonts besides Skia.

As mentioned, they're aware of the problem; however, I'd still 
encourage people to report it, so they don't dismiss it as something 
that hardly matters to anyone (on the grounds that hardly any software 
can access variations).

>
>>
>> Finally, an observation: it's a shame to lose pdftex's 
>> margin-kerning, and that -- despite the fact that AAT supports such 
>> functionality -- none of Apple's font actually provide it.
>
> Interesting question for Jonathan.
>

Actually, some of Apple's fonts *do* include some support for one 
aspect of this, hanging punctuation, or at least they used to; but 
XeTeX explicitly disables this behavior. (I'm not sure if Apple ever 
added "optical bounds" tables to any of their fonts; that would be used 
to support another aspect of "margin-kerning".)

Why would I disable hanging punctuation anyway? Because, at the moment, 
it leads to at least two problems: First, the engine does not know when 
measuring text for line-breaking whether to include the "hanging" 
punctuation or not; and second, it doesn't adequately distinguish 
text-run boundaries that are actually mid-line from line edges, and so 
you get spacing problems within lines where XeTeX has actually rendered 
the line as several separate runs through ATSUI.

All this makes it an "interesting future direction". :-)

Jonathan