jfm由来のグルーの入り方がおかしい?

jfm由来のグルーの入り方がおかしい?

- 土 村 の投稿
返信数: 10
http://oku.edu.mie-u.ac.jp/~okumura/texfaq/qa/53287.htmlから始まる話題ですが、Q&Aでは見通しが悪いので、こちらに引越しさせていただきます。(最後のhttp://oku.edu.mie-u.ac.jp/~okumura/texfaq/qa/53294.htmlあたりからたどると読みやすいでしょうか。)

Vine 4.2 (i386, 32bit) の環境で確認しています。
OK ptetex3-20051003 (ptex-src-3.1.8.1)
OK ptetex3-20060506 (ptex-src-3.1.9)
OK ptetex3-20060615 (ptex-src-3.1.10-Beta2 + utf8.patch)
NG ptetex3-20061213 (ptex-src-3.1.10-Beta3 + libkanji-0.84)
NG ptetex3-20090610 (ptex-src-3.1.10 + ptexenc-0.999)

依然として私のチョンボである可能性が...2006年6月と12月の間に何をしたのか、引き続き調査中です。m(_|_)m

土 村 への返信

Re: jfm由来のグルーの入り方がおかしい?

- 土 村 の投稿
OK ptetex3-20060711 (ptex-src-3.1.10-Beta2)
NG ptetex3-20060713 (ptex-src-3.1.10-Beta2 + Beta2.patch)

ここまで追い込みました。libkanji/ptexenc とは関係ないようです。

で、問題の Beta2.patch ですが、Q&A43790 の「組版結果が環境依存?」という話題でバグ報告したものだったりします...(大汗;)

ptetex3 の古い物は間引いて公開していたのですが、この2つは公開しなおします。

土 村 への返信

Re: jfm由来のグルーの入り方がおかしい?

- 本田 知亮 の投稿
ご検討ありがとうございます.

この件は覚えています.
記事を読み返すと,
やっぱり
「数式の中に生で和文を入れる」
がかかわってますね.

んーー・・・当座の回避としては・・
業務システムの更新はそう
安易にはできないこともあって
$あ$みたいなのは避けて
$\mbox{あ}$
で進めたほうがよさそうですね.

それで,今回の問題への対処として,
この「rの初期化」を外してみると,今度は
その当時の問題が
復活するとかになるのでしょうか.
土 村 への返信

Re: jfm由来のグルーの入り方がおかしい?

- 匿 名 の投稿
角藤です。

私が入れたバグでした。今見直してみると、
理解しているわけではありませんが、土村さんの

r を rr で置き換える

のが正解のような気がしています。現象などから
考えて、あそこに r があるのはおかしいような気
がします。すぐ下で r を代入している部分も
rr で置き換えるべきのように感じます。

r はサブルーティン
@

でのみ用いる補助変数ではないかと思います。

想像で言っても始まりませんが ...
匿 名 への返信

Re: jfm由来のグルーの入り方がおかしい?

- 土 村 の投稿
私も理解できてなくてすいません。思い付きで言ってみたことが正しかったと言われても、ピンと来ません。どんなことをしても、たいてい改善に結び付いてしまってたので、何が本当に正しいのかがわかりにくいのだなぁ、というのが感想です。しかし、3年も前の修正が、今になって影響が出てくるなんて...

> それで,今回の問題への対処として,
> この「rの初期化」を外してみると,今度は
> その当時の問題が
> 復活するとかになるのでしょうか.

たぶんそうだと思いますが、試したわけではありません。

土 村 への返信

Re: jfm由来のグルーの入り方がおかしい?

- 匿 名 の投稿
間違っていないコードであれば r を初期化するか
しないかで、またどのような値で初期化するかで、
結果が変わるはずは無いので、本当のバグは
rr とすべきところを、誤って r としたところでしょう。
ここだけ訂正すれば
begin restart:@t@>@;@/
であるか
begin r:=min_halfword; restart:@t@>@;@/
であるかの違いは当然現れません。 --kakuto
匿 名 への返信

Re: jfm由来のグルーの入り方がおかしい?

- t tk の投稿
私も理解できている訳ではありませんが、

ptex-base.chを眺めていると、7630行目から
"@<Look ahead for glue or kerning@>" というところがあって、
問題の箇所"procedure make_ord"付近と似た処理が出てきます。
そこを見ると、
(インデントが削除されてしまって見にくくてすみません)

begin if op_byte(main_j)<kern_flag then
begin gp:=font_glue[main_f]; cur_r:=rem_byte(main_j);
if gp<>null then
begin while((type(gp)<>cur_r)and(link(gp)<>null)) do gp:=link(gp);
gq:=glue_ptr(gp);
end
else
begin gp:=get_node(small_node_size); font_glue[main_f]:=gp;
gq:=null;
end;
if gq=null then
begin type(gp):=cur_r; gq:=new_spec(zero_glue);
glue_ptr(gp):=gq;
main_k:=exten_base[main_f]+qi((qo(cur_r))*3);

となっています。
cur_rの型はptex.webを見ると、halfwordのようです。
それと同様であるとすると、3844行以下のmake_ordの方も以下のようになるべきのように思います。
procedure make_ord内では、rrはhalfwordと宣言されている(上記cur_rと同様)一方、rはpointerと宣言されいて合いません。

if op_byte(cur_i)<kern_flag then
begin gp:=font_glue[cur_f]; rr:=rem_byte(cur_i);
if gp<>null then begin
while((type(gp)<>rrr)and(link(gp)<>null)) do begin gp:=link(gp);
end;
gq:=glue_ptr(gp);
end
else begin gp:=get_node(small_node_size);
font_glue[cur_f]:=gp; gq:=null;
end;
if gq=null then
begin type(gp):=rrr; gq:=new_spec(zero_glue); glue_ptr(gp):=gq;
a:=exten_base[cur_f]+qi((qo(rr))*3);

試しに、ptex-3.1.10 + tetex3 (ptetex3なし) に上記の編集を施して、
rの初期化も消して試したところ、
本田さんのptexのサンプルはOKになりました。
t tk への返信

Re: jfm由来のグルーの入り方がおかしい?

- 匿 名 の投稿
uptex では (sjis,sjis) で

\font\xx=jis\xx
■;■

■■■
\bye

の場合、ptex と全く同じで、
■;■
■■■
の幅が同じになりますが、

(utf8,uptex) で

\font\xx=ujis\xx
■;■

■■■
\bye

の場合、
■;■
の幅が
■■■
の幅より広くなりました。
ujis.tfm は、そのように設計されて
いるのでしょうか?
匿 名 への返信

Re: jfm由来のグルーの入り方がおかしい?

- t tk の投稿
意図は、jis+(sjis,sjis)とujis+(utf8,uptex)で同一の幅になるつもりです。
提示していただいたサンプルで、ujis+(utf8,uptex)が広くなる現象は、私の手元で再現しませんでした。
しかし、
「2009年 06月 29日(月曜日) 00:09 - t tk の投稿」に書いたことは
同様だと思います。
そこを同様に直すと直るのではないか、と思います。

t tk への返信

Re: jfm由来のグルーの入り方がおかしい?

- 匿 名 の投稿
> そこを同様に直すと直るのではないか、と思います

あれは直してあるのですが...
u0.27 (W32TeX) のビルドがおそらく間違っていると
思います。調べてみます。 --kakuto
匿 名 への返信

Re: jfm由来のグルーの入り方がおかしい?

- 匿 名 の投稿
> 調べてみます

uptex-base.ch をオリジナルから再作成した
ものと、W32TeX で使用しているものを比べました
が、相違点がありませんでした。

そこで
updvipdfmx で pdf に変換してみると、正しく、
同じ幅になりました。

結論: dviout で見ていたので、間違った結論を
得ていました。おそらく、dviout の設定を
ちゃんとしていないのが原因です。
お騒がせしました。

ptexlive も変更されたようなので、W32TeX も
できるだけ早く変更します。
奥村さん指摘の、math baseline shift も変更
します。
ptexlive との振る舞いは一致すると思います。
--kakuto