[DVIPDFMx] dvipdfm vs. x vs. xx

[Heiko Oberdiek]

On Tue, Dec 15, 2009 at 09:11:40PM +0900, Jin-Hwan Cho wrote:

> Without touching the source code of (x)dvipdfmx, there is no GOOD way to suppress
> the reencoding (maybe_reencode_utf8() in xdvipdfmx does this job.)
> 
> One possible way (not GOOD) is:
> 
> 	(1) Prepare an external CMap file Identity-Byte (attached in this mail)
> 	(2) Before calling hyperref, give the following lines.
> 		\usepackage{atbegshi}
> 		\AtBeginShipoutFirst{\special{pdf:tounicode Identity-Byte}}
> 
> Future plan for (x)dvipdfmx is to prepare the special "pdf: tounicode none" that
> suppress the working of maybe_reencode_utf8() in xdvipdfmx.
> 
> Do you have any better idea?

Suppressing reencoding if the BOM is provided in the right
format, e.g. "\376\377" (eight bytes).

> You are right. PDFDocEncoding is different from Unicode. But I cannot catch
> the exact meaning of "pdfencoding=auto" under XeTeX. This option does not
> touch anything (reencoding) under XeTeX, right?

This option uses Unicode as standard. Then it tries to
convert to printable ascii (hxetex, other drivers: PdfDocEncoding).
If the conversion succeeds, the ascii string is used instead,
that does not get reencoded as far as I have understood the
source code. Otherwise the unicode string (UTF16/UCS2) is
given as PDF byte string including BOM.

> I don't understand why conversion warning does appear. I will try after
> changing to the new version 6.79t, and will continue this discussion.

You will need a new stringenc (because of the encoding `ascii-print'):
  ftp://ftp.tug.org/tex/oberdiek/

CTAN upload soon, when automatically mirroring is setup.

Yours sincerely
  Heiko <oberdiek at uni-freiburg.de>