現在
角藤先生W32TeXを使用しています。
ヒラギノフォントを購入し、Windows 7で使おうと
TeXの設定をしていたのですが、
OTFパッケージ安定版(v1.2.9 2007/3/19)使用時に\ebseriesが文字化けしてしまいます。
\documentclass{jsarticle}
\usepackage[expert,deluxe]{otf}
\begin{document}
{\gtfamily\ebseries ほげほげ}
{\gtfamily\bfseries ほげほげ}
\end{document}
のようなファイルをdvipskを使いpostscriptに変えたところ、(platex, dvipskとも特にエラーは表示されません)
\ebseriesを指定した部分のみ文字化けを起こしてしまいます。
(\bfseriesの部分は正常です)
dviファイルはdvioutにて正常に表示されています。
(bfseriesとebseries両方)
OTF/UTF パッケージ用のhiragino.mapは
\usr\local\share\texmf\fonts\map\dvips\base\
に配置し、
config.ps
にp +hiragino.map
を追記しました。
gsviewの
\gs\gs8.71\Resource\CIDFont
にはフォントのシンボリックリンクを
HiraKakuStd-W8
というファイル名で作成してあります。
設定は済んでいると思うのですが、gsviewにてpostscriptファイルが文字化けしてしまいます。
dvipdfmxでは正常にpdfが作成されるので、
dvipsの設定が間違っているのだと思います。
どこをチェックすればよいかどうかご教示ください。
間違いないと思いますが・・・・
さて・・・私は64ビットは使ってませんが
>W32TeX での利用には使えないという点を押さえておいてください)。
>
>W32TeX 一式が64bitOSでは WOW64 による32bit互換アプリとして動作する32bitネイティブなソフト(群)だからです。
このくだり,まったく理解できません.
なぜ64bit版のWinで使うGS/Gsview/Perなどが
32bit版である必要があるのか?
またその根拠がW32TeXが32bitであるからとなるのか?
いろいろな情報はそれなりにもってますが
実は64ビット絡みで
「あれこれが動かない!」という
話は一度も聞いてません.
#もちろん単純なPATH間違いとかは除く
ということで,どこかに
「動かん!」という症例(エラー窓のキャプチャとか
はっきりわかるもの)があるならぜひ.
もしくはMSなりそれなりのところが
こういう勧告なり情報をだしているなら
英語でも日本語でもいいのでぜひ.
#さすがにフランス語とかだったらきびしいけど
常識的また商業的およびMSのサポートのコストを
考えた場合,
いままで32ビットで動いてきた世界を
64ビットにかえるとき
できるだけ過去との互換を考えるはず.
その場合,一番簡単なのは
アプリケーションが32なのか64なのかは
OS側が判断することにして
またアプリケーション間の連携は
今までの(MS推奨の)作法を守っていれば
やはりOS側で処理するように
細工をいれることでしょう.
つまりユーザ側からは32ビット・64ビットは
可能な限り隠蔽する,
そしてどうしても隠蔽しきれない部分は
大々的に告知するという感じですか.
#アプリケーションを作る側はまた別の話.
#64をフル活用したければ専用に作るのは当然だけど
#変わりに「32ビットに64をいれたが動かん!」とかの
#サポートの覚悟を背負い込むことになる・・・.
また,W32TeX(やdviout)が呼び出し
その結果を利用するものは一般に
テキストそのものであったり,変換した画像で
あることがほとんどです.
さらにこれらのデータは「ファイル」の形で
受けわたされる,もしくは
パイプやリダイレクトで「テキスト」で渡される
ことがほぼすべてでしょう.
このようなデータ形式が
32・64の問題にあたるとは思えません.
#PowerShellのように何でもかんでも
#.netなオブジェクトで渡す
#というなら理解できなくないのだけど・・・
本田さん、はじめまして。
>いろいろな情報はそれなりにもってますが
>実は64ビット絡みで
>「あれこれが動かない!」という
>話は一度も聞いてません.
私もこのディスカッションを立てられた方と同様「Windows 7 Pro x64」を利用しています。
以前の「あべのりインストーラ」では64bit版Windows上で利用する際には、角藤先生がGhostscript 8.71が本家のx86用をアレンジした形で配布しているにもかかわらず、GSView 4.9はx64をインストールするようになっていました。
このためGhostscript・GSView間の連携ができなくなり、「あべのりインストーラ」(開発版・2010.3.21)ではOSのbit数にかかわらず、Ghostscript・GSViewはいずれも x86 がインストールされるように仕様変更されています。
もっとも、角藤先生の配布している Ghostscript 8.71 が x64 のアレンジしたものに差し替われば、状況は変わると思います。
ActivePerl 5.12 ですが、TeX の利用の有無にかかわらず、x86 に比べ、パッケージの充実度合いが x64 の方が低く、x86 を 64bit版Windows 上にあえて入れることも少なくありません。
TeXでPerlと連携してコンパイルする場面は emath 等でもあります。その際の pl ファイルは x86 の ActivePerl での動作を前提にして書かれていると思われます。TeX の実行ファイルが x86 命令で、Perl が x64 だとすれば、連携時にどうなるかの検証は行っていないので何ともいえません。pl ファイルに x64 に由来するコードがあれば、連携時に問題になるかもしれませんが…。
TeX の利用の有無とは別の次元の問題も絡むため、 x86 に3つ組みでそろえて当面運用した方がいいかな、と思っています。
これとは別に「W32TeX」で以前、当時の最新版を入れたときに64bit版Windows上におけるファイルのアクセス権絡みの問題が発生したことにより「W32TeX」が修正されたようです。 TeX Q&A の過去ログにありました。
「WOW64」は互換性が高いですが、100点満点ではない(99点くらい?)という一例だと思います。
kconfig.psを修正し、解決いたしました。
問題は解決したつもりですが、
Ghostscriptの設定に関して
http://oku.edu.mie-u.ac.jp/~okumura/texwiki/?Ghostscript%208.xx
をみて
1. cidfmap
2. \usr\local\share\texmf\fontsに置くファイル
http://oku.edu.mie-u.ac.jp/~okumura/texwiki/?Ghostscript%208.xx#otf
3. kconfig.ps
などあることを初めて知り混乱しております。
オプション “-dWINKANJI”をつけない場合、
1や2からgsviewで表示されるフォントが決定され、
gs\gs8.71\Resource\CIDFontに配置したフォント(またはそのシンボリックリンク)が使用される、
オプション “-dWINKANJI”をつける場合
3 kconfig.psからgsviewで表示されるフォントが決定され、
記述したフォント名を使ってC:\Windows\Fontsにインストールしたフォントが使用される、
という理解でよろしいのでしょうか。