[OS X TeX] ** WARNING ** 4 memory objects still allocated

[Peter Dyballa]

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
	     of formulars.
	  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.

--
Greetings

  Pete

The day Microsoft makes something that doesn't suck is the day they start selling vacuum cleaners.
				– Ernest Jan Plugge