[XeTeX] Status of XeTeX on non-MacOSX platforms?

[Jonathan Kew]

On 30 Jul 2005, at 10:32 am, Sivan Toledo wrote:

> Hi,
>
> I would like to ask about the prospects/plans/status of XeTeX for  
> platforms other than MacOS X.
>
> I read carefully the paper on XeTeX for IUC27, and I seems to me  
> that MacOS specific code is used in only 3 places in XeTeX:
> 1. In handling ATSUI fonts and words typeset in these fonts,
> 2. XeTeX calls the ATSUI bidirectional algorithm.
> 3. XeTeX uses a MacOS-specific API to render the document into a  
> PDF file
You're on the right lines, but I can clarify a little further.

#2: no, there isn't an ATSUI bidi algorithm as such, separate from  
the complete ATSUI rendering process; bidi happens automatically as  
part of that. When XeTeX needs to explicitly run the bidi algorithm  
(as part of the ICU/OpenType layout process, a separate path from the  
ATSUI process), then it uses the ICU bidi implementation directly.

However, even in the ICU/OpenType case, XeTeX is still using OS X  
APIs in order to find and access fonts installed on the computer, so  
there's a font API dependency even when not using ATSUI layout.

In addition, XeTeX also uses Mac APIs (specifically QuickTime graphic  
importers) to support image files (which is why it can directly use  
virtually any raster graphic format with the \XeTeXpicfile command).

> I think that item (1) can simply be dropped from non-MacOS builds,  
> and item (2) can probably be replaced by either ICU (I think it  
> includes a version of the algorithm) or freebidi, a GPL library  
> implementing the algorithm.
>
> Item (3) is probably the most difficult to replace, mostly because  
> of the need to subset and download OpenType fonts (both TTF and  
> OTF) in the PDF file. Up to this issue, the PDF generation can  
> probably use the pdfTeX generator.
I think a much simpler path to at least an initial "portable"  
implementation will be to use dvipdfm(x) as the basis for a new xdv- 
to-pdf converter. Perhaps eventually someone will tackle a complete  
integration with pdfTeX, but I see that as a much larger and longer- 
term project.
> I am not suggesting that any of this is easy. Even just building  
> the code with all the MacOS-specific #ifdef'ed away might be  
> difficult.
>
> But I would like to see this happen (I think many other users would  
> too), and I would be happy to help. I have experience in adding  
> font-downloading support to free software (I added TTF/PFB font  
> downloading and subsetting to Qt, I added OTF downloading to iText,  
> and students working under my supervision added OTF subsetting to  
> iText; Qt is C++ code and iText is Java).
>
> I would like to suggest that a good way to move this forward is to  
> separate the system issues from the coding issues. That is, the  
> first step should be to create a platform-independent source tree  
> that builds the functional program on MacOS but a crippled version  
> without the MacOS code on other platforms. Then the missing parts  
> should be defined, either in terms of an API, or just in terms of  
> writing replacement to the delete-MacOS code. Then people with  
> specific expertise can try to help by writing the missing code.
I'm very glad to know people are interested in this, as it's  
certainly something I would like to see happen. Right now I'm  
travelling for several weeks and so little is happening on the XeTeX  
code, but this is exactly the sort of direction I'm trying to move  
the project.

Jonathan