upLaTeXにおける「hyperrefのunicodeオプション」のサポート

[zr-tex8r]

経緯

• hyperrefのunicodeオプションの既定値がtrueに変更された。[v7.00g 2021-02-04]
  • 本来は、unicodeをfalseからtrueに変えても（論理的な）出力は変わらない。
  • ただし、pLaTeX＋hyperref＋pxjahyperはunicode有効をサポートしないので、この場合は非互換になる。
• hyperrefのunicodeオプションの既定値がtrueに変更された。[v7.00h 2021-02-10]
  • そこで、pLaTeXにおいてunicodeの既定値がfalseに戻された。
  • upLaTeX＋hyperrefについては、pxjahyperはunicodeに“試験的”に対応している状態だった。
  • 従って、upLaTeXでのunicodeの既定値はそのままにされた。
• そこで、pxjahyperで「upLaTeXでのunicode有効」を正式サポートの扱いとした。[v0.7 2021-02-13]
  • unicode有効のときの不具合がいくつか修正された。

現状の不具合

• 参考→Beamer \author内で \UTF{...}, \CID{...} を使うとコンパイルできない（TeX Forum）

upLaTeX上で、hyperref（unicodeが既定状態）の読込とpxjahyperの読込の間でPDF文字列を設定するとその文字列が異常になる。hyperrefパッケージのオプションでpdftitleなどを指定する場合などがこれに該当する。2021-02-04以前はこの使い方で正常動作していたので、非互換が発生している。

\documentclass[uplatex,dvipdfmx,a4paper]{jsarticle}
\usepackage[pdftitle={タイトルが化ける}]{hyperref}
\usepackage{pxjahyper}
\begin{document}
\section{しおりは正常}
\end{document}

• つまり、現状のpxjahyperは「“間”でのPDF文字列の設定」に対応できていない。
  • そもそもpxjahyperを読み込む前の動作なので、pxjahyperの側で対応するのが困難。
• 2021-02-04以前は既定でunicodeがfalseだったので正常動作していた。現状でもunicode=falseを明示指定すると正常になる。

対策案

hyperrefの側で、次の2つのうちいずれかの対策を施してもらう必要がある。

1. upLaTeXの場合もunicodeの既定値をfalseにする。
   • 完全に2021-02-04以前の状態に戻る。
2. upLaTeXの場合も「PDF文字列のUnicode変換処理」を有効にする。
   • 現状のhyperrefではXeTeX／LuaTeXの場合に「PDF文字列のUnicode変換処理」が有効になる。pdfTeXでは無効になる。そしてpTeX／upTeXでも無効になる。
   • 現状のpxjahyperではパッチをあてることで無理やり有効にしている。なので、pxjahyper読込前は失敗する。
   • 私見では、将来的にこちらの方が望ましいと思う。

問題

1と2のどちらを採用すべきか。

[zr-tex8r]

現状のhyperrefではXeTeX／LuaTeXの場合に「PDF文字列のUnicode変換処理」が有効になる。

これに関連するhyperrefの実装箇所。

https://github.com/latex3/hyperref/blob/release-7.00k/hyperref.dtx#L3841

この箇所の先頭に次のようなコードがあり、これで「Unicode対応のエンジンであるか」を判定している。

\begingroup
  \catcode0=9 %
  \catcode`\^=7 %
  \catcode`\^^^=12 %
  \def\x{^^^^0000}%
\expandafter\endgroup
\ifx\x\@empty

最終行の\ifxは「^^^^0000という4桁のTeXエスケープを認識するエンジン」、つまりLuaTeX・XeTeXで真になる。真の場合には、\HyPsd@Charが「Unicode対応」になる。

• 現状では、pxjahyperにおいて、「upLaTeXでかつunicode有効の場合は、\HyPsd@Charを『Unicode対応のエンジン』でのhyperrefのものと同一になるよう再定義する」という処置をしている。
• upTeXの場合は“Unicodeの文字”は実際には和文文字トークンなので、XeTeX・LuaTeXの場合とは状況が完全に同じとはいえないが、取りあえず実情としてはこれで正常動作している。

[zr-tex8r]

自分が「unicode有効」を維持した方がよいと考える理由。

※参考→https://zrbabbler.hatenablog.com/entry/20171028/1509208283

• XeTeX・LuaTeXの場合のhyperrefの普通の処理に合わせておくと、将来hyperrefが拡張されて「PDF文字情報」の種類が増えた場合にも自動的にupLaTeXにも適応されるようになるから。
  • hyperrefの\pdfstringdefを利用する他パッケージの機能についても同様のことがいえる。
  • もしかしたら、dvipsでも対応できる？
• (u)pTeX独自の「dvipdfmxのtounicode specialに任せる」という方策をとった場合、「PDF文字情報」の種類が増えた場合には、実はdvipdfmxのソフトウェアを「増えた部分」に対応させる必要がある。
  • 参考→(x)dvipdfmx が文書情報を Unicode する件に関するメモ(3)

[u-fischer]

Sorry I have no idea what this issue is about, but I see hyperref and unicode. So if there is something hyperref can do to better support platex/uplatex then please open an issue at the hyperref github so that we can discuss it.

As you are probably aware we released a pdfmanagement-testphase package which will extend and change the core pdf support of LaTeX. This package also contains a new hyperref driver as the current drivers are not compatible with the new pdf management. It would be good to know if there is something missing for the platex/uplatex support.