[XeTeX] A small tip

Will Robertson will at guerilla.net.au
Fri Nov 18 01:47:30 CET 2005

On 18/11/2005, at 8am, Ross Moore wrote:

> On 17/11/2005, at 6:16 PM, Will Robertson wrote:
>> \documentclass{article}
>> \usepackage[utf8]{inputenc}
>> \DeclareUnicodeCharacter{2014}{2014}
>> \DeclareUnicodeCharacter{8212}{8212}
>> \begin{document}
>>>> \end{document}
> This gives me  8212 .
> If you get  2014  then maybe it's a package-version thing.
> The relevant files are:
> These are quite old -- all from 2001.
> What versions do you have ?

    [2004/02/05 v1.0d Input encoding file]

    [2004/02/09 v1.1b UTF-8 support for inputenc]

And ucs.sty is not even loaded. I recall reading that utf8 encoding  
in inputenc had deprecated it to a certain extent, but I can't  
remember the details. (And utf8x goes even further...)

Still, I'm very surprised that they would have changed from hex to  
decimal like that. I wonder if that was somehow related to ucs?

>> On a related note, I thought xunicode might provide an equivalent  
>> to inputenc's \DeclareUnicodeCharacter,
>> but it seems that xunicode's \DeclareUTFcharacter is for a  
>> different purpose (at least, I couldn't get it to do what I expect).
>   Xunicode's \DeclareUTFcharacter  translates *into* Unicode for  
> the output.
>   Inputenc's \DeclareUnicodeCharacter  translates *out of* UTF8  
> into a TeX macro.

That's how I ended up assuming it must work. In retrospect,  
xunicode's is perhaps a confusing name for that command, then. Would  
\DeclareUTFmacro be better?

>> (I'll never remember when to do hex and when to do decimal...is  
>> the preceding "x" supposed to remind me? Why is it there, out of  
>> curiousity?)
> Yes; it's just a reminder that this is hex, not decimal.
> It plays no role at all in the processing.

Okay...I suppose because I can never remember which to use,  
standardising on a single number base for referring to glyph slots is  
a good idea.

>> Well, it wouldn't be so bad (are all the kerns and nobreaks, etc.,  
>> stripped out by hyperref?),
> No, it doesn't work that way.

Oh, of course! That's a really nice solution. (Stripping out TeX  
primitives sounds very unpleasant, actually.)

>>> ([hxetex.def]'s something that I'll try to provide sometime.)
>> Let me know if you need help...I can't promise anything, of course :)
>> Speaking of your packages, I wonder if it would be useful to  
>> provide a "lean" version of xunicode as a package option so as to  
>> only load the necessary portions of the unicode characters you  
>> define.
> Not in the near future, sorry.
> There are things missing from XeTeX support which have a higher
> priority than reorganising what *is* available.

Would it be a good idea to talk about the missing things so that  
people have an idea of what is going on? I'd be happy to help out  
some, as I hope I've demonstrated. I suspect the amount of time you  
put into xunicode is very much under-appreciated, not to mention  
color and graphicx support, which "just work" without even people  
thinking about it.


More information about the XeTeX mailing list