\capitalring, etc with xelatex, lualatex unicode

[bdtc]

When using xelatex or lualatex, \capitalring and similar macros fail if using hyperref, but succeed if hyperref is not loaded.

`
% Works with pdflatex, with or without hyperref.

% Works with xelatex or lualatex without hyperref.

% Fails with xelatex or lualatex with hyperref.

\documentclass{article}

% \usepackage{hyperref}

\begin{document}

\capitalcedilla A

\capitalogonek A

\capitalgrave A

\capitalacute A

\capitalcircumflex A

\capitaltilde A

\capitaldieresis A

\capitalhungarumlaut A

\capitalring A

\capitalcaron A

\capitalbreve A

\capitalmacron A

\capitaldotaccent A

\end{document}
`

[davidcarlisle]

ah thanks yes this is probably an issue with latex rather than hyperref but I can move it if necessary.

The capital... versions do nothing for Unicode fonts so they are initially defined to be thenormal versions:

> \capitalcedilla=macro:
->\c 

but hyperref uses the fontencoding mechanism to set up its PU encoding and then in switching back latex gets confused and expects TU-specific definitions.

So after hyperref is loaded the definition is

> \capitalmacron=macro:
->\PU-cmd \capitalmacron \PU\capitalmacron .

which would be OK except the current encoding is TU and it expects a TU definition to switch to, the original alias to \c has been lost.

Not sure immediately what the best fix is, but simply using \c would avoid the problem.

[car222222]

Where does this PU encoding come from?

[u-fischer]

@car222222 That's defined by hyperref. It needs to translate the input into something safe for the bookmarks.

[car222222]

Would it be a good idea to remove PU and use TU throughout?
Even if this does not solve this particular problem, it may make our lives simpler;
also, there does not seem to be any reason these days to use more than one font encoding for Unicode fonts (or for Unicode strings in pdf).

[u-fischer]

Would it be a good idea to remove PU and use TU throughout?

No. You only need to look into puenc.def. puenc translates the commands into the octal representation needed by pdf strings, not it something useful for typesetting
For example:

\DeclareTextCommand{\textasciiacute}{PU}{\80\264}% U+00B4

[car222222]

I see, so PU is something totally different, nothing at all related to Unicode characters in fonts.
Even more reason to remove it and use a better method of translating LICRs into other formats such as octal representations.

[u-fischer]

I see, so PU is something totally different, nothing at all related to Unicode characters in fonts.
Even more reason to remove it and use a better method of translating LICRs into other formats such as octal representations.

T1- or OMS-encoding aren't related to unicode characters either. So perhaps we should remove them too? Beside this: the numbers are related to a font. At the end they produce a bookmark which is shown on my screen with the help of a font. They are as real and font related as is a € in a html file or some glyph slot number in a .dvi or a pdf stream.

[FrankMittelbach]

Fixed. It will show up with the next release in fall. But the capital accents will only work in unicode engines if the accent is suported by the current font, e.g., in LM \capitalcedilla C will come out right, but \capitalcedilla A in your example will complain about a missing combining accent as that doesn't exist in the font and a precomposed character doesn't exist either.

This is where the engines behave differently.