otf パッケージ使用時の line_length

[kmaed]

jlreq の問題というのか微妙なところですが，(u)platex で otf パッケージ利用時に，line_length=30zw と指定しても，1行に31文字入ってしまいます．

\documentclass[line_length=30zw]{jlreq}
\usepackage{otf}
%% \usepackage[textwidth=30zw]{geometry} % geometry で指定しても同じ
\begin{document}
\noindent
□□□□□□□□□■□□□□□□□□□■□□□□□□□□□■□□□□□□□□□■□□□□□□□□□■
\end{document}

\textwidth を見ると 300pt になっているようで，otf を読み込むと 1zw=9.6222pt になるのが反映されていないようです．

[munepi]

これは、jlreqが想定する仮想フォントの設計に従うとすれば、otfパッケージ側に然るべきscaleを与えて対応すべきだと思います。

%#!ptex2pdf -l
\documentclass[line_length=30zw]{jlreq}%%このとき、jlreqでは和文実サイズ10ptが想定されている。
\usepackage[scale=1]{otf}%%だから、ここのscaleは1にする必要がある。
%% \usepackage[textwidth=30zw]{geometry} % geometry で指定しても同じ
\begin{document}
\noindent
□□□□□□□□□■□□□□□□□□□■□□□□□□□□□■□□□□□□□□□■□□□□□□□□□■
\end{document}

jlreq 側で otf パッケージに対してあらかじめ \PassOptionsToPackage を想定するかどうかは、クラスファイルの設計開発者に委ねることになると思います。

個人的には、jlreqでは、otfパッケージもgeometryパッケージも読み込んだらエラーにして、利用禁止にしてしまうのも一つだと傍観しています。jlreqパッケージ自体が自身のクラスファイルに嬉しい自前の仮想フォントを持っていることと版面設計する機能を持っているので。やはり、二度手間かけてフォントも版面も設計すること自体が無駄だという考えです。

[kmaed]

otfパッケージ側に然るべきscaleを与えて対応すべきだと思います。

なるほど，ありがとうございます．

otfパッケージもgeometryパッケージも読み込んだらエラーにして、利用禁止にしてしまうのも一つだと傍観しています。

あまりotfパッケージの提供機能をちゃんと把握できていないのですが，利用禁止にして困るようなことはないのでしょうか．

[aminophen]

otfパッケージ側に然るべきscaleを与えて対応すべきだと思います。
jlreq 側で otf パッケージに対してあらかじめ \PassOptionsToPackage を想定するかどうかは、クラスファイルの設計開発者に委ねることになると思います。

最近 texjporg/jsclasses#63 で導入された \Cjascale は，まさに「クラスファイルが想定する和文スケール」なので，jlreq クラスが設定すべき値と思います。かつ otf パッケージはその値が定義済みならばそれを scale オプションの値として引き継ぐので，それがいいのでは。

[aminophen]

otfパッケージの提供機能

についてコメントしてみます。

• otfパッケージ付属のTFMを使用すると約物周りの組み方が変になる #15 によると，「OTF メトリックは JLReq と無関係なので厳密にはサポート外」になる。これに従うと，\usepackage[noreplace]{otf} はメトリックを変更しないので，サポート内に入ると思う。 → もしこの見解が正しいとすれば，エラーにする理由はない。
• OTF パッケージの「多書体化機能」は重要だと思う。これは \usepackage[deluxe]{otf} で有効になるが，noreplace とは共存できない／意味をなさない（“置換”ではなく“増設”のため）。 → 必然的に JLReq のサポート外になるが，そうすると「JLReq で多書体化するにはどうすればいいのか」という疑問が発生する。

[munepi]

@kmaed さん、すみません、 jlreq.cls を眺めていたら、 jafontscale や jafontsize などのオプションがありました ;-) 実際に該当コードを追うと、以下で問題ないことも確認できました。

いずれにしましても、現状、otfパッケージもgeometryパッケージも読み込んだり、jlreqクラスファイル側でもフォントや版面設計ができてしまう以上、挙動が分からずにパッケージに踊らされないようにするためには、最低限の版面設計の知識が必要だと思います。
（つまり、「なんとなく周りの余白だけを定める」というのだけは、避けるべきだと思います。）

%#!ptex2pdf -l
\documentclass[jafontscale=0.962216,line_length=30zw]{jlreq}
\usepackage{otf}%%scaleはデフォルト(ptex: 0.962216)
%% \usepackage[textwidth=30zw]{geometry} % geometry で指定しても同じ
\begin{document}
\noindent
□□□□□□□□□■□□□□□□□□□■□□□□□□□□□■□□□□□□□□□■□□□□□□□□□■
\end{document}

@aminophen さん、はい、 \Cjascale もその一つとして使えて、jlreqがotfパッケージをサポートするのであれば、 \Cjascale を使うのが楽な気がしています。

またまた、個人的には、jlreq 自身が otf パッケージ以上の多書体な仮想フォントを持てば、otfパッケージは基本的に不要だと傍観しています。例えば、明朝系、ゴシック系でそれぞれ大幅に増やすのも容易です。

[abenori]

@munepi さんありがとうございます．とりあえず原因と対策はそんな感じです．readmeのどっかに追記しておきましょうかね．

原則として，特定のパッケージへの対策や干渉は極力避けています．もしjlreq.clsの提供する機能被る機能を有するパッケージが後から読み込まれたら，そっちが優先されるようにしています．従って今回の挙動は「予定通り」です．なので

jlreqでは、otfパッケージもgeometryパッケージも読み込んだらエラーにして、

はしたくないです．まぁこれらのパッケージの機能（特にotf）はjlreq.clsでカバー仕切れているわけでもないですし．

\Cjascaleも同様で，やはり特定パッケージへの対処となるので気乗りしない……．

[abenori]

jlreq 自身が otf パッケージ以上の多書体な仮想フォントを持てば

@munepi さんによるjlreq-otfパッケージ爆誕の予感……！

[aminophen]

\Cjascaleも同様で，やはり特定パッケージへの対処となるので気乗りしない……．

texjporg/jsclasses#63 を良く読んでいただきたいですが，\Cjascale は 2018 年以降の pLaTeX / upLaTeX 系クラスファイルおよび LuaTeX-ja クラス / BXjscls で一斉に「規約化」される，日本語クラス全体の「新規約」として制定されつつあります。したがって，OTF パッケージ専用ではないつもりです。

（現行では \Cjascale を利用するのは OTF パッケージだけですが，今後仮に jlreq-otf が作られることがあるとすれば，そのパッケージが利用すべきは \Cjascale の筈です。）

[abenori]

そっちは既に読んでいます．