Closed h-kitagawa closed 6 years ago
af4035781377972774c8a72e54ac24105cc7ca57 で部分的に対応しました.
実は今の実装にはもう1つ大きな問題があります。それは、
\begingroup
などを使っているため、完全展開可能であるべき場合にそうならず、
結果的にカーニング・リガチャが阻害される
というものです。
例えば、T1エンコーディングにおいては、\'e
は ^^e9
(文字トークン)に
完全展開される必要があります。
\documentclass{article}
\DeclareTextCommand{\?}{OT1}{}
\DeclareTextComposite{\?}{OT1}{!}{`f}
\begin{document}
o\?!\?!ice %→リガチャになる
\message{o\?!\?!ice} %→「office」と表示
\end{document}
ちなみに自分は次のような戦略を立てていました。
\\ENC\x-y
が未定義 → \ENC\x{y}
(旧実装通り)\'e
はこのケースになる\アレbaselineshift
がゼロ → \\ENC\x-y
(旧実装通り) \\ENC\x-y
の意味が単一の文字トークンである → \\ENC\x-y
(完全展開可能を保持)\'e
はこのケースになる\アレbaselineshift
の対策をする。完全展開可能は不要。\xkanjiskip
が落ちても仕方が無い\r{A}
(=\AA
)はこのケースになる※場合分けは展開限定で実装する。
(直接関係しない話ですが)
コレってよく知られている性質なんですかね?
% plain pTeX
\ybaselineshift=2pt % ゼロでも同様の結果
あ{\accent19 e}あ % 両側に \xkanjiskip が入る
\par
あ\hbox{\accent19 e}あ % 右側だけ \xkanjiskip が入る
\bye
「\\ENC\x-y
の意味が単一の文字トークンである」の判定に自信がありませんが,e83377e59fac7c274bbbb7b8a505f6d47397c9e1 で似たような戦略を書いてみました.
(\アレbaselineshift
が 0 の場合はボックスを \unhbox
することで対応)
少なくとも私は知りませんでした.> あ\hbox{\accent19 e}あ
あとでパッチを書きます.
> あ\hbox{\accent19 e}あ
ほんとですね、知りませんでした。パッチありがとうございます。
本題の e83377e のほうもよさそうに見えます。この修正は早めに CTAN に出した方がよさそうですね。
「\アレbaselineshift
を効かせて出力する」の部分なんですが、
「数式中の明示hbox」の仕様を利用する、という手はないですかね。
ちゃんと検討していないのですが、チョット試した感じだと \xkanjiskip
が落ちないように見えます。
\documentclass{jsarticle}
\usepackage{plext}
\begin{document}
\newbox\CharBox
\def\MakeCharBox#1{\setbox\CharBox\hbox{%
\ybaselineshift=0pt \tbaselineshift=0pt #1}}
\def\UseCharBox{$\textbaselineshiftfactor=0 \box\CharBox$}
\ybaselineshift=5pt
あAあ\par
\MakeCharBox{\AA}あ\UseCharBox あ\par
\parbox<t>{6zw}{%
\ybaselineshift=15pt \tbaselineshift=15pt
あAあ\par
\MakeCharBox{\AA}あ\UseCharBox あ\par}
\parbox<t>{6zw}{%
\ybaselineshift=15pt \tbaselineshift=15pt
$\hbox{あAあ}$\par
$\MakeCharBox{\AA}\hbox{あ\UseCharBox あ}$\par}
\end{document}
この修正は早めに CTAN に出した方がよさそうですね。
らしいので、取りあえず早めにCTANに出しましょうか。 ただ、明らかに直した方がよさそうな箇所にコメント入れました。 > e83377e
e83377e のコメント部分は修正いただいたので、uplatex を platex と sync しておきました。それぞれ pLaTeX 2016/06/07 と pLaTeX 2016/06/07u01 になります。
「
\アレbaselineshift
を効かせて出力する」の部分なんですが、 「数式中の明示hbox」の仕様を利用する、という手はないですかね。
これおもしろい ;) Pull request 歓迎します。
「\アレbaselineshift を効かせて出力する」の部分なんですが、 「数式中の明示hbox」の仕様を利用する、という手はないですかね。
いいですね.中身の \xspcode
の値で前後に \null
を補ったりすれば,
\xspcode
が 3(前後とも許可)以外の場合に対応できそうですし.
それぞれ pLaTeX 2016/06/07 と pLaTeX 2016/06/07u01 になります。
どのタイミングで CTAN に出せばよいでしょうか? 一旦これで OK なのか,さらに直すのか.
では、日本時間の今日 (6/7) 中に CTAN へ出すことを目標にしましょう。間に合うならさらに直したものが better ですね。Markdown の Pull request #4 も merge したいです。
plfonts.dtx l.1688 は、要するに #2
でよさそうです。
\@secondoftwo#1{#2}%
もう一つ:今の実装だと \xkanjiskip が OT1 だと入るのに T1 だと入らないことに気づきました。どこか勘違いしているでしょうか?(追記:これは従来と同じ挙動ではありますね)
\RequirePackage[2016/06/07]{platexrelease}
\documentclass{jarticle}
\usepackage[T1]{fontenc} % これをコメントアウトすると OT1
\usepackage{lmodern}
\begin{document}
あ\`eあ
\end{document}
デフォルトだと 128--255 の \xspcode
は 0 となっており,前後の \xkanjiskip
の挿入が許可されていないからです.次のように 3 に設定するとちゃんと動くはず.
\RequirePackage[2016/06/07]{platexrelease}
\documentclass{jarticle}
\usepackage[T1]{fontenc} % これをコメントアウトすると OT1
\makeatletter
\@tempcnta="80
\loop\ifnum\@tempcnta<\@cclvi
\xspcode\@tempcnta=3
\advance\@tempcnta\@ne
\repeat
\usepackage{lmodern}
\begin{document}
あ\`eあ
\end{document}
デフォルトだと 128--255 の
\xspcode
は
理解しました。この範囲の禁則パラメータは jsclasses では最適化されていて、標準クラスは未定義(デフォルトのまま)だったのを思い出しました。pLaTeX に取りこんではならないのでしょうか?
禁則パラメータ
どうなんでしょう.少なくとも T1 エンコーディングの一覧表を見る限りでは良さそうに思うのですが…….
数式中の明示hbox
h-kitagawa@9f81b17b230c804267bd7de35a7cdabcf7643735 でやってみました.テストおねがいします.
(\lastnodechar
でなく,\ENC\x-y
の y の部分から \xspcode
を取得するのが本筋,とコミットしてから気づきました)
ふと思ったのですが,pTeX (, LuaTeX-ja も) でシフト = 0 の hbox とそれ以外の hbox で \xkanjiskip の挿入処理を変えているのはなぜなのでしょう?
禁則パラメータ
デフォルトで入っていないのは、
「10年前は8ビットフォントエンコーディングの使用が一般的でなかった」
からで、単にそのまま放置されたのでしょう。
だから自分は \xspcode=3
に変えてしまって構わないと思います。
※128~255の文字が何かはもちろんエンコーディングにより変わるわけですが、 よく使われるであろう、T1・LGR・T2Aを見比べる限りは、結局、 「全部3にする」が無難に思えます。
禁則パラメータ
「全部3にする」が無難に思えます。
ということであれば、ぜひ 128--255 の文字を \xspcode=3
にしましょう。pLaTeX だけでなく pTeX のほうにも入れると consistent にできますね。
pTeX (, LuaTeX-ja も) でシフト = 0 の hbox とそれ以外の hbox で \xkanjiskip の挿入処理を変えているのはなぜなのでしょう?
確かに、「和欧文のバランス調節目的でシフトすると xkanjiskip が入らなくなる」だと嬉しくないですよね。なんでなんでしょう?(全然理解できないですが、ptexskip.pdf の 1.2 節って関係あります?)
数式中の明示hbox
h-kitagawa@9f81b17 でやってみました.テストおねがいします.
いま試してみたところ、大丈夫そうでした。
禁則パラメータ
kinsoku.tex の \xspcode
の件は、次回にでも回そうと思います。とりあえずいまは従来のままにしておいて、新しく Issue #6 を立てます。この #5 のバグフィックスリリースを最優先します。
変えた後に問題が起きるのはいやですし…
取りあえず「絶対にコケない \pltx@isletter
」を実装してみました。
書式は \pltx@isletter{<test>}{<true>}{<false>}
(現状と同じ)で、以下の仕様を満たす。
<test>
を先頭完全展開した結果が単一の(カテゴリコード11または12の)欧文文字トークンであるかを判定する。
␣a{}
など。今回の目的には影響はない。<test>
を単独で実行した場合にエラーにならないことを仮定する。<true>
か <false>
の何れかに至る。)\def\pltx@mark{\pltx@mark@}
\let\pltx@scanstop\relax
\long\def\pltx@cond#1\fi{%
#1\expandafter\@firstoftwo\else\expandafter\@secondoftwo\fi}
\long\def\pltx@isletter#1{%
\expandafter\pltx@isletter@i\romannumeral-`0#1\pltx@scanstop}
\long\def\pltx@isletter@i#1\pltx@scanstop{%
\pltx@cond\ifx\pltx@mark#1\pltx@mark\fi{\@firstoftwo}%
{\pltx@isletter@ii\pltx@scanstop#1\pltx@scanstop{}#1\pltx@mark}}
\long\def\pltx@isletter@ii#1\pltx@scanstop#{%
\pltx@cond\ifx\pltx@mark#1\pltx@mark\fi%
{\pltx@isletter@iii}{\pltx@isletter@iv}}
\long\def\pltx@isletter@iii#1\pltx@mark{\@secondoftwo}
\long\def\pltx@isletter@iv#1#2#3\pltx@mark{%
\pltx@cond\ifx\pltx@mark#3\pltx@mark\fi{%
\pltx@cond{\ifnum0\ifcat A\noexpand#21\fi\ifcat=\noexpand#21\fi>\z@}\fi
{\@firstoftwo}{\@secondoftwo}%
}{\@secondoftwo}}
forum:1941 の件、結構やっかいそうです… 新しく pLaTeX に入れた \@text@composite
の引数の書式は ucsencs.def(や本家 LaTeX)の定義と inconsistent なのでエラーが出てしまいます。
Runaway argument?
\ifx \uc@throw \undefined \else \def \uc@got {225}\uc@throw \global \let \ETC.
! File ended while scanning use of \@text@composite.
<inserted text>
\par
この \@text@composite
のパラメタ書式が変わっているのって、ずっと疑問に思ってたんですけど・・・。
\def\@text@composite#1#2#3\@text@composite{...}
\@text@composite
は単なる区切りトークン。\def\@text@composite#1#2#3#{...}
...
では #3
は見ていない。\@text@composite \xxxx yy\@empty \@text@composite {\add@accent{NNN}{yy}}
のような形になる。#1
と #2
は同じ。結局、「変える必要は無い」ように見えるんですよね……。
でも必要が無かったらわざわざ変えないと思うので、 多分このパッチを書いた人は「変えるべき理由がある」と考えた、と推測するのですが、その理由が何だかわからない……。
ucsパッケージを読み込んだ場合は、
\@text@composite {\xxxx}{yy}{\@empty}\@text@composite{\add@accent...}
という形の呼び出しが起こるようです。
本来は{\@empty}
の部分が“捨てられて”ほしいのですが、
TL16のpLaTeXの定義だと、{\add@accent
の {
じゃなくて {\@empty
の {
を拾ってしまいます。
パッチ書いたのは私 (http://oku.edu.mie-u.ac.jp/tex/mod/forum/discuss.php?d=1851#p10875) ですが,\@text@composite
のパラメタ書式を変えた理由はよく覚えていません.間違った試行錯誤の結果だと思いますorz
LaTeX オリジナルから変えなくて(= pLaTeT での再定義を削除して)良いと思います.
LaTeX オリジナルから変えなくて(= pLaTeT での再定義を削除して)良いと思います.
了解です。
h-kitagawa のほうのブランチのコードをチェックしてみましたが、問題なさそうです。
\ENC\x-y
の y の部分から\xspcode
を取得する
この方法も魅力的ですが、\"\ae
とかはどうするの、という問題がありそうです。
h-kitagawa/master ブランチのコードから \@text@composite
の定義を削除したものを aminophen/master ブランチ (aminophen@32b8de1) に作ってみたところ、手元では ucs.sty も正しく動いているようです。platexrelease も込みでテストおねがいします。
aminophen@32b8de195a06addb0035bbb0cdf248bab8f9d98e を手元で試してみましたが,pLaTeX 上では platexrelease.sty, ucs.sty とも動いているようです.
upldefs.ltx を同等の内容で手動書き換えしてみましたが,upLaTeX 上で ucs.sty は動いている模様.upLaTeX 上の platexrelease は未検証です.
取りあえず「絶対にコケない
\pltx@isletter
」を実装してみました。
これは入れたほうがよいのでしょうか? いまのままでコケる例というのが全然わかっていなくてそのままにしているのですが。
upLaTeX 上の platexrelease は未検証です.
upLaTeX 上の platexrelease も大丈夫でした。(さきほどplatexrelease.dtx の version を上げ忘れたので aminophen@1962560 で上げなおしました)
ついでに #6 もやってしまおうかと思って考えているのですが、kinsoku.dtx を安直に platexrelease に乗せてしまうと upLaTeX がダメなことになる(pLaTeX と違って、upLaTeX の ukinsoku.tex は当初から 128--255 が \xspcode=3
になっていた)ので、これは例外的に emulate の対象から外そうと思います。
まあ \ifx\ucs\@undefined ... \fi
とか platexrelease.sty に書けば不可能ではないけれど…
いまのままでコケる例
\documentclass{article}
\DeclareTextCompositeCommand{\^}{OT1}{?}{{hoge}}
\def\hoge{hoge}
\DeclareTextCompositeCommand{\^}{OT1}{!}{\hoge}
\begin{document}
\^? / \^!
\end{document}
(こんな場合まで対応する必要があるかわかりませんが)
aminophen@1962560337d093e4e01a1f2d566554ff0b77a794 では \DeclareTextCompositeCommand{\"}{OT1}{圏}{テン}
のように和文に対してアクセントの合成方法を定義した場合に,\"圏
全体が欧文文字のように扱われてベースラインや \xkanjiskip
の入り方がおかしくなります.
一応テストソースを.
%#!ptex2pdf -l a.tex
\documentclass{jarticle}
%\DeclareTextComposite{\"}{OT1}{圏}{`点}% invalid
\DeclareTextCompositeCommand{\"}{OT1}{圏}{テン}
\def\test{あ\AA あ\'eあ\'圏い\"圏うa\"圏a\AA a}
\begin{document}
\xkanjiskip10pt
\ybaselineshift10pt
\test\par
\ybaselineshift0pt
\test
\end{document}
\DeclareTextCompositeCommand{\"}{OT1}{圏}{テン}
h-kitagawa@b1781d1cca304bf134c7f68d97ff058e3884bd9c で対応したつもりです.
今まで出たテストケース(\xkanjiskip、カーニング・リガチャ、ucs.sty、コケる例、和文アクセント)は h-kitagawa@c785814 で通っているっぽいです。確認間違いや抜けがあったらすみません。
h-kitagawa さんのブランチを texjporg に merge してリリース準備に移ろうと思います。併せて #6 も大丈夫だと思いますので、kinsoku ブランチの \xspcode=3
も merge します。platex -> uplatex の sync も行いますので、日付は pLaTeX2e <2016/06/10>
と pLaTeX2e <2016/06/10u01>
とするつもりです。
皆様,ありがとうございます.
ひとまず platex / uplatex を作業しました。ミスってないか確認していただけると助かります。
それと、#6 をマージしてから気づいたのですが:kinsoku.tex に \@tempcnta
を使ったのが良くなかったと判断し、使わずに素直に書き直しました (259efd9) 。
(uplatex の方の話ですが)バージョン番号の u01 というのは
upLaTeX で動かない「pLaTeX 2.09 互換モード」に入るのを抑制したという些細なことです。勝手に入れてすみませんでした(68f6f69 に紛れたような格好で入っています)。
tests ディレクトリ
除外して良いです.リポジトリにテストファイルがあると便利,というだけなので.
もう少し書いておくと、p と up のバージョンについては私は以下の規則を考えています:
現在 uplatex.dtx と uplvers.dtx だけが、t-tk さんの「u00 パッチ」より進んでいるので「u01」を付けています。もし今後 pナントカ.dtx と独立に upナントカ.dtx を更新することがあれば「u02」とする、といった具合です。
数式中の明示hbox
もしや……と思い実験したところ,やはり \mathsurround
が 0 pt でない場合を
考慮していませんでした.1時間以内に直します.
\mathsurround
、そんなのありましたね… ぜひ merge してください。
\mathsurround
merge ありがとうございます。uplatex にも commit しました。あとはリリースお願いします。
あとはリリースお願いします。
platex, uplatex の 2016-06-10 を CTAN にアップロードしました.
ptex-base の kinsoku も上げますか?
ptex-base の kinsoku
merge して上げていただけると助かります。ありがとうございます。
「MacTeX2016インストール後,TeX Live Utilityでアップデートすると コンパイルエラーが発生」http://oku.edu.mie-u.ac.jp/tex/mod/forum/discuss.php?d=1951 ですが,
\\OT1\'-i ->\@tabacckludge '\i
を先頭完全展開するともう一回 \@text@composite
が出てくるのが原因のような気がします.
とりあえず,4a1013af447d813e80037cc02bf64f797931c0b1 で
\romannumeral
トリックを外したところ,動いているようです.
#あちゃあ
先頭完全展開としている際に、先頭に if-トークンが現れてそれを展開してしまうと、
後ろに不均衡な \else
や \fi
が残ってしまって、それがエラーを起こしているようです。
「不均衡な条件トークン」自体は何とかして処理できたとしても、
「if-トークンの展開により条件ネストレベルが増えている」ことの対処は難しそうです。
4a1013af447d813e80037cc02bf64f797931c0b1 で \romannumeral トリックを外した
とりあえず、これが妥当そうです。
修正がよさそうならリリースするのですが,バージョンはどうしましょうか.latex みたいに \ppatch@level を上げればよいのでしょうか.
早速 ZR さんが 「pLaTeX が新しくなってアレ」(http://d.hatena.ne.jp/zrbabbler/20160606/1465165011) で,Å だけでなく é, ê のような全てのアクセント合成を行っている文字について 周囲に \xkanjiskip が入らなくなる問題を指摘されています.
2つほどパッと思いつく方法を考えていますが,どちらも次のようにうまくいかず,悩んでいます.