[OS X TeX] ** WARNING ** 4 memory objects still allocated
yvon.ubuntu at gmail.com
Mon Jul 9 12:11:26 CEST 2012
2012/7/9 Peter Dyballa <Peter_Dyballa at web.de>
> 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:
> 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.
> The day Microsoft makes something that doesn't suck is the day they start
> selling vacuum cleaners.
> – Ernest Jan Plugge
> ----------- Please Consult the Following Before Posting -----------
> TeX FAQ: http://www.tex.ac.uk/faq
> List Reminders and Etiquette: http://email.esm.psu.edu/mac-tex/
> List Archive: http://tug.org/pipermail/macostex-archives/
> TeX on Mac OS X Website: http://mactex-wiki.tug.org/
> List Info: http://email.esm.psu.edu/mailman/listinfo/macosx-tex
Thanks a lot for your precise and long answer.
However, I'm actually using TeXLive 2012...
I do have also a \newcommand (commented out by % actually because buggy) :
which gives, in acrobat reader bookmarks part of some commands...
something like "color push gray color0colorpopIntroduction généralegriscolor
push gray color0 color poptowidthheightdepth"
where the \section texte is the red one above "Introduction générale"
I'll look at that this afternoon
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the macostex-archives