名前: ZR 日時: 2007-08-15 02:17:44 IPアドレス: 59.140.98.*
>>49096 >>>49068 >>>49069 >これでいかがでしょう? >これでよろしければ次回差し替えます。 問題ないと思います。 >>>49087 >>>その他、vfの軽量化をしました。 >>これは、扱う文字の集合を小さくしているのだと思いますが、どういう >>集合なのでしょうか。(AJ1-6 と Unicode の共通部分?) >UnicodeのBlock毎 >(http://www.unicode.org/Public/UNIDATA/Blocks.txt)に >Adobe-CNS1-5, Adobe-GB1-5, Adobe-Japan1-6, Adobe-Korea1-2 >の文字を一文字でも含んでいれば、vfに登録するようにしてみました。 >(日本語ならAdobe-Japan1-6) >ただし、BMP内のPrivate Use Area は全て登録しました。 承知しました。 > 3. Unicode へのマップ: CP932 vs JIS X 0208 upTeX のような「ネイティブな Unicode アプリケーション」では、入力となる Unicode 文書の文字は Unicode の規準に従って選ぶ(例えば U+2014 EM DASH と U+2015 HORIZONTAL BAR を使い分ける)のが本来の姿でしょう。しかし、これ は理想あるいは将来の姿であって、旧来の符号系の存在がまだ大きい現状では、 Unicode 文書が旧来符号系の影響を受けるのは避け難い所でしょう。 upTeX の動作の中で「JIS 符号 → Unicode」の変換が行われる場面は少なくと も 2 つあります(まだある?): 1. \jis, \sjis, \euc プリミティブ 2. ISO-2022-JP のソースを読む場合 # この 2. が可能なことは仕様として保証されるのですか?? 逆の「Unicode → JIS 符号」の変換は使われないと理解しています。 これとは別に、「従来の pTeX との互換性を確保する」為に、pTeX の設定を upTeX に持ち込もうとすると、そこで「JIS 符号 → Unicode」の変換を考慮 しなければなりません(先の \inhibitxspcode の例のように)。 これについては、私は JIS→Unicode が一対多になる場合は、元の JIS の設定を変換先の複数の Unicode 文字の全てに引き継ぐことにすればよい(例えば波ダッシュの場合、 "301C と "FF5C の kcatcode 以外の全てのパラメタを pTeX の波ダッシュ と同じにする) と考えていました。こうすれば、上述の upTeX 自身が行う JIS→Unicode 変換 の影響が軽減できるからです。 # Unicode での設定は「和文扱い」に限り有効であることに注意。 ところが、既定のフォント設定である jis や min10 系のフォント(upTeX では Unicode 版の ujis/umin10 等となります)では、それだけでは上手くいかない 場合があることが判りました。 dvipdfmx では、これらのフォントは CMap で Unicode から Adobe-Japan1 の CID に変換し、CID エンコーディングの実フォントに対応付けています。 # jis/min10 は元の符号が JIS エンコーディングであるこを以外は同じ処理。 従って、ujis の CMap (UniJIS-UTF16-H) での変換結果が、jis の CMap (H) でのそれと一致しなければ「同じ結果」にはなりません。それ自体は許容できる (全く同じでなくてもよい)としても、場合によっては「全角幅でない」不適切な グリフが選ばれたり、さらに悪い場合は、Adobe-Japan1 に対応するグリフが存 在しないこともあります。 # 詳解は略すが、"urml" が想定する字幅は、明示的に半角幅としているものを # 除けば、全角幅でなければならない。 例えば、JIS の "2142 の <‖> を考えます。これを Unicode に直すと JIS に従った(0208 の)変換では U+2016 DOUBLE VERTICAL LINE Microsoft の(CP932 の)変換では U+2225 PARALLEL TO となります。さらにこれらを CMap (H / UniJIS-UTF16-H) で変換すると JIS 2142 の変換結果は CID 00666 (双柱; 全角幅) Unicode 2016 の変換結果は CID 00666 Unicode 2225 の変換結果は CID 15489 (平行; 全角幅でない) となります。従って、JIS 符号系で書かれた <‖> を含む pTeX のソースを UTF-8 に変換して upTeX で処理した場合、<‖> が U+2016 になった場合はいい ですが、U+2225 になった場合(Windows プログラムで変換した場合に可能性大) は不適切な組版結果になります。 # さらに、<‖> の場合、upTeX 自身の JIS→Unicode 変換も U+2225 を返すの # で、ISO-2022-JP のまま upTeX で処理した場合も不適切となる。 # 余談: # MS 明朝の JIS 2142 (U+2225) のグリフは旧版では「双柱」(線が垂直)でし # たが、新版(Vista のもの)では「平行」(線が斜め)になっていて、U+2016 に # 「双柱」があります。MS 明朝の U+2225 は全角幅です。 ujis の性格を考えると、CMap の変換結果が不適切な字幅のグリフになるような Unicode 文字は ujis では使えないと考えるべきなのでしょう(ujis/umin10 系 の他のフォントも同様)。そして ujis が upTeX の標準のフォントである以上、 upTeX 自身の JIS→Unicode 変換の結果が ujis 非対応の文字になること は少なくとも避けるべき だと思います(これに該当するのは U+2225 だけですが)。 さて問題なのは、これらの「JIS 符号系からの変換で現れうる Unicode 文字で ujis で使えないもの」について ujis は何らかの対策を講ずるべきかというこ とです。例えば、U+2225 を vf を用いて U+2016 に置換する等の策が考えられ ます(この場合、ujis→urml の vf に組み込むことになるでしょう)。 この事案に対する皆様はどうお考えでしょうか。 # もちろん、upTeX で使える和文フォントは Adobe-Japan1 の CID フォントに # は限らず(dvipdfmx の cid-x.map でエンコードを "unicode" とすることで # 直接 Unicode エンコードのフォントが扱える)、またどんな文字集合と字幅 # を持つフォントでもそれ専用の tfm を用意すれば扱えるので、上述の議論は # ujis/umin10 に特有のもので、upTeX 自身の問題ではない。 ---- 参考として、ptexenc において JIS→Unicode 変換が「一対多」となっている 文字に対して、Unicode 文字の Adobe-Japan1 への変換結果を載せておきます。 また JIS の文字の pTeX でのパラメタ設定も添えました。 jtype: jis メトリックでの TYPE。既定値=0 mtype: min10 メトリックでの TYPE。既定値=0 ixspc: \inhibitxspcode の値。既定値=3 prebp: \prebreakpenalty の値。既定値=無設定 pstbp: \postbreakpenalty の値。既定値=無設定 (該当なし) 2126 <・> jtype=3,prebp=10000 U+2022 BULLET → CID 00119 ×(Prop幅) U+2219 BULLET OPERATOR → CID 00117 ×(Prop幅) U+22C5 DOT OPERATOR → 対応なし *U+30FB KATAKANA MIDDLE DOT → CID 00638 ○(全角幅) 2131 <￣> U+203E OVERLINE → CID 00226 ×(Prop幅) *U+FFE3 FULLWIDTH MACRON → CID 00649 ○(全角幅) 213D <―> ixspc=0 U+2012 FIGURE DASH → CID 00114 ×(半角幅) U+2013 EN DASH → CID 00114 ×(半角幅) U+2014 EM DASH → CID 00138 ○(全角幅) *U+2015 HORIZONTAL BAR → CID 00661 ○(全角幅) 2141 <〜> ixspc=0 U+223C TILDE OPERATOR → CID 00100 ×(Prop幅) U+223E INVERTED LAZY S → 対応なし U+301C WAVE DASH → CID 00665 ○(全角幅) *U+FF5E FULLWIDTH TILDE → CID 00665 ○(全角幅) 2142 <‖> mtype=4 U+2016 DOUBLE VERTICAL LINE → CID 00666 ○(全角幅) *U+2225 PARALLEL TO → CID 15489 ×(Prop幅) 2143 <｜> mtype=4 U+2223 DIVIDES → 対応なし *U+FF5C FULLWIDTH VERTICAL LINE → CID 00667 ○(全角幅) 2144 <…> jtype=5,ixspc=0,prebp=250 *U+2026 HORIZONTAL ELLIPSIS → CID 00668 ○(全角幅) U+22EF MIDLINE HORIZONTAL ELLIPSIS → 対応なし 215D <−> jtype=5,prebp=200 U+2212 MINUS SIGN → CID 00693 ○(全角幅) *U+FF0D FULLWIDTH HYPHEN-MINUS → CID 00693 ○(全角幅) 216f <￥> ixspc=0 U+00A5 YEN SIGN → CID 00061 ×(Prop幅) *U+FFE5 FULLWIDTH YEN SIGN → CID 00711 ○(全角幅) 2171 <¢> mtype=3 U+00A2 CENT SIGN → CID 00102 ×(Prop幅) *U+FFE0 FULLWIDTH CENT SIGN → CID 00713 ○(全角幅) 2172 <£> mtype=3 U+00A3 POUND SIGN → CID 00103 ×(Prop幅) *U+FFE1 FULLWIDTH POUND SIGN → CID 00714 ○(全角幅) 224C <¬> U+00AC NOT SIGN → CID 00153 ×(Prop幅) *U+FFE2 FULLWIDTH NOT SIGN → CID 00751 ○(全角幅) 227E <◯> U+20DD COMBINING ENCLOSING CIRCLE → CID 16328 ○(全角幅) *U+25EF LARGE CIRCLE → CID 00779 ○(全角幅)
この書き込みへの返事：