Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

plext の挙動(揃え位置) #24

Closed
aminophen opened this issue Sep 13, 2016 · 14 comments
Closed

plext の挙動(揃え位置) #24

aminophen opened this issue Sep 13, 2016 · 14 comments

Comments

@aminophen
Copy link
Member

aminophen commented Sep 13, 2016

取り残していた texjporg/ptex-texmf#3 の議論も、こちらに移行することとします。

少し時間が出来たのであらためて読み返しているところなのですが、[t], [b] のときに「周囲のベースラインと合わせる」を仕様とする場合、ベースラインとは欧文ベースラインなのか和文ベースラインなのか、などが論点となっていたようです。


挙動を変えるとまずいのではないか、という話が何度も出てきたような気がしますが、とりあえず今 plext_test に置かれていたソースを私のところで fork して

ですべて PDF 化してみました。すると横組も縦組も、全部挙動が違います。4 つの PDF で「plext 非読み込み」(黒色で表示)同士を比べてみたり、「アスキー版 plext 読み込み」(赤色で表示)同士を比べてみても、少しずつベースラインや揃い位置がずれていて、同じにはなっていません。

アスキーが最後に pLaTeX2e を更新したのは 2006/11/10 ですし、plext.sty にいたっては 2001 年から不変ですので、この挙動の違いはすべて pTeX に由来するものです。

  • 2009 年の p3.1.11(アスキーがまとめた最後の pTeX)で、「\{y|t}baselineshift が数式にも反映されるように修正」が入った → 2008 と 2015 の差異
  • 2016 年 3 月の \{text|script|scriptscript}baselineshiftfactor の追加 → 2015 と 2016 の差異
  • 2016 年 9 月(つい先日)の \ifmbox の追加 → 2016 と 2017dev の差異

ここまで異なると、後方互換性がまったく保証できないと思います。むしろ「TL2017 までに“最善の新仕様”を確定させ、その後変更しない」というのがよいのではないか、と思いますが、いかがでしょう。

@aminophen aminophen changed the title plext の挙動 plext の挙動(揃え位置) Feb 4, 2017
@aminophen
Copy link
Member Author

aminophen commented Feb 9, 2017

改めて検討を始めました。まず、tabular と \parbox 命令の垂直位置からです。

  • 周囲の組方向が横組かつ組方向が <y>, <z> 指定の場合
    • [t] 指定のとき,一行目のベースラインが周囲のそれと一致(罫線の場合は和文ベースラインの位置)
    • [c] 指定のとき,表組の中心が周囲の数式軸を通る(欧文ベースラインシフトの影響下)
    • [b] 指定のとき,最終行のベースラインが周囲のそれと一致(罫線の場合は和文ベースラインの位置)
  • 周囲の組方向が横組かつ組方向が <t> 指定の場合
    • [t] 指定のとき,表組の上端が周囲の和文ベースラインと一致
    • [c] 指定のとき,表組の中心が周囲の数式軸を通る(欧文ベースラインシフトの影響下)
    • [b] 指定のとき,表組の下端が周囲の和文ベースラインと一致
  • 周囲の組方向が縦組かつ組方向が <y> 指定の場合
    • [t] 指定のとき,表組の上端が周囲の和文ベースラインと一致
    • [c] 指定のとき,表組の中心が周囲の数式軸を通る(欧文ベースラインシフトの影響下)
    • [b] 指定のとき,表組の下端が周囲の和文ベースラインと一致
  • 周囲の組方向が縦組かつ組方向が <t> 指定の場合
    • [t] 指定のとき,一行目のベースラインが周囲のそれと一致(罫線の場合は和文ベースラインの位置)
    • [c] 指定のとき,表組の中心が周囲の数式軸を通る(欧文ベースラインシフトの影響下)
    • [b] 指定のとき,最終行のベースラインが周囲のそれと一致(罫線の場合は和文ベースラインの位置)
  • 周囲の組方向が縦組かつ組方向が <z> 指定の場合
    • [t] 指定のとき,表組の上端が周囲の和文ベースラインと一致
    • [c] 指定のとき,表組の中心が周囲の数式軸を通る(欧文ベースラインシフトの影響下)
    • [b] 指定のとき,表組の下端が周囲の和文ベースラインと一致

という仕様を考えてみました。TeX Live 2017 に入る予定の (e-)pTeX 3.14159265-p3.7.1 で上記の仕様となるように実装したものが

です。ベースになっているのは #33\@Kanji 修正を施した plext.sty 2017/02/04 v1.2d で、揃え位置に関して修正を加えています。

別の揃え位置を採用する可能性も考えてみました。

(1) [t] および [b] のときに「周囲の和文ベースラインと一致」とあるものを「周囲の欧文ベースラインと一致」に変えたい場合。たとえば [t] の場合で例示すると

% \fork@array@option のほうの中身
     \def\@begin@alignbox{\lower\ybaselineshift\vtop\bgroup\kern\z@\vtop}%
     \let\@end@alignbox\egroup
% \fork@parbox@option のほうの中身
     \def\@begin@parbox{\lower\ybaselineshift\vtop\bgroup\kern\z@\vtop}%
     \let\@end@parbox\egroup

のようにすれば実現可能です。

(2) [c] のときに「中心が周囲の数式軸を通る(欧文ベースラインシフトの影響下)」とあるものを「中心が周囲の和文ベースラインと一致」に変えたい場合。たとえば

% \fork@array@option のほうの中身
     \def\@begin@alignbox{\setbox\z@=\vtop}%
     \def\@end@alignbox{%
         \@tempdima=-0.5\ht\z@
         \advance\@tempdima 0.5\dp\z@
         \raise\@tempdima\box\z@}%
% \fork@parbox@option のほうの中身
     \def\@begin@parbox{\setbox\z@=\vtop}%
     \def\@end@parbox{%
         \@tempdima=-0.5\ht\z@
         \advance\@tempdima 0.5\dp\z@
         \raise\@tempdima\box\z@}%

のようにすれば実現可能です。

@h-kitagawa
Copy link
Member

h-kitagawa commented Feb 9, 2017

ありがとうございます.個人的な意見を書きますと,

(1) [t] および [b] のときに「周囲の和文ベースラインと一致」とあるものを
「周囲の欧文ベースラインと一致」に変えたい場合

少なくとも横組クラスでは plext.sty は読み込まれない状況もあるので,その場合と結果が変わるのはまずいと思います.

周囲の組方向が縦組かつ組方向が <z> 指定の場合

縦組と縦数式ディレクションが絡んだ場合だけ,双方の和文文字の位置はずれてしまうので「欧文文字の位置が周りと合うようにする」とするのはどうでしょう?

@aminophen
Copy link
Member Author

(1) [t] および [b] のときに「周囲の和文ベースラインと一致」とあるものを
「周囲の欧文ベースラインと一致」に変えたい場合

少なくとも横組クラスでは plext.sty は読み込まれない状況もあるので,その場合と結果が変わるのはまずいと思います.

そうですね。縦組クラスの場合の可能性ということにします。なお「周囲の和文ベースラインと一致」という挙動は、picture 環境にもあてはまっているようです。

\documentclass{tarticle}
\begin{document}
あ\begin{picture}(30,20)
\put(0,0){\line(1,0){30}}
\put(0,0){\line(0,1){20}}
\end{picture}
\end{document}

周囲の組方向が縦組かつ組方向が <z> 指定の場合

縦組と縦数式ディレクションが絡んだ場合だけ,双方の和文文字の位置はずれてしまうので「欧文文字の位置が周りと合うようにする」とするのはどうでしょう?

縦数式ディレクションの考慮が抜けてました。その方が自然になりそうです。

@aminophen
Copy link
Member Author

縦組と縦数式ディレクションが絡んだ場合だけ,双方の和文文字の位置はずれてしまうので「欧文文字の位置が周りと合うようにする」

これが思いのほか難しく、結局実装できていません。表組はもともといったん数式モードに入るという挙動で、さらに縦横両方のベースライン補正が効いてくるようなのですが、うまく調節できずにいます。どなたか直していただけると助かります…

@aminophen
Copy link
Member Author

aminophen commented Mar 15, 2017

https://github.com/aminophen/plext_test に、TeX Live 2017 に入る予定の (e-)pTeX 3.14159265-p3.7.1 を使って make したテストケースを集めてみました。

  • plext-ascii.sty 2017/03/02 v1.2e (← これが現在の platex リポジトリの master。\fork…option についてはアスキー版のマクロを完全に維持している)
  • plext-beta.sty 2017/03/02 v1.2e-a01 (← これが本 Issue で検討中の揃え位置の新挙動)

この 2 つが比較できる PDF も置いてあります(北川さんのテストケースをリビルドしただけですが)。見やすいように便宜的に test-tate-20170315.pdftest-yoko-20170315.pdf に PDF だけ置いています。

挙動としては和文ベースラインを基準にしたこのコメントどおりなのですが、個別に見てみると一部不自然に見える気がしてきました。赤で示されているアスキー版と青で示されている開発版のうち、変更せずアスキーのまま(赤)のほうがよいと思うモノが一つでもあれば指摘していただけるとありがたいです。(因みに縦数式ディレクションはまだ考えがまとまっていない…)

@aminophen
Copy link
Member Author

aminophen commented Mar 28, 2017

予定のリリース日が 10 日後に迫ってきましたので 18edb85 にて tabular, array, \parbox の <t> および <y> について修正しました。<z> についてはまだ迷っているのでコミットしていません。

今迷っている部分:

  • 周囲が縦のときの tabular/array の <z> → どこに揃えるか?
  • 周囲が縦のときの \parbox<y> → (一旦変えてはみたが)アスキー版のままでも良いかも?
  • 周囲が縦のときの \parbox<z> → どこに揃えるか?

@aminophen
Copy link
Member Author

aminophen commented Apr 1, 2017

周囲が縦のときの \parbox<y> → (一旦変えてはみたが)アスキー版のままでも良いかも?

この [t] および [b] は悩んでいます。

\documentclass{tarticle}
\usepackage{otf}
\begin{document}
あ\parbox<y>[b]{5zw}{あいうえお}あ
\end{document}

としたときに、アスキー版では 3 つの「あ」が縦にまっすぐ並びます(厳密には pLaTeX の JFM では微妙にずれますが、otf パッケージ使用時や upLaTeX の標準では綺麗に揃う)。一方、開発版では「ボックスの端をベースラインにそろえる」ため、真ん中の「あ」が半分だけずれます。

アスキー版に多発していた「\cdp だけ上下にずらす」という処理から推測するに、アスキーは「\parbox で縦横用和文文字の位置を揃える」ことを意図したのだろうと思います。

forum:1355 で北川さんが指摘していらっしゃるのは、この「ずらす」処理を誤って tabular の方にも入れたために、かえって揃え位置が不自然になってしまった事例だと思います。

「ボックスの(上・下)端を周囲の和文文字の端に合わせる」というアスキー版の \parbox<y> は「不自然」とまではいえないと思います。一方で

  • ほかの揃え位置が「ベースラインを~に合わせる」であることから考えると統一感が無い?
  • 周囲が縦のときの \parbox<y> を和文文字の端基準にするなら、周囲が横のときの \parbox<t> も同様に和文文字の端基準にした方がよい → こちらは挙動変更するか?

という論点が生じます。

@h-kitagawa
Copy link
Member

h-kitagawa commented Apr 1, 2017

周囲が縦のときの \parbox<y> を幅基準とする

「周囲が横のときの \parbox<t>」の挙動変更も含めて,だんだん問題がないように思えてきました.

  • このように周囲と異なる組方向でボックスを組むのは plext 非読み込み時では想定していない
  • \rensuji の [l], [r] 指定時も「和文文字一文字分の幅」(\hbox to1zw{\yoko ...}) に対して左/右寄せになっている
  • 統一感については,「周囲の組方向と中の組方向が直交する場合」「しない場合」で挙動を統一させたと考えれば問題ない?
    (LuaTeX-ja では \dtou の場合も絡むので)
    ←縦数式ディレクション考慮すると,このような簡単な話じゃなさそうです.

@aminophen
Copy link
Member Author

週末に出す予定なのに commit の余裕がない状態です.すみません.

  • 直交な場合=「周囲が縦のときの \parbox<y>」および「周囲が横のときの \parbox<t>

→ ともに幅基準とする.つまり前者にとってはアスキー維持,後者にとっては挙動変更.

  • 縦数式ディレクションおよび <z> が絡む挙動

→ 議論が熟していないので,ひとまず 2017/04/08 という日付で出す pLaTeX/upLaTeX においては「未定義」としておきます(とりあえずコードの状態してはアスキー版のまま保留).pretest が終結するまでの間に決めましょう.

@aminophen
Copy link
Member Author

というわけで 1ffb88f で実装したつもりです.\parbox の揃え位置は

% \item 周囲の組方向が横組かつ組方向が|<t>|指定の場合
% \begin{itemize}
%   \item |[t]|指定のとき\\箱の上端が周囲の和文文字の高さと一致
%   \item |[c]|指定のとき\\箱の中心が周囲の数式軸を通る(欧文ベースラインシフトの影響下)
%   \item |[b]|指定のとき\\箱の下端が周囲の和文文字の深さと一致
% \end{itemize}
% \item 周囲の組方向が縦組かつ組方向が|<y>|指定の場合
% \begin{itemize}
%   \item |[t]|指定のとき\\箱の上端が周囲の和文文字の高さと一致
%   \item |[c]|指定のとき\\箱の中心が周囲の数式軸を通る(欧文ベースラインシフトの影響下)
%   \item |[b]|指定のとき\\箱の下端が周囲の和文文字の深さと一致
% \end{itemize}

ということになります.

\documentclass{jarticle}
\usepackage{plext}
\usepackage{otf}
\begin{document}

\vbox{\tate\adjustbaseline\parbox<y>[t]{5zw}{あいうえお}あ\parbox<y>[b]{5zw}{あいうえお}あ}
\vbox{\yoko\adjustbaseline\parbox<t>[t]{5zw}{あいうえお}あ\parbox<t>[b]{5zw}{あいうえお}あ}

\end{document}

これでテストになるでしょうか.

@aminophen
Copy link
Member Author

aminophen commented Apr 6, 2017

直交する場合について \parbox は変更しましたが,tabular/array はどうしましょうか.文字の幅より表の方が余分に広いため,周囲の高さ・深さに合わせても揃っている印象が薄い気がして,現在はまだ単なる \vtop や \vbox になっていますが…? → ベースライン補正分もずれてしまうので,変えなくていい気がしてきた。

@aminophen
Copy link
Member Author

aminophen commented May 3, 2017

縦数式ディレクションが絡む場合と,<z> の場合が「未定」になっているので何とかしたいです。しかし,数式ベースライン補正の仕様はコロコロ変わっているので,どうするのが初期のアスキーの意図なのかもよく分からなくなっています。

さて:「未定」になっている plext.sty の tabular/array の <z> について,ここに置いた 2017/05/02 v1.2f-a03 のコードを試してみると,周囲の欧文ベースラインと表の一行目・最終行の欧文ベースラインがそろっていそうに見えます…が,計算が合っているかどうかわかりません。どう思われますか?

@aminophen
Copy link
Member Author

「未定」のまま進まないのはよくないと思うので 36d4b57 でコミットしたもので「確定」したことにします。

@aminophen
Copy link
Member Author

Closed via release 2017-07-29.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants