Closed aminophen closed 5 years ago
昨日投稿したこの件ですが,改めて考えると (★1) を仕様とみなすのが良いかどうか微妙な気がしてきました。(★2) についてはこのとおり修正したいです。
コメントするのを忘れてしまいました.こちらでテストはしていませんが,この方向で良いと思います.>(★2)
コメントありがとうございます。既に TL2019 ソースは「バグ修正のみ」のフェーズに入っていますが,(★2) は細かい修正の一環ということにして,今夜コミットします。(★1) は保留で。
(★1) についてですが,和文フォントに対する \iffontchar
と \fontcharwd
等で引数の意味が ⟨character code⟩
なのか<character type>
なのかが異なるのは(理想としては)避けたいなあ,という感じがあります.(和文フォントに対する \iffontchar
が,is_char_kanji
と同じになってしまうのはしょうがないかな.)まあ今年度は保留で良いと思います.
文字タイプ t に対する結果(存在判定・寸法)を得たいのなら,指定する引数を <character code>
をかぶらない値,例えば 16777216 + t とか -(t+1) とかにする,にしたいです.
(★2) は r50703 でコミットしました。
(★1) は考え中ですが備忘録として。
和文フォントに対する
\iffontchar
と\fontcharwd
等で引数の意味が⟨character code⟩
なのか<character type>
なのかが異なるのは(理想としては)避けたいなあ
確かにこれは引っ掛かっています。
和文フォントに対する
\iffontchar
が,is_char_kanji
と同じになってしまうのはしょうがないかな.
ふと考えると,実は is_char_kanji
と同じことを (e-)pTeX のマクロで実装するのは難しい(仮にできたとしても,厳密さを求めると面倒)と思いました。「Bad character code のエラーを出すことなく,欧文か和文の内部コードとして有効かどうか判定する」という \if〜 は需要が見込めるかもしれません。むしろその方向で実装するのもアリかもしれません。
character type は別途プリミティブがあってもいいかも。どこだったか忘れましたが,「文字タイプ 0 の文字ノード」を常に安全に作るのは難しいという話が出ていた気もしますし,そういうのも含めて将来的に考えてもいいかも。
とりあえず fontchar_chartype ブランチ (https://github.com/texjporg/tex-jp-build/tree/fontchar_chartype) で,次のようにしてみました(TL2020 に間に合えばいいかな,程度の認識です.2019-04-05 以降でないといろいろ対応ができません).
\iffontchar
: 引数が非負のときは is_char_kanji
,負数 c のときは文字タイプ -(c + 1) の存在判定\fontchar??
: 引数が負数 c のときは文字タイプ -(c + 1) の存在判定実は is_char_kanji と同じことを (e-)pTeX のマクロで実装するのは難しい
ソースのコミットメッセージにも書きましたが,(e-)upTeX(の内部コードが Unicode の状態)では is_char_kanji
が非負か否かの判定になっています.
どこだったか忘れましたが,「文字タイプ 0 の文字ノード」を常に安全に作るのは難しい
確か \adjustbaseline
の基準 (platex/#48) だったような.
r51624 で
\iffontchar: 引数が非負のときは is_char_kanji,負数 c のときは文字タイプ -(c + 1) の存在判定 \fontchar??: 引数が負数 c のときは文字タイプ -(c + 1) の存在判定
をコミット。
texjporg/ptex-manual#3 の (★1) (★2) に対する修正です。
1efab15 が (★1) に関する
を仕様とみなし,
の数値のチェックで厳密に 0--255 しか受け付けないようにするものです。
ac9f777 が (★2) に関して
を「256」ではなく「和文文字コードとして有効かどうか」に変えるものです。