一般フォーラム

> web2c-w32.tar.xz を更新すると問題なくなると思います。

これで駄目な場合，luatex 等のバイナリも更新する必要が
あるかも知れません。 2012/04/30 より前の一時期，
C の system() 関数が関与する場合に不具合があるバイナリを
出していました。

なかなな一筋縄ではいかないということが分かりました。
少々長いですが、もしよろしければお付き合いお願いします。
\xxx の8bit記法でバイト列を書いた場合に、仮定しているencodingが何かにより文字が変わる問題です。

例えば

\section{\texorpdfstring{(1) test}{test[\303\242][\240][\037]}}
\section{\texorpdfstring{(2) テスト}{テスト[\303\242]}}

とあったときを検討します。
ちなみに
\303 :: hex 0xC3, U+C3は、Ã, PDFDocEncodingは、Atilde(Ã)
\242 :: hex 0xA2, U+A2は、¢, PDFDocEncodingは、cent(¢)
\240 :: hex 0xA0, U+A0は、non break space, PDFDocEncodingは、Euro(€) U+20AC
\037 :: hex 0x1F, U+1Fは、unit separator, PDFDocEncodingは、tilde(˜) U+02DC

PDFDocEncodingでは、0xC3 0xA2 が Atilde(Ã), cent(¢) を示します。
UTF8では、0xC3 0xA2 が U+E2 (â) を示します。
EUC-JPでは、0xC3 0xA2 が 35区2点 (但) を示します。
仮定しているencodingが何かにより文字が変わります。

また、\xxx の8bit記法は、PDFの仕様上、
テキスト文字列(bookmarkなどの箇所に使用される文字列)に記述された場合
(a) PDFDocEncoding もしくは、
(b) BOMが先導した場合は UnicodeのUTF16BE
だそうです。
Ref. PDFリファレンス第2版 アドビシステム著 ISBN4-89471-338-1 §3.8.1 テキスト文字列

下記の環境[1a]〜[1c][2a]〜[2e]を使用した場合を考えてみます。

[1] dvipdfmx

[2] dvips

欧文LaTeXでは、PDFDocEncoding を期待した結果となり、
[1a][2a]では、(1)の方は、
のようになります。

従来のpLaTeXでは
[1b]で試してみると、(2)の方は、EUC-JP想定で変換され
のようになりました。
調べ切れていませんが、おそらく[2b][2c][2d]も同様だと想像しています。
upLaTeX+dvipdfmxでは
[1c]で試すと、(2)の方は、UTF8想定で変換され
のようになりました。

従来の[2e]では、
欧文のみの場合には変換しない方針、
和文を含む場合は変換する方針だったので、バグがなければ、
(1)の方は、
のようになり
(2)の方は、[1b]ならばEUC-JPが想定され
[1c]ならばUTF8が想定され
になるはずでした。(実際にはバグで、通りませんでした。)

しかし、PDFの仕様の(a)(b)を勘案すると、
\xxx を見つけた場合にEUCやUTF8を想定するのは不適切という気がしてきました。
和文を含む含まないで結果が変わるのも、不整合な印象です。
仕様案を考えてみます。

仕様案その1
\xxx を見つけた場合には PDFDocEncoding を常に期待し、
PDFDocEncoding → UTF16BEの変換をする。

仕様案その1a
\xxx を見つけた場合には PDFDocEncoding を常に期待し、
欧文ならば、変換なし
和文ならば、PDFDocEncoding → UTF16BEの変換をする。

仕様案その2
\xxx を見つけた場合には PDFDocEncoding を期待するモードをdefault、
\xxx を見つけた場合には UTF16BE を期待するモードをコマンドラインオプションで選択可能とし、
各encoding → UTF16BEの変換をする。

仕様案その3 (従来のdvipdfmx+CMap変換の仕様)
CMap が不使用ならば \xxx を見つけた場合は PDFDocEncoding を期待するモードで
変換なし
和文ならば、
CMap が EUC-UCS2 ならば \xxx を見つけた場合は EUC-JP を期待するモード
CMap が UTF8-UCS2 ならば \xxx を見つけた場合は UTF8 を期待するモード
各encoding → UTF16BEの変換をする。

仕様案その3a (従来のconvbkmk.rbの仕様案)
欧文ならば、\xxx を見つけた場合は PDFDocEncoding を期待するモードで
変換なし
和文ならば、
convbkmk.rb が EUC-JP モードならば \xxx を見つけた場合は EUC-JP を期待するモード
convbkmk.rb が UTF8 モードならば \xxx を見つけた場合は UTF8 を期待するモード
各encoding → UTF16BEの変換をする。


今のところ、仕様案その1a にしようかと思っています。
この場合、仕様案その3 との乖離が大きくなるのが難点ですが、欧文LaTeX との乖離は小さくなる方向です。
仕様案その2 は、\xxx の8bit記法を UTF16BE でわざわざ書かなくても、と思います。
( そういえば、bkmk2uniでは、\0xXXXX と書くとUnicodeで直接指定出来る機能が入っているそうですが、
convbkmk.rb でもサポートした方がよいのでしょうか。 )
いずれにせよ、仕様案その3a を捨てると
PDFDocEncoding → UTF16BEの変換を用意することになりそうで、ちょっと手間がかかりそうです。
あるいは、割り切って、不整合な感じには目をつぶって、仕様案その3a を押し通すか。

ご意見があればよろしくお願いします。