[XeTeX] Re: [MacTeX] XeTeX

Ross Moore ross at ics.mq.edu.au
Thu Apr 15 16:45:43 CEST 2004


Hi Jonathan,

On 15/04/2004, at 6:26 PM, Jonathan Kew wrote:

>>> By the way, what happens if you try this with Omega?
>>
>> Same as  tex, etex, pdftex, etc.
>
> OK. I wondered, because when I tried Omega [ver. 3.141592-1.23.2.2 
> (Web2C 7.5.2)] yesterday, I ran into things like this:
>
> 	\showthe\mathcode65
> 	> 28993.
> 	\showthe\mathcode`\A
> 	> 2899\CLOBBERED..
>
> Ouch! Different issue, though; it's trying to show the right number.

Yes, that's something different, which even TeX has a problem with.
For this 3-liner:

\showthe\mathcode65
\showthe\mathcode`A
\showthe\mathcode`\A \relax

  ... the 3rd line is somehow different from the others:

This is TeX, Version 3.14159 (Web2C 7.3.7x)
(./mtest
 > 28993.
l.1 \showthe\mathcode65

?
 > 28993.
l.2 \showthe\mathcode`A

?
 > 28993.
<to be read again>
                    \relax
l.3 \showthe\mathcode`\A \relax

? x
No pages of output.

My Omega is a bit older than yours...

This is Omega, Version 3.14159--1.23 (Web2C 7.3.7x)
Copyright (c) 1994--2000 John Plaice and Yannis Haralambous
(mtest
Babel <v3.7h> and hyphenation patterns for american, french, german, 
ngerman, d
utch, nohyphenation, loaded.

  ... but it gives exactly the same screen output as my TeX, shown above.


>> These are the problems that I've encountered so far:
>>
>>   1.  \mathcode  (as above)
>
> Yes. I think I may have this fixed; need to check a bit more, and I'll 
> try to post a new version shortly.

Great news.


>>
>>   2.  lack of tracing in  xdv2pdf  (mentioned above)
>
> Agreed; makes it hard to diagnose problems.
>
>>
>>   3.  cannot create a fresh working  xetex.xfmt  from  plain.tex
>>       (so that it preloads .tfm file locations from my installation)
>
> The xetex.xfmt that I provided was created by something like:
> 	% xetex -ini \*plain \\input xplain \\dump
> (producing plain.xfmt, then renamed to xetex.xfmt).
>
> (The extra input file xplain.tex simply sets up \catcode, \lccode and 
> \uccode values for a bunch of Unicode letters.)
>
> Are you trying to preload a very different set of tfms? I'm trying to 
> think why it wouldn't work for you.

Just the standard ones, I believe.
They would have been installed from TeXLive CDs, back in 2002.
They seem to be identical with earlier files from 2000.

>
>>
>>      Here's what happens when I try to use such a locally \dump'd 
>> format:
>>
>>  [glenlivet: XeTeX samples] rossmoor% xetex CM-test.tex
>> This is XeTeXk, Version 3.14159-2.1-0.3 (Web2C 7.5.2)
>>  %&-line parsing enabled.
>> (./CM-test.tex [1*** malloc: vm_allocate(size=2584555520) failed 
>> (error code=3)
>> *** malloc[28133]: error: Can't allocate region
>> fatal: memory exhausted (xmalloc of 2584553356 bytes).
>> [glenlivet: XeTeX samples] rossmoor% bad XDV file: DVI_PRE not found, 
>> b=-1
>
> Is the malloc failure (which clearly reflects an underlying problem; 
> no reason it should need that many bytes!) coming from xetex or from 
> xdv2pdf? Try running xetex with the -no-pdf option, so it simply 
> writes an .xdv file, and see if you get the same error.

It happens for  xetex , not xdv2pdf.
But it happens on the CM-test.tex example, but not Hindi.tex .
So it may be related to my earlier problem with CM fonts.



>>   4.  fclose: Bad file descriptor   problem.  (Is this just cosmetic 
>> ?)
>
> I don't know what this is, yet; I haven't seen it. But it worries me. 
> I suspect perhaps it's failing to find/open the tfms, and not handling 
> the failure well; and later "closing" files that were never opened.


>>   5.  lack of driver-support for color
>>          (this has been mentioned previously)
>>        Is color part of the AAT interface ?
>>        If so, then this shouldn't be too hard to do.
>>        But there also needs to be color for non-AAT constructs.
>>
>
> For AAT fonts, you can specify "color=XXXXXX" (a 6-digit hex RGB 
> value) as one of the options to the \font command (this is shown in a 
> few of the sample files).
>
> There's also \special{x:textcolor=XXXXXX} and 
> \special{x:rulecolor=XXXXXX} that will set the color for following 
> text and rules respectively. These will override any font color. You 
> can reset them by omitting the XXXXXX altogether, as in 
> \special{x:textcolor=}; that's different from specifying 
> \special{x:textcolor=000000} in that it will no longer override \font 
> color specifications.

OK; this is workable, to some extent.
Most of the TeX drivers now have a 'color-stack',
which is manipulated by  colorpush  and  colorpop  operations.

The point is that without push/pop then nested color-changes such as:
   \color{red} ... {\color{green}..... {\color{blue} .... } ...} ...}
have to be programmed in TeX to retain a history:

  \special{x:textcolor=FF0000}
           \special{x:textcolor=00FF00}
                            \special{x:textcolor=0000FF}
                                            \special{x:textcolor=00FF00}
                                               
\special{x:textcolor=FF0000}
                                                  
\special{x:textcolor=000000}

While this is achievable in TeX  --- anything is, in principle!
it is actually much easier to do it in the driving application,
when that is what controls how the color commands are put into
the resulting document (in this case a PDF file).
It requires an extra \special command at each color-change:

   \special{x:textcolorpush}
   \special{x:textcolor=FF0000}
            \special{x:textcolorpush}
            \special{x:textcolor=00FF00}
                            \special{x:textcolorpush}
                            \special{x:textcolor=0000FF}
                                            \special{x:textcolorpop}
                                               \special{x:textcolorpop}
                                                  
\special{x:textcolorpop}

   ... but not needing to recover the previous color makes the TeX 
programming
   much easier, as the specific color coords need only be known at the 
time
   the color is switched-on.


>>
>>   6.  lack of driver-support for active hyperlinks
>>        Preview.app supports hyperlinks in Panther, but TeXshop does 
>> not.
>>        Surely there are some APIs for this now.
>
> I don't recall seeing any APIs to create hyperlinks when generating 
> PDF through Quartz, which is what xdv2pdf is doing; but I'll look, 
> perhaps Panther added this. If not, I'll talk to some folks at Apple 
> and see if there's a possibility for the future. (Creating the 
> hyperlinks is a completely separate matter from supporting them once 
> they're in the PDF, of course.)

All I can say is that I was surprised a few weeks ago when someone 
reported to me
that some links in a pdfLaTeX-generated document were linking to the 
wrong place
from Preview.app, but Adobe Reader got them right.
(Prior to this I had always used Adobe Reader for checking pdfLaTeX 
jobs, as I'd
thought Preview didn't support them, since TeXShop doesn't. Now I know 
otherwise!)

To finish the story, the author had used 'relative' URLs;
e.g. \href{www.tug.org}{TUG}  instead of  
\href{http://www.tug.org}{TUG}.
Somehow AR figured out that there should have been the  http://
whereas Preview (correctly, in my view) does not make this assumption,
instead looking on the local disk.



>>   7.  support for  scaling/rotations/clipping etc. of imported 
>> graphics.
>>        How much of the \includegraphics  from  graphicx.sty
>>        can be supported, for a  xetex.def  driver file ?
>
> The \picfile (and \pdffile) commands accept keyworded options for 
> scaling, translation, and rotation (not clipping, yet at least); see 
> the XeTeX-notes file.

OK; that'll make a lot of effects implementable.


> Let me know how far this gets you; I'm happy to consider changes to 
> make xetex fit in better with the rest of the TeX world. Nothing about 
> this is set in stone; features were simply created to fit what I 
> needed to do in what seemed like the easiest way.

Sure; that's surely the best way to start, especially when exploring 
what can be done.
Later you expect to enrich the syntax to agree with what others have 
found to be better
ways of requesting specific kinds of features.


Hope this helps,

	Ross


>
> Jonathan
>
> _______________________________________________
> MacTeX mailing list
> http://tug.org/mailman/listinfo/mactex
>
------------------------------------------------------------------------
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
------------------------------------------------------------------------


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

_______________________________________________
MacTeX mailing list
http://tug.org/mailman/listinfo/mactex



More information about the XeTeX mailing list