printkanji_16bit におけるファイル名の扱い #125
Comments
|
とりあえず |
|
00b6c07 で直したつもりですが，どうでしょうか？（手元の TeX 環境は UTF-8 の Linux 環境しかないので……） UTF-8 の Linux 環境では，従来の pTeX でも と変な表示になっています． |
|
00b6c07 を試してみました。
また、.log の win32 では以下のパッチでよくなりました。 diff --git a/source/texk/ptexenc/ptexenc.c b/source/texk/ptexenc/ptexenc.c
index 695977bdf..1ddedc834 100644
--- a/source/texk/ptexenc/ptexenc.c
+++ b/source/texk/ptexenc/ptexenc.c
@@ -285,13 +285,13 @@ DEFINE_MULTISTRLEN(short,unsigned short);
int multistrlenfilename(unsigned short *s, int len, int pos)
{
s += pos; len -= pos;
- if (terminal_enc == ENC_UTF8) {
+ if (is_internalUPTEX()) {
int ret = UTF8Slengthshort(s, len);
if (ret < 0) return 1;
return ret;
}
if (len < 2) return 1;
- if (terminal_enc == ENC_SJIS) {
+ if (is_internalSJIS()) {
if (isSJISkanji1(s[0]) && isSJISkanji2(s[1])) return 2;
} else { /* EUC */
if (isEUCkanji1(s[0]) && isEUCkanji2(s[1])) return 2;
diff --git a/source/texk/web2c/ptexdir/ptex-base.ch b/source/texk/web2c/ptexdir/ptex-base.ch
index 9f88d61d6..ff1441dc0 100644
--- a/source/texk/web2c/ptexdir/ptex-base.ch
+++ b/source/texk/web2c/ptexdir/ptex-base.ch
@@ -385,9 +385,9 @@ else begin i:=str_start[s]; l:=str_start[s+1];
while i<l do begin
p:=multistrlenfilename(str_pool, l, i);
if p<>1 then
- begin for j:=i to i+p-1 do print_char(so(str_pool[j]));
+ begin for j:=i to i+p-1 do print_char(@"100+(so(str_pool[j]) mod 256));
i:=i+p; end
- else begin print(so(str_pool[i])); incr(i); end;
+ else begin print(so(str_pool[i]) mod 256); incr(i); end;
end;
end;
end;
@@ -401,10 +401,10 @@ begin if s<>0 then begin
while i<l do begin
p:=multistrlenshort(str_pool, l, i);
if p<>1 then begin
- for j:=i to i+p-1 do print_char(@"100+so(str_pool[j]));
+ for j:=i to i+p-1 do print_char(@"100+(so(str_pool[j]) mod 256));
i:=i+p; end
else begin
- if so(str_pool[i])<>"""" then print(so(str_pool[i]));
+ if so(str_pool[i])<>"""" then print(so(str_pool[i]) mod 256);
incr(i); end;
end;
end;
非 Windows かつ内部コードが upTeX 以外かつ端末が UTF-8 のときはファイルオープン時に内部コード⇔UTF-8 変換しているようなので、この場合はコード変換があったほうがよい気がします。
openclose.c の |
これで直りそう？ diff --git a/source/texk/web2c/lib/openclose.c b/source/texk/web2c/lib/openclose.c
index 63fa03935..20c3a47de 100644
--- a/source/texk/web2c/lib/openclose.c
+++ b/source/texk/web2c/lib/openclose.c
@@ -281,6 +281,13 @@ open_input (FILE **f_ptr, int filefmt, const_string fopen_mode)
must_exist);
if (fname) {
fullnameoffile = xstrdup(fname);
+#if defined(PTEX) && !defined(WIN32)
+ fname0 = ptenc_from_utf8_string_to_internal_enc(fullnameoffile);
+ if (fname0) {
+ free (fullnameoffile);
+ fullnameoffile = fname0;
+ }
+#endif
/* If we found the file in the current directory, don't leave
the `./' at the beginning of `nameoffile', since it looks
dumb when `tex foo' says `(./foo.tex ... )'. On the other |
|
ありがとうございます．とりあえずどちらも適用し，非 Windows で動くようにしました (627b5d6)．
ただ，
という処理を加えるよりかは，multistrlenfilename 側を Windows か否かで分ける（Windows なら multistrlenshort そのまま）としたほうが良いかもと思うようになってきました．この方針でも試してみます． |
|
#45 とも関連？ |
|
一通りコミットが終わって落ち着いたと思っていたのですが \input foo€€€.tex %
\byeこれを j1.tex として ptex (euc) で処理すると I can't find file のところに null 文字が入っていることに気づきました。 |
|
確認しました，後で調べます． |
|
ファイル名は和文欧文の区別をしないことから， |
|
とりあえずこうするとヌル文字にはならず，ac e2 というバイト列が直に出力されます．本当は WEB 経由でやりたい（TCX ファイルで --- a/source/texk/ptexenc/ptexenc.c
+++ b/source/texk/ptexenc/ptexenc.c
@@ -560,7 +560,10 @@ int putc2(int c, FILE *fp)
num[fd]++;
if (multistrlen(store[fd], num[fd], 0) == num[fd]) {
long i = fromBUFF(store[fd], num[fd], 0);
- ret = put_multibyte(toENC(i, output_enc), fp);
+ long nc = toENC(i, output_enc);
+ if (nc==0)
+ for (int j=0;j<=num[fd];j++) ret = putc(store[fd][j], fp);
+ else ret = put_multibyte(toENC(i, output_enc), fp);
num[fd] = -1;
} else if ((is_internalUPTEX() && num[fd] == 4) ||
(!is_internalUPTEX() && num[fd] == 2)) { /* error */ |
|
upTeX で内部コードが euc/sjis の場合の日本語ファイル名 #136 で確かめたように、本Issueで挙げられた問題は全て解決したと思います。ここは閉じます。 |
ややこしくなりそうなので，#81 の以下の h20y6m さんのコメントを新 issue に切り出しておきます．
printkanji_16bit を独自の win32 ビルドで試していいるのですが、日本語ファイル名で少しきになることがあります。
（独自ビルドのせいだったらすみません）
以下の内容のファイルと UTF-8 エンコードで
日本語.texとして保存します。\jobnameが欧文バイト列になっている^^形式になっているなお全ての場合で正しいファイルが読み書きされており使用上は問題なさそうです。
printkanji_16bit を含めない独自ビルドでは従来と同じになったので printkanji_16bit に起因するものだと思うのですが……
Originally posted by @h20y6m in #81 (comment)
The text was updated successfully, but these errors were encountered: