Open aminophen opened 6 years ago
aminophen
commented
6 years ago いくつか補足です。
aminophen
commented
6 years ago 
t-tk
commented
6 years ago 少し私見を述べます。
という命題に、私は同意していません。 upTeX の例で言えば、 @zr-tex8r さんのLaTeX の「アレなデフォルト」 傾向と対策に指摘があった2点「upLaTeXでBMP外の字を使うとアレ」「upTeXの和文カテゴリコードがアレ」に関して 両方とも、公式のソース配布のドキュメントに記載してある内容でした。しかし最近の upTeX-1.23 で、ドキュメントの記述を変更し、デフォルト動作を変更することにしました。
perl ではスマートマッチ機能が一度公式化されたものの、その後実験的機能に格下げになった例を思い出します。
熟慮して慎重に決定した仕様をドキュメントに記載したところで、「利便性」「直感的」「安全性」「周囲の状況の変化」など様々な理由で、不評な動作は変更を迫られることもあるし、時の経過とともに過去の決定が適切で無くなる場合もあるということです。 ドキュメント化をすれば、不都合なデフォルト動作が免罪されるわけでもないですし、不便が消えるわけでも不評を鎮圧できるわけでもありません。 pTeXのような「枯れた」しかも普及しているソフトウェアの場合は、ドキュメント化されていなければ動作を変えていいというわけでも無いでしょう。
デフォルト動作を変えたい、もしくは変えるべき、ということならば、正面切ってそういう議論をしたらいいと思います。
aminophen
commented
6 years ago 立てたことを忘れていました…。 @t-tk さんのを読んで私が感じ取った一つの重要なポイントは
という感じでしょうか。確かにその観点は抜けていました。というわけで少し考えてみました。例えば，こんな考え方はどうでしょう？
ドキュメントは記録であって，何につけても大事なんじゃないかと思っています。
pTeXのような「枯れた」しかも普及しているソフトウェアの場合は、ドキュメント化されていなければ動作を変えていいというわけでも無いでしょう。
これもその通りです。慎重さは大事にしたい一方，「変えてはいけない」理由が「枯れていて，普及もしているから」，以上！ …で終わられてしまうと，なんだかスッキリしないのが私です。
正面切ってそういう議論を
はその通りで… ただ，現時点では「変えたい」という発議をしても，取り合って貰えない感じがしているのは私だけでしょうか？
t-tk
commented
6 years ago 取り留めのない雑談になりますが…
pTeX および関連ソフトについてざっと振り返ってみると、 ASCII社さんの公式のリリースの最終更新が2009年、公式Webの公開が2016年まで継続していました。 日本語TeX開発コミュニティーの発足は2015年6月でした。 振り返ってみるとupTeXの仕様を固めるのに2007年1月の開発開始から1年位かかっていました。
2007年頃の雰囲気は、ASCII社さんによるpTeX, pLaTeXの開発が収束に向かいつつある一方、 e-TeX拡張、XeTeX, LuaTeXなどは遠い世界でした。 そういう状況の中では、p{,La}TeXは、開発リソースの面でも将来性の面でも 世界から取り残されると知りつつも背伸びが出来ず、 「枯れていて，普及もしているから」変えない、という戦略には説得力があったように思います。
また、p{,La}TeXはASCII社さんが開発・公開してきたソフトなのだから、 2016年までは、動作を少しでも変更するような改変は、ASCII社さんに取り込んでもらうか、 さもなくば名前を変えて行うべし、という意見に説得力があったように思います。 (ptexenc拡張やe-TeX拡張のような方向性は別として。)
一方、最近の欧文LaTeXの激しい動きにpLaTeX, upLaTeXを追従させるべく 努力していただいている点はありがたく思っています。 up{,La}TeX は、間接的に p{,La}TeX を利用する立場なので、p{,La}TeX がきちんとメンテされることは有難いです。
2007年のupTeXの仕様決めの際にTeX掲示板でご意見を募り、pTeXのしがらみを断つ方が望ましい項目として 「標準フォントをmin10系ではなくjis系に、正方形が望ましい」と伺い、そう変えていったと 記憶しています。
焦点は、p{,La}TeXを取り巻く状況が変化する中、2018年の現在から将来を見据えてp{,La}TeXの仕様はどうあるべきか、ということになると思います。 p{,La}TeXの動作で不都合な点と言われるもののうち、p{,La}TeX以外に移行すれば済むものもあります。 拙作のupTeXだけでなくLuaTeX-jaなどのp{,La}TeX以外のソフトも実績を積んできており、 今あえてp{,La}TeXを使い続ける必然性や優位性は減りつつあるようにも思えます。
それでもあえて、「コミュニティー版としてp{,La}TeXの仕様の見直しをする」のは、 ありえなくは無いと思います。が、費用対効果とか力の入れどころの面で適切なのか、とも思います。 p{,La}TeXをピカピカに磨き直す価値は???
「変えたい」という発議をしても，取り合って貰えない感じ
消極的賛成、と消極的反対と、どちらでも構わない派と色々いらっしゃると思います。 私の場合は、ざっくり言うと 「ユーザーとしてはどちらでも構わない。開発者側としては必要な措置を講じれば変えてもいい」 といった感じです。
「(いつ)の議論で，(どういう理由)で(どういう挙動)が(維持または変更)された」というような記録
その有り難味はよく分かります。 ここの場やMLや掲示板のログなどでも、記録、備忘録の意味でも意識して書くようにしています。
t-tk
commented
6 years ago 冒頭に挙げられていた挙動と対策について、私がよく分かっていない点もありますが、方針を議論してみます。ドキュメント化は適宜することとして。
以下私見を言います。 ソフトウェアの挙動を良くするという点で、デフォルト動作の変更が好ましい方向であるならば、すれば良いと思います。 その際、互換性などの理由で従来の挙動が好ましいユーザーのために、簡便な方法で動作を巻き戻す手段(オプションとして旧デフォルトを得る手段)を提供することは要ると思います。
「[1] (案2) 寸法が同じでグルー設定が正常な jis 系に変更する」 「[1] (案3) 正方形なメトリックを新設して標準メトリックとする」のどちらでも良いと思います。 同時に、従来のメトリックの方が好ましいユーザーのために、minijsパッケージの逆、「jisminパッケージ」のようなものを提供すると良いと思います。 簡便に巻き戻す手段が提供できるなら、現状から隔たりが大きい(案3)でも良いと思います。
でも良いように思います。 @zr-tex8r さんの記事を見ると、インデントの量だけいじっても焼け石に水のように思えます。 (u)jclasses に出来て jsclasses に出来ないことは何かありますか?
aminophen
commented
6 years ago 簡便な方法で動作を巻き戻す手段
これは #70 に関連しますね。もし，「巻き戻す手段さえ用意すればデフォルトを変えて良くしてもよい」のであれば， #70 を実装するモチベーションにはなるかもしれません。
従来のメトリックの方が好ましい
に関連しますが，[1] メトリック然り，[2] abstract インデント然り，『従来の挙動を好ましいと思っている人，特に再定義等せずそのまま使っている方』って，どれくらいいらっしゃるのでしょうか？
インデントの量だけいじっても焼け石に水のように思えます。
(u)jclasses のおかしな点は，私もイマイチ把握できていなくて，すぐには出てきません。
＃ もし，今の状況が「把握したくても把握できない・把握するのが難しい」だとすれば，名前を変えた新しい“良い”ものを作りたいと思い立った方々にとって，極めて不幸な状態ですよね。
(u)jclasses に出来て jsclasses に出来ないことは何かありますか?
縦組クラスがない，が代表です。あとは，「jsclasses が“やり過ぎ”で好みが分かれる」という意見は見たことがあります（jsclasses に未だに open なまま残っている texjporg/jsclasses#62 も，細かい話ですがこれに該当すると思います）。比較的新しい jlreq.cls を使えばいい，という意見もありえて，何を標準・推奨とすべきかが一意に定まらない難しさがあります。（なので，標準・推奨を定めないのが無難そう。）
t-tk
commented
6 years ago 「巻き戻す手段さえ用意すればデフォルトを変えて良くしてもよい」
は理想的にはそう思っていますが、現実的には巻き戻す手段を実装する労力がつらい場合もあると思います。さらに、「巻き戻す手段のメンテナンスコスト」が将来にわたって重荷になるようだと悲しいです。 そういう意味で費用対効果は把握すべきであり #70 の場合は、少々頑張りすぎのように感じます。 また、巻き戻す手段の提供の仕方は色々あると思います。
[2] (u)jclasses の article 環境のインデント設定のようなケースでは、
「jarticle.clsの旧デフォルト設定は \setlength\parindent{1\Cwd} でした。変更前の挙動が好ましい場合は、それを追加してください」
で充分と思います。
あるいは「旧版の挙動が好ましい場合は、https://github.com/texjporg/platex/releases のものを使ってください」でも充分と思います。
何を標準・推奨とすべきかが一意に定まらない難しさがあります。（なので，標準・推奨を定めないのが無難そう。）
文書クラスの場合は、たとえ初心者でもいくつかの候補から選ぶ性質のものなので、標準・推奨を定めないのは腑に落ちます。 それならば (u)jclasses を jsarticle ほどピカピカにすることを頑張らなくてもよいと考えることもできます。
[1] pTeX, pLaTeX の標準メトリックのケースでは、 私の感覚では、前述のように「jisminパッケージ」のようなものを提供する」位が適当かと思います。
バイナリーで提供しているもの、依存関係がややこしいもの、大量のファイルが関連しているもの、動作を熟知していないとコントロールが難しいもの、などの場合は「旧版は過去のソースを使ってください」と言いづらいです。その場合は、巻き戻す手段をひとまとめにしたパッケージの類が有用と思います。 しかし、それも理想論で、労力はかかりますよね…
『従来の挙動を好ましいと思っている人，特に再定義等せずそのまま使っている方』
ケースとしては以下のようでしょうか。
default変更によるプラスの効果を期待するのは2aの層です。 マイナスの影響を受ける人は2bと3ですが、その層に対応策を提供できればよろしいかと。
t-tk
commented
6 years ago もう一つ論点がありました。
「jclasses は凍結」みたいな主張はナンセンスだと思っています。LaTeX カーネルも pLaTeX カーネルも pTeX エンジンも組版挙動が変化{する可能性がある,し続けている}状況の中で jclasses.dtx のソースコードだけ凍結することに意味はない
これには大いに賛成です。ただし、程度の問題はあると思います。 例えば、「min10を巻き戻す手段を頑張って用意したのにもかかわらず、(p)LaTeXカーネルの挙動の変化による差分の方が大きかった!!」のようなことならば、"min10を巻き戻す手段"が無意味になります。
旧仕様を好む一部のユーザーさんには手間になりますが「旧版は過去のソースを使ってください」を一律にお願いする、という方針もあり得ると思います。
例えば、下記はどうでしょうか。
t-tk
commented
6 years ago 標準フォントの件、 #73 に移動します。
ふと疑問に思ったのですが、 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 で違いが出ているはずです。 どちらが好ましいか、定説はあるのでしょうか?
pLaTeX / upLaTeX の「デフォルトの」挙動が良くない，という意見を時々見かけます。それらは「組版の互換性」などという名分で，今まで texjporg では触れてきませんでした。例えば
ちょっとが詰まりすぎる等）などです。これらについて，作者側・メンテナ側から「それは意図通りなので変えるつもりはありません」というように明言されたケースは（少なくとも私は）記憶にありません。
個人的な意見ですが，挙動と仕様は違うと思います。具体的には「作者・メンテナ自身が公式ドキュメントに書いていない挙動は，仕様ではない」，従って「変化しても文句は言えない」という考えです。
＃ 実際，dvipdfmx の PDF BoundingBox 選択律は，TeX Live 2017〜2018 の間に互換性がなくなりました。失われました。これもドキュメントがなかったことが一因ではと思います。
本当に変わってはいけないのであればそれは公式ドキュメントに書くべきで，そうしないと皆さん安心して使えないのだと思います。そこで，ドキュメント化を進めたいと思います。
さしあたり気になっているのは以下の2点です。
ひとまず私自身の「変えたい」「変えたくない」みたいな希望の主張は控えます。ドキュメント化を進めて安心して使える状態を作ることが主目的なので。
「jclasses は凍結」みたいな主張はナンセンスだと思っています。LaTeX カーネルも pLaTeX カーネルも pTeX エンジンも組版挙動が変化{する可能性がある,し続けている}状況の中で jclasses.dtx のソースコードだけ凍結することに意味はないと思うからです。