いつも大変的確なご助言をいただき、有り難うございます。大変申し訳ないのですが再びご助言を仰ぎたい事態が発生しました。少し長文になりますがよろしくお願い致します。
Debian 9.6環境でTeX 2017を使用しています。GhostScriptのみ"ftp.jp.debian.org"からインストールし、定期的にアップデートしています。今年の5-6月頃、gsがアップデートされる(この時のバージョンは、たしか9.20前後)と共に突然乱調になりました。
ビューアにpxdviを使用しているのですが、ソースに:
\special{psfile=#1.......}
が含まれると画像データのロードに失敗する。
しかしながら、dvipdfmxにてpdfファイル作成は正常にできるため「そのうち治るだろう。」と放置しておりました。
一昨日gsは再びアップデートされ(9.25)、上記の不具合は完全に解消しました。同時に、今度はdvipdfmxで同様なトラブルが発生します。
GPL Ghostscript 9.25: Unrecoverable error, exit code 1
dvipdfmx:warning: Filtering file via command -->rungs -q -dNOPAUSE -dBATCH -dEPSCrop -sPAPERSIZE=a0 -sDEVICE=pdfwrite -dCompatibilityLevel=1.5 -dAutoFilterGrayImages=false -dGrayImageFilter=/FlateEncode -dAutoFilterColorImages=false -dColorImageFilter=/FlateEncode -dAutoRotatePages=/None -sOutputFile='/tmp/dvipdfm-x.b153376ac17aca8bfdb182b45f3d8976' './絵/ps/ad12-8_1.ps' -c quit<-- failed.
と宣うため、次のコマンドを単独で実行すると:
gs -q -dNOPAUSE -dBATCH -dEPSCrop -sPAPERSIZE=a0 -sDEVICE=pdfwrite -dCompatibilityLevel=1.5 -dAutoFilterGrayImages=false -dGrayImageFilter=/FlateEncode -dAutoFilterColorImages=false -dColorImageFilter=/FlateEncode -dAutoRotatePages=/None -sOutputFile='/tmp/dvipdfm-x.b153376ac17aca8bfdb182b45f3d8976' './絵/ps/ad12-8_1.ps' -c quit
Error: /undefinedfilename in (.//ps/ad12-8_1.ps)
等と怒ります。試みにファイルパスの日本語を英語に書き換えると正常に駆動します(pdfファイルもできます。)。しかしながらこの形式の(日本語パスを含む\special{})コードは膨大な数があるため途方に暮れています。
私はどうしたらよいでしょう?
尚、日本語環境はEUCです。お手数ですがよろしくご回答ください。
投稿が途切れてしまったので続きを書きます。
....と宣います。そこで次のコマンドを単独で実行すると:
gs -q -dNOPAUSE -dBATCH -dEPSCrop -sPAPERSIZE=a0 -sDEVICE=pdfwrite -dCompatibilityLevel=1.5 -dAutoFilterGrayImages=false -dGrayImageFilter=/FlateEncode -dAutoFilterColorImages=false -dColorImageFilter=/FlateEncode -dAutoRotatePages=/None -sOutputFile='/tmp/dvipdfm-x.b153376ac17aca8bfdb182b45f3d8976' './絵/ps/ad12-8_1.ps' -c quit
Error: /undefinedfilename in (.//ps/ad12-8_1.ps)
等と怒ります。試みにファイルパスに含まれる日本語を英語に書き換えてみると正常に駆動します(pdfファイルもできます。)。しかしながら上記のようなコード(日本語を含む\special{})は膨大な数があり、途方に暮れています。
私はどうしたらよいのでしょうか?
尚、日本語環境はEUCです。
....と宣います。そこで次のコマンドを単独で実行すると:
gs -q -dNOPAUSE -dBATCH -dEPSCrop -sPAPERSIZE=a0 -sDEVICE=pdfwrite -dCompatibilityLevel=1.5 -dAutoFilterGrayImages=false -dGrayImageFilter=/FlateEncode -dAutoFilterColorImages=false -dColorImageFilter=/FlateEncode -dAutoRotatePages=/None -sOutputFile='/tmp/dvipdfm-x.b153376ac17aca8bfdb182b45f3d8976' './絵/ps/ad12-8_1.ps' -c quit
Error: /undefinedfilename in (.//ps/ad12-8_1.ps)
等と怒ります。試みにファイルパスに含まれる日本語を英語に書き換えてみると正常に駆動します(pdfファイルもできます。)。しかしながら上記のようなコード(日本語を含む\special{})は膨大な数があり、途方に暮れています。
私はどうしたらよいのでしょうか?
尚、日本語環境はEUCです。
再現テストのため debian9.6 with texlive2018 は用意したのですが、\special に詳しくないので挫折。簡単な再現例を提示していただければと思います。
さて、ファイルパスを英語に置き換えれば通るとのことなので debian であればそのような問題に容易に対応できるのでチャレンジしてみるお気持ちがあれば釈迦に説法ではありますが ....
targets=$(grep -l -r -e ’/絵/[a-z]' )
sed -i -e 's%(.\)/絵 /\([a-z]\)%\1/PICTURE/\2%' ${targets}
検索・置き換えパターンはあくまで例です。
さて、ファイルパスを英語に置き換えれば通るとのことなので debian であればそのような問題に容易に対応できるのでチャレンジしてみるお気持ちがあれば釈迦に説法ではありますが ....
targets=$(grep -l -r -e ’/絵/[a-z]' )
sed -i -e 's%(.\)/絵 /\([a-z]\)%\1/PICTURE/\2%' ${targets}
検索・置き換えパターンはあくまで例です。
ファイルシステムの encodeも EUC なのかしら？と思いつtも
なんとか EUC コードのディレクトリ作成し、再現することを確認しました。
（なので ln -s 絵 「EUCの絵」 として実験したので EUC と UTF8 両方
でアクセスできるようにしてあるので厳密な再現環境ではないのですが）
また debian だけでなく MacOS でも ghostscript が 9.25 以上であれば
再現するようです。
dvi に埋め込まれた psfile のパスが EUC になっているようなので、
日本語のファイル名が UTF8 でも 9.25 では発生すると思います。
今回の ghostscript のアップデートは脆弱性対応なので package の
ダウングレードをしない方向で検討。
自力コンパイルなどを検討しましたが linux 用のプリコンパイルされ
たものを見つけたのでそれを利用したところ
dvipdfmx は無事通るようになりました。
以下は、その概略手順です。
プリコンパイルされたものは https://github.com/ArtifexSoftware/ghostpdl-downloads/releases/download/gs922/ghostscript-9.22-linux-x86_64.tgz を利用しました。
これを展開すると
ghostscript-9.22-linux-x86_64/
ghostscript-9.22-linux-x86_64/gs-922-linux-x86_64
ghostscript-9.22-linux-x86_64/README.txt
ghostscript-9.22-linux-x86_64/COPYING
になるので
cd ghostscript-9.22-linux-x86_64/
ln -s gs-922-linux-x86_64 gs
export PATH=$(pwd):$PATH
このようにダウンロードしたプリコンパイル gs を最優先するようにしました。
＃脆弱性を内在させたものなので限定してお使いください。
＃9.25 を使うのならとりあえずは日本語のパスをアルファベットのものに
＃書き換えることをお勧めします。
なんとか EUC コードのディレクトリ作成し、再現することを確認しました。
（なので ln -s 絵 「EUCの絵」 として実験したので EUC と UTF8 両方
でアクセスできるようにしてあるので厳密な再現環境ではないのですが）
また debian だけでなく MacOS でも ghostscript が 9.25 以上であれば
再現するようです。
dvi に埋め込まれた psfile のパスが EUC になっているようなので、
日本語のファイル名が UTF8 でも 9.25 では発生すると思います。
今回の ghostscript のアップデートは脆弱性対応なので package の
ダウングレードをしない方向で検討。
自力コンパイルなどを検討しましたが linux 用のプリコンパイルされ
たものを見つけたのでそれを利用したところ
dvipdfmx は無事通るようになりました。
以下は、その概略手順です。
プリコンパイルされたものは https://github.com/ArtifexSoftware/ghostpdl-downloads/releases/download/gs922/ghostscript-9.22-linux-x86_64.tgz を利用しました。
これを展開すると
ghostscript-9.22-linux-x86_64/
ghostscript-9.22-linux-x86_64/gs-922-linux-x86_64
ghostscript-9.22-linux-x86_64/README.txt
ghostscript-9.22-linux-x86_64/COPYING
になるので
cd ghostscript-9.22-linux-x86_64/
ln -s gs-922-linux-x86_64 gs
export PATH=$(pwd):$PATH
このようにダウンロードしたプリコンパイル gs を最優先するようにしました。
＃脆弱性を内在させたものなので限定してお使いください。
＃9.25 を使うのならとりあえずは日本語のパスをアルファベットのものに
＃書き換えることをお勧めします。
和田 勇 様
随分とお手数をかけてしまい。お詫びと御礼を申し上げます。ご指摘の内容を基に私なりに検討し、以下の様に対策しようと考えております。
1.aptやaptitudeを用いたダウングレードは限界があり、戻れたとしてもごく最近のバージョンまでしか戻れない。
2.ご指摘のurlはgs本家のものと思われますが、ここから過去に実績のあるver9.10のソースコードを利用して自分でビルドしてみる。
Debian環境も影響するようで簡単にはビルドできませんが、一応バイナリの作成に成功しました。
実際にこれを用いてプリビューア、pdf出力もうまく行く様です。
3.今後、暇をみてバージョンを上げていき「使える/使えない」を見極めたいと考えております。
4.少なくとも今後はGhostscriptについてaptあるいはaptitudeによるバージョン管理は止めます。
突然の依頼に対し丁寧に対応いただきました。重ねて御礼申し上げます。
随分とお手数をかけてしまい。お詫びと御礼を申し上げます。ご指摘の内容を基に私なりに検討し、以下の様に対策しようと考えております。
1.aptやaptitudeを用いたダウングレードは限界があり、戻れたとしてもごく最近のバージョンまでしか戻れない。
2.ご指摘のurlはgs本家のものと思われますが、ここから過去に実績のあるver9.10のソースコードを利用して自分でビルドしてみる。
Debian環境も影響するようで簡単にはビルドできませんが、一応バイナリの作成に成功しました。
実際にこれを用いてプリビューア、pdf出力もうまく行く様です。
3.今後、暇をみてバージョンを上げていき「使える/使えない」を見極めたいと考えております。
4.少なくとも今後はGhostscriptについてaptあるいはaptitudeによるバージョン管理は止めます。
突然の依頼に対し丁寧に対応いただきました。重ねて御礼申し上げます。
関連のトピックス「pTeX/upTeXの日本語ファイル名」(texjporg @ GitHub) を貼っておきます。
pLaTeX かつ内部コードEUC で実行している場合、specialで書き出されるファイル名の文字列はEUCになっているはずです。
昔のghostscriptで使えていたのに最新版では使えなくなったということは、そのEUCが通らなくなったためでしょう。
対処法としては大きく分けて3つあると思います。
- pLaTeXを使いつづけファイル名をASCIIに変更する。
- upLaTeXに乗り換えファイル名もLinuxのロケールもUTF-8に統一する。
- pLaTeXおよび漢字ファイル名を使うが、specialのファイル名の文字列をEUC→UTF-8に変換後、dvipdfmx, ghostscriptに渡す。
レガシーエンコーディングを使い続けるのには今の時代、大変な労力を伴います。このため、個人的には1または2を推奨します。
3は TeX Live 2017にも入っているはずの dv2dt/dt2dv を利用して適当な変換スクリプトでも書けば実現できると思います。
GitHubにも書きましたが、変換の手法はそれに限らずいくらでも手段はあると思います。
t tk様
ご指摘有り難うございます。
-->...レガシーエンコーディングを使い続けるのには今の時代、大変な労力を伴います...
仰るとおりだと思います。昔々Sun-3なるコンピュータがありまして、これは日本語が使えませんでした。その後Sparc何某というコンピュータの時代にeucコードなるものが出、同時にTeXなるソフトウエアを紹介されたのが始まりです。
当初はバイナリを利用しておりましたが、そのうちASCII版TeXなるものを自分でビルドする時代が長く続き、現在に至りました。
TeX以外にもOS環境、C/C++利用においてレガシーエンコーディングの壁が高く聳えているのを日々感じております。私自身utf-8環境は既に製作済みですが、それでもeucから離れることができません。現在の私の年齢を考えますと、もはや不可能事と考えております。
ご指摘有り難うございます。
-->...レガシーエンコーディングを使い続けるのには今の時代、大変な労力を伴います...
仰るとおりだと思います。昔々Sun-3なるコンピュータがありまして、これは日本語が使えませんでした。その後Sparc何某というコンピュータの時代にeucコードなるものが出、同時にTeXなるソフトウエアを紹介されたのが始まりです。
当初はバイナリを利用しておりましたが、そのうちASCII版TeXなるものを自分でビルドする時代が長く続き、現在に至りました。
TeX以外にもOS環境、C/C++利用においてレガシーエンコーディングの壁が高く聳えているのを日々感じております。私自身utf-8環境は既に製作済みですが、それでもeucから離れることができません。現在の私の年齢を考えますと、もはや不可能事と考えております。