[XeTeX] Conflict between xunicode and fontspec?

[Peter Dyballa]

Am 07.02.2008 um 18:39 schrieb Ulrike Fischer:

>> Am 07.02.2008 um 16:47 schrieb Ulrike Fischer:
>>
>>> So the problem is not the input but the output encoding: the default
>>> encoding eu1 from fontspec doesn't contain the necessary commands
>>> to map
>>> the commands like \^{u} to the correct single glyph "ugrave".
>>
>> This would explain why at sudden it fails to copy from the PDF file:
>> fontspec was changed in an unwanted and unexpected way
>
> I don't know if this is really your problem. Perhaps you are using  
> some
> other package which maps your input to commands lile \^{u}. As Bruno
> mentioned there is xunicode which handles the \^{u} case so you should
> try it. If it doesn't help: a complete minimal example and the  
> resulting
> pdf would probably help to find what's going wrong.

In GNU Emacs I can input the characters as themselves, so xunicode is  
not needed. I started LaTeX at a Sun keyboard with compose key –  
there was no real need to learn using these macros (OK, TeX was also  
patched to accept direct input). Since then I prefer to use as little  
packages as possible. (Which sometimes greatly fails: latest hyperref  
package works when you also install the whole oberdiek plethora of  
packages. But it has support for pdfTeX 1.50!)

>
>> I was thinking (and I think I also experienced this) xdv2pdf and
>> xdvipdfmx were inserting a mapping from accented characters to their
>> Unicode positions, just as Vladimir Volovich's cmap packages tries to
>> handle this with pdfTeX, so that copying from the PDF file resulted
>> in fully composed Unicode strings. At least today I cannot copy
>> composed Unicode characters from any PDF file.
>
> Does "any PDF" include arbitrary PDF's from the net?
>


Yes! I have some German PDF documents, often created without pdfTeX  
or XeTeX. (The worst of them is from pdfFactory 2.42 (Windows XP  
Professional German) – it seems to use some encryption or scrambling  
that what you see & copy is not what you paste & see. The names of  
the ugly ragged fonts are hidden, except that they are TT.) But now  
I've found a few causes/culprits ...

	First problem is GNU Emacs – it does not like to compose.
	Second problem is Apple's PDFKit – it decomposes.
	Third problem are TextEdit and Adobe Reader – they behave correctly  
(IMO).

When I copy from TeXShop (my preferred PDF viewer) to TextEdit the  
characters are OK, composed as in GNU Emacs, i.e. the XeLaTeX source  
file, or as displayed in the PDF viewer. Pasting the same into GNU  
Emacs shows it decomposed.

When I copy from Adobe Reader 8 to TextEdit the characters are OK,  
composed as in GNU Emacs, i.e. the XeLaTeX source file, or as  
displayed in the PDF viewer. Pasting the same into GNU Emacs shows it  
*alright*.

And when I copy in TextEdit what I had copied before from TeXShop and  
pasted into TextEdit, and paste this secondary copy into GNU Emacs  
*it's composed*.


I think this is worth another Apple Bug Report. Can MS Windows users  
feel better?

--
Mit friedvollen Grüßen

   Pete

Be careful of reading health books, you might die of a misprint.
				– Mark Twain