texjporg / platex

pLaTeX community edition
BSD 3-Clause "New" or "Revised" License
49 stars 8 forks source link

標準フォントの仕様 #73

Open t-tk opened 6 years ago

t-tk commented 6 years ago

66 で話題に出ている件で、別の issue を立てたほうがよいと思い、こちらに立てました。

「pTeX, pLaTeX の標準が min10系になっているが、標準フォントとしては難点が多い」 という意見はよく聞きます。 「そうは言っても現状を維持すべきだ」という意見もあると思います。 現状維持の判断を継続するにしても状況を理解しておきたいので よろしければ議論にお付き合いください。

jsclasses + pLaTeX の縦組みのデフォルトは tmin10 になっているようですが、 jis-v にしなかった理由は何かあるのでしょうか? jis-v より tmin10 の方が好ましいのでしょうか?

jis-v と比較し otf パッケージ(japanese-otf)の縦組みは "!", "?" が type 6として扱われている点で相違があるようです。 この理由は何かあるのでしょうか?

upLaTeX では、jis-v.pl ベースに upjisr-v.pl を作成しそちらをデフォルトにしました。 "!", "?" は、japanese-otf-uptex で違いが出ているはずです。 どちらが好ましいか、定説はあるのでしょうか?

okumuralab commented 6 years ago

田中さま,

いろいろ話が進んでいるようですが,全然追いつけていなくて,申し訳ありません。

jsclassesはもともと縦組みをサポートしていなかったので,tmin10にしたのが自分かどうかも含め,まったく記憶にありません。jsclassesによる縦組みの例も見たことがないので,仕様変更されても困る人は多分いないと思います。

aminophen commented 6 years ago

https://texwiki.texjp.org/?jsclasses#i93cafcb に「jsclasses による縦組」という項目があり,その中には全体縦組と部分縦組の例がそれぞれ挙がっています。全体を縦組しているものは挙がっている例が upLaTeX なので,今回の tmin10 デフォルトは適用されていないと思います。部分縦組(plext 使用時)は tmin10 が使われているはずですが,変更されて困るとは思いません。

aminophen commented 6 years ago

ところで, @t-tk さんがご指摘のように,(u)tmin10 系が縦組で "!", "?" を type 6 として扱っている理由は,疑問符・感嘆符の後に全角空白を自動でグルーとして挿入するためです。jis-v 系にはこの規定がなく,逆に OTF パッケージの縦組系には同様の空白があります。どちらが好ましいか,は良く知りませんが,確かに小説などでは空白ありで組まれているのをよく見かけます。

t-tk commented 6 years ago

jsclassesはもともと縦組みをサポートしていなかった

ああ、そういう事でしたか。

jsclassesによる縦組みの例

縦組みのクラスがないので、あるとしたら、縦組みのボックスを作った場合のその中だけですね。 仕様変更は許されそうですね。

kmaed commented 6 years ago

疑問符・感嘆符のあとのアキについては,JLREQ にも記述があるようです. https://www.w3.org/TR/jlreq/ja/#positioning_of_dividing_punctuation_marks

一方で,

注3)文末ではなく,文中で区切り約物(cl-04)が付く場合がある.この場合は,区切り約物の前後をベタ組にするか,その前後を四分アキにする(図 3.18).

という記述もあります.

abenori commented 6 years ago

疑問符・感嘆符のあとのアキについては,JLREQ にも記述があるようです.

一方表6では空白なしだったり.(手動で?全角空白を入れろ,ということかなぁと思っています.)

kmaed commented 6 years ago

表6は「行の調整処理で空ける処理が可能な箇所」ですよね.文字間のアキについては附属書Bの表1ではないでしょうか.ただ,こちらにも全角アキについては特に記述がなくて,記述があるのは「附属書C 文字間での分割の可否」の方のようです.

kmaed commented 6 years ago

手動で?全角空白を入れろ,ということかなぁ

どこが文末なのかは自動判定できないと考えると,それも仕様としてはありえる気がします.英文で文末のピリオドか,省略のピリオドか,という話と似ているような.

abenori commented 6 years ago

文字間のアキについては附属書Bの表1ではないでしょうか.

そうでした.すみません.

zr-tex8r commented 6 years ago

確か『美文書』のどこかに
「文末の区切り符号の後には\hspace{1zw}を自分で入れろ」
みたいな説明が書いてあったのではないでしょうか。もしそうなら、部分縦組みの中でも同じ入力規則になるのが理想的である、と思います。

okumuralab commented 6 years ago

p.303ですね。otfでは \hspace{0.5zw} 相当が自動で入るがjisでは入らないので手で入れるしかないと書いています。

aminophen commented 6 years ago

変更の是非はさておき,

見たことがないので,仕様変更されても困る人は多分いない

の「見たことがない→困る人は多分いない→変えて良い」という論理は ok なのでしょうか?(私は何に於いても「変更が妥当と考えられるならば変えて良い」という意見で,「ある挙動がどのくらい使われているか」は測り知れないから二の次,と思っています。)

t-tk commented 6 years ago

どこが文末なのかは自動判定できないと考えると,それも仕様としてはありえる気がします.

OTF パッケージの縦組系で文中なので"?", "!"の後に全角アキを入れたくない場合は、グルーを消すように手動でマークアップを入れなければならない、ということなんですか。 jis-v とは考え方の違い、と理解しました。揃える必要があるのかどうか?

japanese-otf-uptex の縦組みで、区切り約物 cl-04 を同列に扱おうとするならば、以下の4グリフもtype 6 にすべきのようです。

CIDの対応はUniJIS-UTF16-{H,V}のもの U+203C ‼ CID:12111 全角 U+2047 ⁇ CID:16278 全角 U+2048 ⁈ CID:16279 全角 U+2049 ⁉ CID:12112 全角

t-tk commented 6 years ago

「見たことがない→困る人は多分いない→変えて良い」という論理は ok なのでしょうか?

私の発言ではありませんが、私が思うに、 新しく推進したい機能Aを入れようとすると別の観点で有用な機能Bが損なわれるケースはままあり、 機能Aと機能Bがトレードオフになってしまう場合があります。 「機能Bに相当するものが存在しなければ、機能Aを入れるのに障害が無い」 というロジックとして捉えました。

今回の文脈では 「jsclassesのボックスの中の縦組みのデフォルトのメトリックが好ましいと思って使っている人は多分いない」 ですね。

66 の @aminophen さんの↓の問いかけと似たような趣旨かもしれません。

[1] メトリック然り,[2] abstract インデント然り,『従来の挙動を好ましいと思っている人,特に再定義等せずそのまま使っている方』って,どれくらいいらっしゃるのでしょうか?

aminophen commented 6 years ago

新しく推進したい機能Aを入れようとすると別の観点で有用な機能Bが損なわれるケースはままあり、 機能Aと機能Bがトレードオフになってしまう場合があります。 「機能Bに相当するものが存在しなければ、機能Aを入れるのに障害が無い」 というロジックとして捉えました。

仮にこのとおりのロジックであれば,筋はいちおう通っていると思いますし,私もこれと同じ考え方です。個人的には,min10 系と jis 系を比較すると「横組に関しては jis 系の方が優れていると思うが,縦組は必ずしもそうではない」という意見です。既にでているとおり,「?!の後に自動で全角分のグルーが入る」という機能Bは,tmin10 にはあって jis-v にはありません。「jis 系の方がその他の文字の詰め具合は自然である」という機能Aを入れようとすると,この機能Bが失われてしまいます。

ところで,メトリックには(pLaTeX 用の既存のものに絞ると)「min10 系」「jis 系」「OTFパッケージ系」の他にも,「jlreq 系(jlreq.cls について来るもの)」或いは「newmin10 系」 http://akagi.ms.u-tokyo.ac.jp/tex_dvioutw.html#newmin があります。個人的には,min10 系と最も互換性が高く,かつメジャーな不具合が解消される「newmin10 系」を採用するのも一手ではないかと思っています。