[XeTeX] Feedback on W32 Port of XeTeX v0.994

[Jonathan Kew]

Hi Toralf,

Good to hear from you, and welcome! :)

> maybe you (as Mac or Linux Users) dont't care but you have one very  
> happy user of the windows port.

It's always been my goal to have a Windows version eventually, I just  
haven't had time to try and compile it there yet. So I was very  
pleased when Akira did this and made it available.

> There are unfortunately two big issues, which could stop me from  
> using XeTex for the online Version of my PhD-Thesis (PDF filesize  
> is 10 times smaller with XeTeX compared to PDFTeX due to the heavy  
> font usage in my document): Colors and PDF-picture inclusion do not  
> work. As soon as I include \usepackage[xetex]{color} I get  
> thousands of errors álá 'Warning*** -->x:textcolor=000000<---  
> unparsed macros afters specials ignored'

Support for output-driver features such as graphics and color is in a  
state of some confusion at the moment, I'm afraid, because originally  
(for the past couple of years) XeTeX on Mac OS X has used its own  
"private" driver, xdv2pdf, but now on Linux (and Windows) it is using  
xdvipdfmx, an extended version of dvipdfmx. The drivers do not  
currently support exactly the same set of features, and particularly  
\special commands.

The [xetex] option for the color and graphics/graphicx packages was  
implemented back in the Mac-only days, and so it generates xdv2pdf- 
style output, and with xdvipdfmx you get warnings (and no color), as  
you've seen.

What may help for now, until all this gets sorted out better, is to  
load the color and graphics packages with the [dvipdfm] option (or  
[dvipdfmx], if there is such an option available). This should make  
them use \special commands that the driver will recognize.

> Second thing: when I want to include a PDF with \inludegraphics 
> {test.pdf} or \XeTeXpicfile{test.pdf} I get the error 'Could not  
> inlude picture or PDF file' and when i press >h< I get 'picture  
> format not supported'.

Here again, the problem is that the graphics package is using xetex  
features that aren't available (yet) in the Windows version. Again,  
try loading graphics with [dvipdfm] and see if this helps.

> Third thing: XeTeX did not recognise the Optical Versions of the  
> biggest font I have access to: The Premier Pro version of Garamond.  
> It only included the Caption version (for all pt sizes); when I  
> deleted this file, it included the Display version etc.

This sounds like a bug; xetex should be able to find the various  
optical versions, provided Garamond Premier Pro has a 'size' feature  
in the OpenType tables. I don't have Garamond Premier Pro available  
to test, though.

Are you able to get access to a Mac OS X and/or Linux system where  
you could test xetex with this font, to see if it can correctly  
handle the optical sizes there? That would help clarify whether this  
is a problem specific to the W32 port or not.

If there are issues related specifically to the W32TeX port, you may  
want to inform Akira Kakuto, who built that version. As far as I  
know, Akira isn't on this mailing list, so separate feedback (see the  
W32TeX page) might be useful.

Also, be sure to try updating to the very latest available version; I  
believe Akira has updated the package a couple of times since the  
initial release.

> Last issue I noticed: Independant of how I inlcude the font (with  
> fontspec, \font= or with my stylefile), the pnum feature  
> (Proportional Figures) gave a strange result: when I type several  
> times the nunber 'one', like 11111111, they end up in visualy quite  
> disturbung groups of two digits, like 11 11 11 11..not separeted by  
> much, but still quite visible. Other Opentype aware applications  
> like Adobe Indesign or Illustrator dont to that and neither does  
> PDFTex do that..so is this a bug or a feature (the result of the  
> script that is behind pnum)?

Interesting.... does this persist even if you view the PDF with large  
magnification, or print to a high-resolution printer? It's probably  
an issue with rounding, and indicates that we should ensure xdvipdfmx  
uses greater precision in glyph positioning. I'll look into this in  
the Linux version (which should give identical results to the W32  
build).

> For with PDFTex comparable typesetting quality, also compatibility  
> with the microtype package would be nice--in my view, font  
> expansion and character protrusion are the biggest leap forward  
> with respect to quality since a long time -- but I am aware of the  
> fact that it would be quite labourious to implement that into XeTeX.

Yes, this is a common request, and I hope we'll get there eventually  
(but it won't be immediate!).

JK