On 2010-03-02, Jürgen Spitzmüller wrote:
> Guenter Milde wrote:
> The following minimal document
> -------------------------------------
> \documentclass[greek]{article}
> \usepackage{fontspec}
> \usepackage{babel}
> \usepackage{xunicode}
> \usepackage{xltxtra}
> \begin{document}
> test
> \end{document}
> --------------------------------------
> produces a PDF with the string "τεστ". This proves that transliteration in
> XeTeX works as in (pdf)latex, contrary to your claim.
With babel, yes. As the transliteration is done at the font level (it is
a feature of the LGR font encoding), it cannot be kept for
Unicode-encoded fonts.
However, Greek Unicode chars are missing in the output in the
following example if:
a) babel is included, or
b) the \setmainfont line is commented
\documentclass[greek]{article}
\usepackage{fontspec}
\setmainfont{Gentium}
% \usepackage{babel}
% \usepackage{polyglossia}
\begin{document}
Me mia mati'a...
Με μια ματιά...
\end{document}
Babel selects a different font (the missing unicode support is a
consequence of this font change).
This is one of the reasons why I believe the XeTeX documentation when it
tells that babel and XeTeX are incompatible.
> It does not matter whether or not polyglossia does this different than
> babel. If you use a different package, you have to be prepared for
> such changes
Well, I expect changes with the pdftex -> xetex switch, otherwise I would
not switch.
> (although I'd say this is a polyglossia bug *if* polyglossia claims to
> be a drop-in-replacement for babel [which I don't know].
It is a replacement but not a drop in.
> However, if polyglossia changes behaviour, we cannot replace
> babel by it anyway, unless the user explicitely requests this.
We must replace babel by polyglossia, as babel is not compatible with
XeTeX. Selecting XeTeX as output machine is an explicite request for
full, language-independent Unicode support.
We might have to care for possible incompatibilities in supported options
and languages with polyglossia, though.
Günter
