eplatex

• Reporter: ttkttk
• Owner: h7k
• Type: Bugs
• Status: Closed
• Component: (None)
• MileStone: (None)
• Priority: 3
• Severity: 5 - Medium
• Resolution: Remind
• File: None

Details Reply

e-pTeX 090223 FAM256-PATCHED を試しています。

環境: VineLinux 4.2, i386
ptetex3-20080616 + upTeX-0.26 に追加インストール

こちらの環境では
eplatex を内部コード sjis にしたとき fmt の作成に失敗します。
FAM256-patch を外すと、全てOKです。

NG: (segmentation fault)
eptex -ini -etex -progname=platex -jobname=platex --kanji-internal=sjis platex.ini
eptex -ini -progname=platex -jobname=platex --kanji-internal=sjis platex.ini

OK:
ptex -ini -progname=platex -jobname=platex --kanji-internal=sjis platex.ini
ptex -ini -progname=platex -jobname=platex --kanji-internal=euc platex.ini
eptex -ini -etex -progname=platex -jobname=platex --kanji-internal=euc platex.ini
euptex -ini -etex -progname=platex -jobname=platex --kanji-internal=euc platex.ini
euptex -ini -progname=platex -jobname=platex --kanji-internal=euc platex.ini (upTeXのpTeX互換内部EUCモード)
euptex -ini -etex -progname=platex -jobname=platex --kanji-internal=sjis platex.ini
euptex -ini -progname=platex -jobname=platex --kanji-internal=sjis platex.ini (upTeXのpTeX互換内部SJISモード)
euptex -ini -etex -progname=uplatex -jobname=euplatex uplatex.ini
euptex -ini -progname=uplatex -jobname=euplatex uplatex.ini

内部コードの領域を拡張するため、cs_token_flag を
upTeX : @"1FFFFFFF (過剰かも)
Omega : @"FFFFF
pTeX : @"FFFF
TeX : @"7FFF
としてあったと思います。

epTeX + FAM256 でも
同様に@"FFFFよりも拡張することが必要なような気がしています。
いかがでしょうか?

Ticket History (3/6 Histories)

2009-03-09 16:55 Updated by: h7k

Comment Reply

おっと，気づきませんでした．すみません．
とりあえず，Segfault だけに限ってみれば，e-pTeX 090309 では解決されていないでしょうか？

以下，こちらの思考過程です：

1. tl-bsd fanさんのコメントに刺激され，FreeBSD 7.1-RELEASE i386 をエミュレータ上で動かし，e-pTeX のコンパイルスクリプトを調整することにした．
2. ところが，option に FAM256 = 1 と書いて FAM256 有効バイナリをつくると，ご指摘のバグが（内部コード UTF8 ですが）発生する．
3. FAM256 バイナリのビルドの途中で，FAM256 パッチが無効のバイナリができるが，それでも同じ症状が再現．
4. スクリプトを見たところ，option に FAM256 = 1 と書いたときとそうでないときの1回めのビルドを比較すると，
texmfmem.h だけが異なる（FAM256 パッチが有効の時は Omega のメモリフォーマットを用いるように1回めのビルドの前に変更するようにしていた）．
5. memoryword の定義を見ると，
その中の struct u の定義が Omega 系列では quarterword*2,
TeX 系列では short*2 になっていた．
6. ところで，e-pTeX では quarterword は1バイトになっている．upTeX, e-upTeX では 2バイト．
7. max_quarterword を@"FFFF にして，quarterword を 2バイトにしてみたら，Segmentation Fault は発生しなくなった．
8. というわけで，e-pTeX 090309 では max_quarterword を@"FFFF にしてあります．

2009-03-09 17:27 Updated by: h7k

Comment Reply

ああ，失礼しました．2. において，内部コードは EUC の間違いです．

cs_token_flag は，tex.web (3.1415926) をみると @'7777=@"FFF になってました．
（きちんと見ていませんが）おそらく
・Omega で @"FFFFF なのは，各フォントが 65536 文字まで使えるため？
left_brace_token とかも全部256の倍数→65536の倍数となってる．
・ pTeX で @"FFFF なのは，区間 (@"1000,@"FFFF) のところで
漢字その他の 2 バイト文字を扱うため？
だと思います．

だから，個人的には，FAM256 では cs_token_flag を拡張する必要が薄いように思っています．

2009-03-09 20:29 Updated by: h7k

• Priority Update from 5 - Medium to 7
• Owner Update from (None) to h7k

2009-03-11 23:42 Updated by: ttkttk

Comment Reply

ご検討ありがとうございました。
max_quarterwordを@"FFFF にしたeptex-090309を試したところ、eplatex.fmtの生成に失敗する問題はこちらでも解消しました。
cs_token_flagの変更は不要だったかもしれません。
まだ完全に理解できていませんが、何か分かったらまた連絡します。

一点だけ理解していることを申しておきますと、
pTeXでは、@"8000～@"FFFFのうち漢字/かな/和文記号の内部コード(SJISモードならSJIS, EUCモードならEUC)のパターンに合致した場合のみ、処理を漢字/かな/和文記号に回します。
FAM256のトークンが和文と重なる心配がなければ、問題は起きないはずです。

2009-03-11 23:50 Updated by: h7k

• Resolution Update from None to Remind
• Priority Update from 7 to 3

2009-04-04 21:51 Updated by: h7k

• Status Update from Open to Closed
• Ticket Close date is changed to 2009-04-04 21:51