[OS X TeX] ** WARNING ** 4 memory objects still allocated
Peter_Dyballa at Web.DE
Mon Jul 9 10:41:40 CEST 2012
Am 09.07.2012 um 09:48 schrieb Yvon Thoraval:
> ** WARNING ** Failed to convert input string to UTF16...
This can come from hyperref. Its README explains:
Default for the encoding of bookmarks is `pdfencoding=auto'.
That means the strings are always treated as unicode strings.
Only if the string restricts to the printable ASCII set,
it is written as ASCII string. The reason is that the
\special does not support PDFDocEncoding.
XeTeX uses the program xdvipdfmx for PDF output generation.
This program behaves a little different from dvipdfm, because
of the supported Unicode characters. Strings for bookmarks
or information entries can be output directly. The
big chars (char code > 255) are written in UTF-8 and
xdvipdfmx tries to convert them to UTF-16BE. However
hyperref already provides PDF strings encoded in UTF-16BE,
thus the result is a warning
"Failed to convert input string to UTF16..."
The best way would be, if xdvipdfm could detect the
byte order marker (\376\377) and skips the conversion
if that marker is present.
For the time being I added the following to hyperref,
when option `pdfencoding=auto' is set (default for XeTeX):
The string is converted back to big characters thus that the
string is written as UTF-8. But I am very unhappy with this
solution. Main disadvantage:
Two versions of \pdfstringdef are needed:
a) The string is converted back to big characters for
the "tainted keys" of xdvipdfmx (spc_pdfm.c: default_taintkeys).
The subset hyperref uses is /Title, /Author, /Subject,
/Keywords, /Creator, /Producer, /T. Any changes of this
set in xdvipdfmx cannot be detected by hyperref.
b) Without conversion for the other strings , providing UTF16be
directly. Examples: Prefix of page labels, some elements
Thus *each* application that uses \pdfstringdef now must
check, if it defines a string for some of the tainted keys.
If yes, then the call of \pdfstringdef should be preceded
by "\csname HyPsd at XeTeXBigCharstrue\endcsname".
Example: package bookmark.
So it should not happen – but it happens! To me it happens when I use accented characters (German ä, ö, ü,...) directly. My workaround was to use \"a etc. Another cause can be that some auxiliary files are polluted. So I'd recommend to remove these auxiliary files first, run xelatex a few times and the see if this removes the issue.
From my experience I think that an up-to-date TeX Live 2011 does not show such reports.
The still allocated memory objects are an xdvipdfm problem. An up-to-date xdvipdfm works, according to my experience, better.
The day Microsoft makes something that doesn't suck is the day they start selling vacuum cleaners.
– Ernest Jan Plugge
More information about the macostex-archives