\char
is not an expandable command, thus it does not work as string in \pdfinfo
. Also, \char
would use the current font encoding. But the font encoding is irrelevant here. Instead, the PDF specification allows two encodings:
- PDFDocEncoding, an 8-bit encoding, different, but similar to latin1,
- UTF16-BE with BOM for Unicode strings
Package stringenc
helps in converting a string (e.g. from UTF-8) to the correct encoding, needed for the values in \pdfinfo
.
Also the values for the keys in \pdfinfo
must be escaped as strings, for example unmatched parentheses; pdfTeX's \pdfescapestring
helps here for strings given in parentheses.
The other string form are angle brackets with the string encoded as hexadecimal string.
Package hyperref
's \pdfstringdef
takes care of lots of these issues. It also defines virtual font encodings PD1
and PU
to get many characters work. For reinventing the wheel I strongly recommend reading the section about strings in the PDF specification.
At TeX level, the string needs to expand as plain text string without commands. PDF viewers do not know about TeX commands inside bookmark strings.
The letters by \char'151
(i
) and \char'141
(a
) can be given as (PDFDocEncoding):
\pdfinfo{/Author(\string\151\string\141)}
pdfinfo
reports then:
Author: ia
^^
notation or\Uchar
in LuaTeX (or XeLaTeX). But\char
is not expandable. Why exactly do you need that? Can't you define\def\hiddencharone{a}
and\def\hiddenchartwo{b}
and use\hiddencharone\hiddenchartwo
?