#2068 Windows API Error 1113 with filenames with non-ascii-chars

closed
None
2014-08-20
2011-08-09
U_Fischer
No

Miktex 2.9 on win XP. The problem has also been reported from a win7 ultimate.

Test document (the document is ansinew encoded and the non-ascii chars are "u umlaut" and "a umlaut":

\documentclass{article}
\usepackage[ansinew]{inputenc}
\usepackage[T1]{fontenc}
\begin{document}
abc
% latex.exe: Windows API error 1113: F++r das Unicode
% -Zeichen ist kein zugeordnetes Zeichen in der Mehrbytecodepage vorhanden.
% Drücken Sie eine beliebige Taste . . .

\input{tüte}

%! LaTeX Error: File `täte.tex' not found.
%\input{täte}
\end{document}

The input with the u umlaut (\input{tüte} gives an api error, the other a file not found error. It doesn't matter if the files exist actually exist or not. The behaviour doesn't change if the document encoding is changed to utf8. Similar errors appears with other commands which reads files, e.g. \includegraphics. Which error appears obviously depend simply on the non-ascii char used.

On the mailing list someone claimed the problem is new and that such file names worked before (I have some doubts that it could work reliably as I can't imagine how pdftex should be able to convert such file names correctly without knowledge of the document encoding). But imho pdftex should at least capture this API error more gracefully.

Ulrike Fischer

Discussion

  • Christian Schenk

    It should actally work if the file contents is UTF-8 encoded... I will check this.

     
  • U_Fischer

    U_Fischer - 2011-08-09

    Damn. Sorry I forget that I got yesterday interupted before I could run the updates. So it could be that it works for utf8 now. I will check this afternoon. But I think with 8-bit-files you still get the API errors.

    Ulrike Fischer

     
  • U_Fischer

    U_Fischer - 2011-08-09

    I updated and recheck: The behaviour on winxp is unchanged.

     
  • Christian Schenk

    Thank you!

    Later MiKTeX versions use Unicode (UTF-8) to encode file names. Older versions (pre June/July 2011) use the current ANSI code page for file name encoding. IIRC, I switched
    from ANSI to Unicode in order to fix a fontconfig bug (the fontconfig cache is UTF-8
    encoded).

    I think your test case (\input{ANSI-encoded-umlaut-filename}) did never work
    on a japanese Windows system (where the current ANSI codepage certainly is not
    Latin1). And it did not work on modern Linux systems (UTF-8 encoded systems) either.

    This is a defect, i.e., I will address this issue in one way or the other.

     
  • Christian Schenk

    If the file contents is UTF-8 encoded and if you don't use inputenc with ansinew,
    then it works as expected:
    latex testutf8.tex
    creates testutf8.dvi

     
  • Christian Schenk

    UTF-8 encoded input file

     
  • U_Fischer

    U_Fischer - 2011-08-09

    I'm sure that a lot of variation of the theme never worked (I know to much about the working of inputenc and encoding problems to to dare to use such file names).

    As the bottom layer now uses utf8 it works if the file names in the document are encoded in utf8 and "transported" unchanged to the system commands. That means utf8-document compiled with luatex, xetex and (pdf)latex without inputenc works. If you load inputenc it breaks, if you use 8-bit encodings with pdflatex it breaks.

    But if you changed recently from ansi to utf8 this explains imho the raising number of complains about the windows 1113 error: In utf8 quite a lot byte sequences are illegal, An 8bit encoded "tüte.tex" is not an allowed utf8 code. (luatex would complain about
    ! String contains an invalid utf-8 sequence.
    l.11 t
    üte}

    So people get less "file not found" messages and more API errors.

    Ulrike Fischer

     
  • Anonymous - 2011-08-10

    The problem is also occurring if I try to run xelatex on an file with an non-ascii char in it, like "Büro.tex".

     
  • U_Fischer

    U_Fischer - 2011-08-10

    Running a file is different to trying to input it. When I try to compile a "büro.tex" I get a completly different error:

    I:\Z-Test>xelatex büro
    This is XeTeX, Version 3.1415926-2.3-0.9997.5 (MiKTeX 2.9)
    entering extended mode
    ! Undefined control sequence.
    <*> b^^♥^^³
    ro
    ? x
    No pages of output.

    I'm not sure if this is a miktex problem. It could be an error in the format. I will investigate a bit.

    Ulrike Fischer

     
  • Christian Schenk

    The bugs have been solved:

    Ansi-encoded file names are valid again
    xelatex büro works now

    The fix will be made available with the next MiKTeX update. A pretest is available here:

    http://downloads.miktex.org/temp/3388904.zip

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks