中韓フォントの JFM #2
Comments
|
CTANに zhmetrics-uptex というパッケージがあります。中国の方が作られたもののようです。 |
|
確かにそれは私も考えています。zhmetrics-uptex は簡体中国語なので，これを元に簡体は作れるのですが，繁体は事例がないようなので，調べる必要がありそうです。 |
|
zhmetrics-uptex を見てみましたが、これは
で中身が（ヘッダのフォント名以外）完全に同一でした。makemetrics.lua が Makefile の代わりですが、実行コマンドも 簡体中国語は現行で問題なさそうだ、ということはわかりましたが、繁体中国語に詳しい方がいらっしゃると良いのですが… 少なくとも現行の |
|
繁体中国語の場合、CLreq を見る限り、句点類と読点類は、行末に来ても直後に終わり括弧類を伴っても、半角分のスペースを詰めるようなことはないようです。ということは「、」「，」「。」「．」には JFM グルーを持たせる必要なくて，単に TYPE 0 の文字として扱えば良いのかもしれません。 そう考えて、安直にこれらを削除した JPL ソースを作ってみました。（と言っても、TYPE 2 から「、」「，」を削除し、TYPE 4 を丸ごと削除したあと、番号が連続するように TYPE 5 を TYPE 4 にリネームしただけですが。）仮に uptchcr-{h,v}.pl という名前にして、upjisr-{h,v}.pl からの差分を載せてみます。 --- upjisr-h.pl 2017-07-02 18:42:20.000000000 +0900
+++ uptchcr-h.pl 2017-07-02 18:56:09.000000000 +0900
@@ -1,5 +1,5 @@
(COMMENT THIS IS A KANJI FORMAT FILE)
-(FAMILY UPJIS KANJI)
+(FAMILY UPTCH CENTER KANJI)
(FACE F MRR)
(CODINGSCHEME TEX KANJI TEXT)
(DESIGNSIZE R 10.0)
@@ -29,7 +29,7 @@
(GLUE O 0 R 0.500000 R 0.0 R 0.500000)
(GLUE O 1 R 0.500000 R 0.0 R 0.500000)
(GLUE O 3 R 0.250000 R 0.0 R 0.250000)
- (GLUE O 5 R 0.500000 R 0.0 R 0.500000)
+ (GLUE O 4 R 0.500000 R 0.0 R 0.500000)
(STOP)
(LABEL O 3)
(GLUE O 0 R 0.250000 R 0.0 R 0.250000)
@@ -37,18 +37,11 @@
(GLUE O 2 R 0.250000 R 0.0 R 0.250000)
(GLUE O 3 R 0.500000 R 0.0 R 0.250000)
(GLUE O 4 R 0.250000 R 0.0 R 0.250000)
- (GLUE O 5 R 0.250000 R 0.0 R 0.250000)
(STOP)
(LABEL O 4)
- (GLUE O 0 R 0.500000 R 0.0 R 0.0)
- (GLUE O 1 R 0.500000 R 0.0 R 0.0)
- (GLUE O 3 R 0.750000 R 0.0 R 0.250000)
- (GLUE O 5 R 0.500000 R 0.0 R 0.0)
- (STOP)
- (LABEL O 5)
(GLUE O 1 R 0.500000 R 0.0 R 0.500000)
(GLUE O 3 R 0.250000 R 0.0 R 0.250000)
- (KRN O 5 R 0.0)
+ (KRN O 4 R 0.0)
(STOP)
)
(CHARSINTYPE O 1
@@ -57,7 +50,7 @@
UFF5F U3018 U3016 U301D
)
(CHARSINTYPE O 2
- 、 ， ’ ” ） 〕 ］ ｝ 〉 》
+ ’ ” ） 〕 ］ ｝ 〉 》
」 』 】
UFF60 U3019 U3017 U301F
)
@@ -65,9 +58,6 @@
・ ： ；
)
(CHARSINTYPE O 4
- 。 ．
- )
-(CHARSINTYPE O 5
— ― … ‥
)
(TYPE O 0
@@ -95,7 +85,7 @@
(GLUE O 0 R 0.500000 R 0.0 R 0.500000)
(GLUE O 1 R 0.500000 R 0.0 R 0.500000)
(GLUE O 3 R 0.250000 R 0.0 R 0.250000)
- (GLUE O 5 R 0.500000 R 0.0 R 0.500000)
+ (GLUE O 4 R 0.500000 R 0.0 R 0.500000)
)
)
(TYPE O 3
@@ -108,27 +98,15 @@
(GLUE O 2 R 0.250000 R 0.0 R 0.250000)
(GLUE O 3 R 0.500000 R 0.0 R 0.250000)
(GLUE O 4 R 0.250000 R 0.0 R 0.250000)
- (GLUE O 5 R 0.250000 R 0.0 R 0.250000)
)
)
(TYPE O 4
- (CHARWD R 0.500000)
- (CHARHT R 0.880000)
- (CHARDP R 0.120000)
- (COMMENT
- (GLUE O 0 R 0.500000 R 0.0 R 0.0)
- (GLUE O 1 R 0.500000 R 0.0 R 0.0)
- (GLUE O 3 R 0.750000 R 0.0 R 0.250000)
- (GLUE O 5 R 0.500000 R 0.0 R 0.0)
- )
- )
-(TYPE O 5
(CHARWD R 1.000000)
(CHARHT R 0.880000)
(CHARDP R 0.120000)
(COMMENT
(GLUE O 1 R 0.500000 R 0.0 R 0.500000)
(GLUE O 3 R 0.250000 R 0.0 R 0.250000)
- (KRN O 5 R 0.0)
+ (KRN O 4 R 0.0)
)
)--- upjisr-v.pl 2017-07-02 18:42:21.000000000 +0900
+++ uptchcr-v.pl 2017-07-02 19:14:52.000000000 +0900
@@ -1,6 +1,6 @@
(COMMENT THIS IS A KANJI FORMAT FILE)
(DIRECTION TATE)
-(FAMILY UPJIS KANJI)
+(FAMILY UPTCH CENTER KANJI)
(FACE F MRR)
(CODINGSCHEME TEX KANJI TEXT)
(DESIGNSIZE R 10.0)
@@ -30,7 +30,7 @@
(GLUE O 0 R 0.500000 R 0.0 R 0.500000)
(GLUE O 1 R 0.500000 R 0.0 R 0.500000)
(GLUE O 3 R 0.250000 R 0.0 R 0.250000)
- (GLUE O 5 R 0.500000 R 0.0 R 0.500000)
+ (GLUE O 4 R 0.500000 R 0.0 R 0.500000)
(STOP)
(LABEL O 3)
(GLUE O 0 R 0.250000 R 0.0 R 0.250000)
@@ -38,18 +38,11 @@
(GLUE O 2 R 0.250000 R 0.0 R 0.250000)
(GLUE O 3 R 0.500000 R 0.0 R 0.250000)
(GLUE O 4 R 0.250000 R 0.0 R 0.250000)
- (GLUE O 5 R 0.250000 R 0.0 R 0.250000)
(STOP)
(LABEL O 4)
- (GLUE O 0 R 0.500000 R 0.0 R 0.0)
- (GLUE O 1 R 0.500000 R 0.0 R 0.0)
- (GLUE O 3 R 0.750000 R 0.0 R 0.250000)
- (GLUE O 5 R 0.500000 R 0.0 R 0.0)
- (STOP)
- (LABEL O 5)
(GLUE O 1 R 0.500000 R 0.0 R 0.500000)
(GLUE O 3 R 0.250000 R 0.0 R 0.250000)
- (KRN O 5 R 0.0)
+ (KRN O 4 R 0.0)
(STOP)
)
(CHARSINTYPE O 1
@@ -58,7 +51,7 @@
UFF5F U3018 U3016 U301D
)
(CHARSINTYPE O 2
- 、 ， ’ ” ） 〕 ］ ｝ 〉 》
+ ’ ” ） 〕 ］ ｝ 〉 》
」 』 】
UFF60 U3019 U3017 U301F
)
@@ -66,9 +59,6 @@
・ ： ；
)
(CHARSINTYPE O 4
- 。 ．
- )
-(CHARSINTYPE O 5
— ― … ‥
)
(TYPE O 0
@@ -96,7 +86,7 @@
(GLUE O 0 R 0.500000 R 0.0 R 0.500000)
(GLUE O 1 R 0.500000 R 0.0 R 0.500000)
(GLUE O 3 R 0.250000 R 0.0 R 0.250000)
- (GLUE O 5 R 0.500000 R 0.0 R 0.500000)
+ (GLUE O 4 R 0.500000 R 0.0 R 0.500000)
)
)
(TYPE O 3
@@ -109,27 +99,15 @@
(GLUE O 2 R 0.250000 R 0.0 R 0.250000)
(GLUE O 3 R 0.500000 R 0.0 R 0.250000)
(GLUE O 4 R 0.250000 R 0.0 R 0.250000)
- (GLUE O 5 R 0.250000 R 0.0 R 0.250000)
)
)
(TYPE O 4
- (CHARWD R 0.500000)
- (CHARHT R 0.500000)
- (CHARDP R 0.500000)
- (COMMENT
- (GLUE O 0 R 0.500000 R 0.0 R 0.0)
- (GLUE O 1 R 0.500000 R 0.0 R 0.0)
- (GLUE O 3 R 0.750000 R 0.0 R 0.250000)
- (GLUE O 5 R 0.500000 R 0.0 R 0.0)
- )
- )
-(TYPE O 5
(CHARWD R 1.000000)
(CHARHT R 0.500000)
(CHARDP R 0.500000)
(COMMENT
(GLUE O 1 R 0.500000 R 0.0 R 0.500000)
(GLUE O 3 R 0.250000 R 0.0 R 0.250000)
- (KRN O 5 R 0.0)
+ (KRN O 4 R 0.0)
)
)uptch“c”r-{h,v} と “c” をつけたのは、Centered を意図しています。もしかすると句読点類が仮想ボディの中央でなく角に寄せてあるものもあるかもしれないので、現在配布しているものはそのままで、新規追加するのが良いだろうというつもりです。 |
|
従来版 uptchr-{h,v} で組んだものと新版 uptchcr-{h,v} で組んだものの比較です。 CLreq を完全に再現する意図はないのですが、（縦書きのクオートはさておき）、横・縦ともにカッコが仮想ボディの端にくっついていないので、なんだか微妙な出来栄えですね… 横書き、従来版
横書き、新版
縦書き、従来版
縦書き、新版
|
|
テフライブに台湾の繁体中国語の事例が極めて少ないのは、もしかしたら MiKTeX ベースで開発されている cwTeX がいまだによく知られているから、なのでしょうか？ ここの「cwTeX 使用手冊 [2005.10.7]」を見ると、これは横書きで句読点が仮想ボディの左下に寄ったフォントが使われています。一方 の質問を見る限り、繁体だと仮想ボディの中央に句読点がないと違和感があると感じる人もいるようで…？ 他の例は ですが、これは同じく横書きで句読点が仮想ボディの中央にあります。 cwTeX のほかには chiTeX も同じく台湾の方が作ったものですね。 まだよくわかっていませんが引き続き調査します。 |
|
句読点にグルーがないとするとやっぱり適切に行長を調節できないはずなので、他の例を調べてみると だと仮想ボディの中央に句読点があって、句読点が全角幅から shrink しているような気がします。仮想ボディの中央、という配置からすると、中点 “・” と同じ TYPE にするとよいのかも？ |
これを実現する場合、TFM を作るのは難なくできますが、VF を作るには手作業で U+3002（。）、U+3001（、）、U+FF0E（．）、U+FF0C（，）を MOVERIGHT しないといけないようです。自動化するには makejvf も何か「句読点類を仮想ボディの中央と仮定するオプション」を実装しないといけないことになります。 （メモ：例えば「中点」(U+30FB) は makejvf が以下のように MOVERIGHT で左にずらしている。 おそらくこれと同じことをやれば良いはず。） |
|
手作業でこれを実行して、句読点類の両側に JFM グルーが付いた状態で組むと、従来版より自然な組版結果になったと思います。JPL ソースはこれです。 従来版（句読点類の JFM グルーが右側だけ）
新版（句読点類の JFM グルーを両側に）
この結果を見て
が欲しくなったので、makejvf に「 これを使うと手作業が不要になって便利そうですが、どうでしょう？ |
|
自分が今把握していること。
|
|
繁体字中国語の〈。〉で留意すべきこと：
|
|
いろいろありがとうございます。私としては，
ものを作りたい，と思っています。 現時点の私の繁体字中国語の句読点類〈、。，．〉についての考えを改めて書いておくと
という感じです。 |
|
ちなみに，簡体中国語についてわからないことがあれば，CTeX-org の人（＝zhmetrics-uptex の作者）に GitHub 経由で質問しに行けばいい，と思っています。韓国語・繁体中国語はちょっとツテがありません。 |
JFM (.tfm) で同じクラスに入れる，ことは可能だと思いますが，そこから makejvf で VF を作るときにはどうすればよいのでしょう？ ほとんどの実フォントは U+00B7 のデザインが半角幅か可変幅と思われます。そのような状況下で，汎用的な VF を作れるのか疑問です。 → というか，「半角幅かもしれないし可変幅かもしれない」という時点で，汎用 JFM をつくることはできないと思われますね…。
arphic と fandol を確認すると，確かに半角幅に収まるようです。（他も確認して追記予定）
ptex-fontmaps の fandol（これはテフライブ収録のフリーな OTF）を見てみると，〈！〉は宋体・黑体ともに半角幅に収まっていますが，〈？〉は宋体では収まっている一方で，黑体でははみ出しています。同じフォント群でこのような違いがあることを考慮すると，〈。〉と同じクラスに入れるのは避けたほうがよさそうです。 |
悩ましいですが、それは日本語での「AJ1でないフォントでクオートがアレ」と同じ問題なので諦めるしかない気がします。なお、日本語と異なり「“UTF16-H”のCMapでアレ」という問題はないため、「Aﾎﾆｬ1なフォント」であれば全角幅になります。これを正統な状態として前提にするのでいいと考えます。
（多分、現実には、欧文の 各言語のレガシー文字コードにおいて“その記号”に当たるものは、ほぼ間違いなく、U+00B7 にマップされています。
|
改めて考えると，むしろ「Windows の游フォントでクオートがアレ」に近い気がしてきました。そう考えると，フォントによって可変幅かもしれないことは諦めるのも妥当に思えてきました。 JFM で U+00B7 を中点のタイプに含めたとして，この U+00B7 問題は解決しないと思います。現行の makejvf は「コードポイントをハードコードして，文字の左に“余白”がある想定の文字を MOVERIGHT -0.5 とかして左にずらす」ようです。U+00B7 も「全角幅の左に 0.25zw の“余白”」を想定するのでしょうから，これもまたハードコード対象に増やす必要があることになりそうです。（実際，上の方で私が書いた「句読点類が仮想ボディの中央にある VF」を作るには makejvf の改修が必要だった。）これもまたオプションスイッチ？ |
|
とりあえず先日書いた「makejvf の -c オプション」パッチを当ててビルドした makejvf の win32 バイナリの一時置き場。-c を付けないときは従来どおり動くつもりですが，バグっていたら知らせてください。（Unix の方はお手数ですがご自身で https://gist.github.com/aminophen/a1e367829363980c108bda29266eed0c を当ててビルドしてください。） |
|
さらに気づいたのですが，U+00B7 が含まれる Unicode ブロックは
ですよね。その状況で，果たして和文 VF に修正を加えたとして，どの程度役立つのでしょうか？ |
|
Latin-1 (ブロック名 "C1 Controls and Latin-1 Supplement") U+80 ~ U+FF にあり、かつ、 upTeX の場合は、両方を使いたければ、\kcatcode を文脈に応じて設定すれば使えます、というのが「売り」の仕様です。 記憶に頼りつつ、軽く調べつつ書いたので、不正確な点があるかもしれませんが、大筋は上記の通りです。 |
|
t-tk さん， 説明ありがとうございます。少しずつ状況が分かってきました。
なるほど。そういわれてみれば日本語でもよく見る「度」の記号〈°〉 (U+00B0) が入っていました。いわゆる約物ではないのですが，半角幅に収まるのだから JFM で詰めてもよいかもしれないです。 ＃ そういえば，〈°〉や〈℃〉は (u)pTeX の行頭禁則 (\prebreakpenalty > 0) に入っていないのですね。MS Word 等の行頭禁則には間違いなく含まれているので，(u)pTeX でも含めて問題なさそうな気もします。…が，少なくともこれは uptex-fonts のトピックではないですね。 |
|
\kcatcode を文書中で切り替えることで日中韓と欧を切り替えられる，というメリットを生かそうとすると，やっぱり日中韓用の VF が呼ばれる時を考慮して，U+00B7 のタイプを設定した方が良さそうですね。 やはり現行の makejvf ではそれが出来ない（write.c でコードポイント毎の水平シフト量計算がハードコードされているから）ので，また新機能を実装することになります。ただ，逐一オプションを追加すると収拾がつかないので，包括的にサポートできそうな以下のような仕様を考えています。
こうすれば，ほとんどはデフォルトに従って，シフト量を適宜調整した VF を作れるのでは，と思います。 |
|
|
「U+00B7の扱いについて方針」とは関係ありませんが、気になったので先に確認です：
私の認識では、①と②の違いは「行末での挙動」だけではなく「行の途中での挙動」もあると思っています。一般に、約物に設定される JFM グルーの伸縮量は、\kanjiskip による伸縮量よりも大きく設定されています。つまり「普通の漢字より約物の方が行長調節に大きな役割を果たす」といえますが、これは ﾅﾝﾄｶReq に規定されていない (u)pTeX の特徴だと思います。 |
実装してみました。パッチは以下です。（先日の「仮想ボディの中央に句読点があるフォント対応 -c オプション」にさらに追加する形。） win32 バイナリもビルドしてみました。20170707-makejvf-center-usertable.zip 設定ファイルの各行は で，コードポイントは UCS mode かそうでないかで（勝手に）解釈が切り替わります。シフト量の単位はそれぞれ zw, zh として小数値を書きます。U+00B7 に即すると と書いた file.txt を用意して とすれば目的の VF が得られるという想定です。未テストなので是非試していただけると助かります。（HGゴシックEとかだと，U+00B7 が全角幅でデザインされているのではないでしょうか。） |
|
makejvf の今後について、雑談です。 |
ご提案ありがとうございます。
齋藤さんのサイトはよく参考にさせていただきました。makejvf の調整の自由度は低いと私も思います。japanese-otf(-uptex) もそうですが，現在はアドホックに Omega の ovp2ovf を使っている状況ですよね。 とはいえ，新しいものを作るのは設計が難しいわけで，互換性を損なうわけでなければ makejvf の設定ファイルで十分なのでは，とも思います。その場合は
の方針がよいと思います。
これはそのまま同意します。 |
|
何はともあれ，makejvf がそもそも何をするツールなのか，は認識を統一したほうがいいでしょうね。 [1] アスキーの説明 (ptex-fonts/README_makejvf) によると「(株)アスキーで日本語化された dvips を使用する際に必要な VF を作成する」モノ。 [1] という目的から [2] という方法が素直に導けるかどうか，は考えてもしょうがないので，「makejvf はそういうもの」という前提で，以下のように考えてみました。 さて，仮に makejvf が [2] という方法をとるのであれば，期待する動作として「JFM から利用可能な最大の情報を取り出して，その JFM に見合った VF を自動で作って欲しい」と思うのが自然だと思います。同時に，makejvf が「複数のフォントの組み合わせ」や「個々の文字の調整」をサポートしないことも，いたって自然だと思います。 しかし，makejvf は実際には「横組か縦組か」と「文字の幅」という情報しか取り出していなくて，JFM の最大の特徴である GLUE/KERN テーブルは活用していません。仮に GLUE/KERN テーブルを読む仕組みが makejvf にあったならば，
という処理ができますから，
という問題は生じないはずなのです。この GLUE/KERN テーブルの読み出しがどれほど難しいのか，は考えてみても良いかも（難しくないのであれば，makejvf をそのように実装する）とは思っています。 |
|
ご参考になるかどうか分かりませんが、 |
|
（本題と無関係なところのツッコミですが）
異体字セレクタの利点はプレーンテキストでもグリフの区別が実現できることです。一方で、XeTeXやLuaTeXはマークアップ付のテキストでしかも既にOpenType属性の十分なサポートを持っています。従って、単一のフォントを使う場合でも、OpenType属性を使う方が自然な解決法だと思います。 % XeLaTeX文書; UTF-8
\documentclass[xelatex,ja=standard,a4paper]{bxjsarticle}
% Source Hanの日本語版を指定. それ以外は全く使っていないことに注意.
\setCJKmainfont[FontIndex = 0]{SourceHanSerif-Regular.ttc}
\setCJKsansfont[FontIndex = 0]{SourceHanSans-Bold.ttc}
\setmainfont{SourceSerifPro-Regular.otf}
\setsansfont{SourceSansPro-Bold.otf}
\newenvironment{CJKLang}[1]{\addCJKfontfeatures{Language = #1}}{}
\xeCJKDeclareCharClass{CJK}{`☃}
\begin{document}
\begin{CJKLang}{Japanese}% 日本語
{\TeX}と☃は\textgt{一切}関係ありません。
\end{CJKLang}
\begin{CJKLang}{Korean}% 韓国語
\xeCJKsetup{CJKspace = true}% 空白を保持する
{\TeX}과\ ☃은 \textgt{전혀} 관계 없습니다.
\end{CJKLang}
\begin{CJKLang}{Chinese Simplified}% 簡体字中国語
{\TeX}和☃\textgt{完全}没有关系。
\end{CJKLang}
\begin{CJKLang}{Chinese Traditional}% 繁体字中国語
{\TeX}和☃\textgt{完全}沒有關係。
\end{CJKLang}
\end{document}
|
To build these vf, makejvf version 20170716 (tl r44817) is required
|
uptex-fonts の Makefile において，makejvf の実行時オプションに -e を追加し，r44817 の makejvf version 20170716 で make してみると，生成する vf が完全にバイナリ一致しました。しかも，繁体中国語の新しい JFM / VF を作ることも全自動で可能になりました。 280fa10 でこれを足しておきました。 （もちろん，uptchc*.tfm から uptchc*.vf を作るときには のように警告が出ます。これは意図通りで，「繁体中国語の句読点類の仮想ボディ内での位置」が「makejvf/write.c で日本語用にハードコードされた句読点類の右シフト量」に合致しないからです。） U+00B7 を中点と同じ TYPE に追加するかどうか（日本語も？）は今から考えます。 |
|
簡体中国語について， CTeX-org/ctex-kit#292 で尋ねてみたところ，反応がきているようなので，ご興味のある方はそちらもご覧ください。 |
|
昔のことを思い出しました。 |
魅力的ですが，「何らかの集合」をどう定義するか，そして「その集合」をどう表現するか（← これがそのままユーザインタフェースになるはず），が自然にならなければ結局同じ問題が残るように思います。 さて，これとは別件で： CTeX-org/ctex-kit#292 で上がったのですが，ukinsoku.tex (uptex-base, uplatex) で U+00B7 (middle dot) に前禁則ペナルティを与えるべきではという指摘が来ました。 今のところ私は，以下のような副作用があるのでどうしよう，と答えています。 \documentclass{ujarticle}
\usepackage{lmodern}
\pagestyle{empty}
\AtBeginDvi{\special{pdf:mapline uprml-h UniJIS-UTF16-H :0:simsun.ttc}}
% \prebreakpenalty is applied to both CJK and non-CJK tokens
\prebreakpenalty"B7=10000\relax
\parindent0pt
\textwidth7zw
\begin{document}
% By default, U+00B7 is treated as non-CJK token
字字字字字字字\char"B7 abc\par % unexpected
% By using \kchar, U+00B7 is treated as CJK token
字字字字字字字\kchar"B7 abc\par
\end{document}この例で分かるとおり |
|
Latin-1ブロックの分割の素案です。
Unicodeでは script property が定義され Script.txtに記載されている。U+80 ~ U+FF の中は、Common のものと Latin のものが混在しており、これを upTeXの扱うBlockとしては Common と Latin の2個に分割する。
U+AA(ª), U+BA(º), U+C0..D6(À..Ö), U+D8..F6(Ø..ö), U+F8..FF(ø..ÿ)は "Latin",
今までと同じ。実装上は全角英数, 半角カタカナと同様、uptexdir/kanji.c で振り分ける。 レガシーエンコーディングでCJKだったもの(×÷やU+B7など)は Common の中に全て含まれるようです。 あまりよく分かっていませんが、\prebreakpenalty はグループごとに設定できませんでしたっけ? |
|
ů を使っている言語は、世界の特殊文字Wiki によると、
だそうです。 |
ありがとうございます。良い仕様だという印象を持っていますが，問題が起きないかどうか判断できるほど \kcatcode 周りに詳しくないので，ZR さんあたりにもできればご意見を伺いたいところです。
というのを見て，(u)pTeX で「\prebreakpenalty/\postbreakpenalty の挙動に \kcatcode が影響する場合がある」という話を思い出してしまい (ref. texjporg/tex-jp-build#13)，私もちょっと混乱しています。後ほどゆっくり読み直して考えます。
何があるのかなと疑問に思いつつ，世界の特殊文字Wiki という存在を忘れていてたどり着いていませんでした。混植が必要な場合はレアケースとみて良さそうですね。 さて 0xB7（CJK →
も同じ境遇ですね。それぞれ JIS X 0213 に定義された「始め二重山括弧引用記号/始めギュメ」，「終わり二重山括弧引用記号/終わりギュメ」ですが，現状は禁則ペナルティ設定がありません。「0x80--0xFF の範囲の文字は 8-bit Latin との兼ね合いで禁則ペナルティを設定していないので，必要に応じてユーザに設定してもらう」というのをドキュメントに書くだけで済ませようか，と考え始めました。 |
[ukinsoku.tex l.157] \postbreakpenalty`«=10000
\prebreakpenalty`»=10000 |
あれ，見落としていたみたいです。ということは，CJK トークンとしての扱いを優先していることになるので，一貫性のため 0xB7 にも \prebreakpenalty を与えるほうがよさそうですね。 |
|
正直言って、T1の 世界の特殊文字Wikiによると
T1以外に危険なものはあるのだろうか。ロシア語はもろにまずいかも。
そもそもkcatcodeの指定のdefaultがCJKトークン優先なので、整合性は取れていると思います(汗)。 |
|
考えてみたのですが、0xAB, 0xBB, 0xB7の禁則ペナルティのデフォルトは「設定なし」にしたいです。
例えば、「CKのブロックに入ったときに同時に 0xB7 の禁則ペナルティを設定」「JのU+AB, U+BBをCJK扱いするのは特殊なのでユーザーが個別に設定」という方が理解しやすく扱いやすいと思います。 |
|
0x80--0xFF の範囲の文字で，ukinsoku.tex の \prebreakpenalty / \postbreakpenalty が設定されているものが他にないか調べてみました。全て JIS X 0213 対応で追加されていたものです： \postbreakpenalty`«=10000 % U+00AB
\prebreakpenalty`»=10000 % U+00BB
\postbreakpenalty`¡=10000 % U+00A1
\postbreakpenalty`¿=10000 % U+00BF
\prebreakpenalty`·=10000 % U+00B7（今回追加）
\prebreakpenalty`ª=10000 % U+00AA
\prebreakpenalty`º=10000 % U+00BA
\prebreakpenalty`¹=10000 % U+00B9
\prebreakpenalty`²=10000 % U+00B2
\prebreakpenalty`³=10000 % U+00B3変更するのであればこれら全部一緒ですね。
の方がわかりやすい気もするのですが，今まで問題が起きていなかった（少なくとも報告されていない）ことを考えると，致命的な問題はなかったんじゃないかと思っています。 実際に問題が起きるのは |
|
繁体中国語について，現在の開発版は
としてありますが，ptex-fontmaps の現状が全て後者に該当していることから，前者は需要が低いと思われます。そこで，やっぱり「標準」として配るのは中央寄せのほうだけにしたいと思えてきました。 そのためファイル名を変えて，中央寄せのものを uptch* にしてしまって，左寄せのものをこの GitHub 上だけでオプション配布（たとえば uptcho* という名前）することを提案します。つまり
その方が，pxbabel とかの改修が不要になって都合が良さそうです。 |
|
私の意見もほぼ同じです。
|
需要があるかはよくわからなかったので、私としては主に互換性目的でした。特に異論がないようであれば、uptcho は用意しないことにします。 |
|
仮に
という需要があったとして、それは日本語か簡体中文用の設定を流用すれば十分な気がします。 そうすると、「ソレはどうやって（makejvfで）作るのか」の情報があるのが望ましいですが、それは現状でどこかに書いてあるんでしたっけ？ |
私としては，makejvf.1（つまり makejvf の英語版マニュアル）を新作して，こっそりですが少しずつ充実させているつもりでした。新しく作った -e オプションの説明は詳し目にしています。-t CNFfile の説明は今夜にでも書こうかと… |
upTeX の中国語・韓国語の JFM を改善したい，という Issue です。ptex-fontmaps で中韓フォントをサポートするようになったことで露呈してきた問題です。
現時点で作った tests/ 以下にあるテストケースを PDF にしたものが
にあります。 maps-pdf/adobe/test-tc-adobe-yoko-up.pdf を見ていて違和感を持って調べたことから，この issue を立てることにしました。現時点で発覚したのが，「句読点類と終わり括弧類が連続する場合，簡体中国語では字間を詰めるが，繁体中国語では詰めない」ということです。（なお，簡体中国語では句読点類が仮想ボディの左下に置きますが，繁体中国語では仮想ボディの中央に置くとも書かれていて，ほとんどのフォントはそのように実装されています。）
https://w3c.github.io/clreq/#compression_rules_for_consecutive_punctuation_marks
このように不自然な結果となります。このような問題点を抽出し，少しずつ修正していきたいです。
The text was updated successfully, but these errors were encountered: