[XeTeX] Re: [MacTeX] XeTeX 0.4 available

[Ross Moore]

Hi again Jonathan,


On 21/04/2004, at 7:14 PM, Jonathan Kew wrote:

> 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.

Yes, indeed.
The \gdef  commands above simply define strings, without saying
anything about whether or not you use them for a particular font.


> 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.

Yes, again.
Which is why I'm asking everyone to make appropriate .fd  files for 
fonts
that they use, and submit them to this list.
Otherwise there is too much work for one person to track down all the 
options
within all the fonts.


>
> (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.)

With so much flexibility, we need many eyes to sample and test the 
possibilities.


>
>
>>> 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).

Who knows what other glitches may emerge, with all the possible styles
and combinations available with these fonts.
Again, this is why we need many eyes.



>
>>
>>>
>>> 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". :-)

Quite.



Cheers

	Ross

>
> Jonathan
>
> _______________________________________________
> XeTeX mailing list
> postmaster at tug.org
> http://tug.org/mailman/listinfo/xetex
>
------------------------------------------------------------------------
Ross Moore                                         ross at maths.mq.edu.au
Mathematics Department                             office: E7A-419
Macquarie University                               tel: +61 +2 9850 8955
Sydney, Australia                                  fax: +61 +2 9850 8114
------------------------------------------------------------------------