Sorry to bother everyone again - this is a followup question to my earlier question:

Can openout handle a filename with spaces?

(I suppose I can combine this with the earlier question, but this seems to be a "gotcha" of the original question.) While I have a solution there, it breaks when using filenames with umlauts and when using either latin1/utf8 input encodings. The MWE gets an additional line (to break it):




The errors are different for each case. Since it works without the inputenc package, I'm very tempted to say, "just remove this line and see what happens."

I looked around and found the following question (which seemed most pertinant):

fontenc vs inputenc

The discussion there seems to say that inputenc will change the umlaut character to a tex macro. So ö becomes \"o etc.

My question is, does this expansion break the code that handles the asterisk/space replacement below? If so, then do I need to expand/replace the \scantokens macro with a loop that checks for this extra condition? yuck!


% "test öffnen.tex"
% Variations in run command to illustrate a more specific requirement ...
% Without {inputenc}
% Works: >h:\MikTeX\MikTeX.2.9p\texmf\miktex\bin\pdflatex "test öffnen.tex"
% Works: >h:\MikTeX\MikTeX.2.9p\texmf\miktex\bin\pdflatex "-job-name=test oeffnen" "test öffnen.tex"
% Works: >h:\MikTeX\MikTeX.2.9p\texmf\miktex\bin\pdflatex "-job-name=test öffnen" "test öffnen.tex"
% BROKEN with \usepackage[latin1]{inputenc}
% BROKEN with \usepackage[utf8]{inputenc}
%        >h:\MikTeX\MikTeX.2.9p\texmf\miktex\bin\pdflatex "-job-name=test öffnen" "test öffnen.tex"
% Same run-command as above, different package
%%% jobname=test*öffnen
%%% ! TeX capacity exceeded, sorry [input stack size=5000].
%%% \font@name ->
%%%              \T1/cmr/m/n/10 
%%% l.27 ...scantokens\expandafter{\JobnameX\noexpand}
%%%                                                   }
%%% If you really absolutely need more capacity,
%%% you can ask a wizard to enlarge me.
%%% produces error on console: pdflatex: Windows API error 1113: No mapping for the Unicode character exists in the target multi-byte code page.
% Convert jobname
\def*{ }
\catcode`\*=12 %
\newcommand{\TestFilename}{\JobnameX .ips}
%%% Write stuff to output - then read it back into a pdfobj
\typeout{Test writing stuff to output file=\TestFilename}
\immediate\write\MyFilehandle{Test writing stuff to output file=\TestFilename}
\immediate\pdfobj file {\TestFilename} %%% Just to show a snapshot of the entire process.
%%%   FYI - we embed papertray/bursting/external page requirement commands for postprocessing
%%%   (actually written as a 'pagepiece' dictionary)
%%% Write some text to create a pdf
Write some text into the pdf.

The error when using latin1 says I should expand TeXs stack. Which I guess I could do - only I'm not convinced that that is the problem. It seems more like a symptom.

  • Note that MiKTeX has recently been updated w.r.t. spaces in names: it no longer uses * chars but now uses the same quoting approach as TeX Live does. – Joseph Wright Mar 3 '15 at 18:21
  • Thanks for the "heads up" - I'll definately take a look at it. Do you have an idea what it's doing with umlauts in command line parameter strings? – infowanna Mar 3 '15 at 19:50
  • If you don't use inputenc you won't be able to use umlauts and accented chars in your document, you will have to write \"a instead of ä. If you use inputenc, you should use the option that tells the truth about the encoding of your document: Type an "ä" and then use the option where the output is correct. Imho you shouldn't use scantokens on the jobname. If you need to replace spaces better do a string replacement which doesn't change the other catcodes in the name. – Ulrike Fischer Mar 5 '15 at 10:21
  • @JosephWright - thanks - I finally got around to looking at the recent update to MikTeX. Oddly enough, if an umlaut is in the file Name I get the interesting output of (first few lines): This is pdfTeX, Version 3.1415926-2.5-1.40.14 (MiKTeX 2.9) (preloaded format=pdflatex 2015.7.30) 30 JUL 2015 17:14 entering extended mode *mweä*test.tex ("C:\ . . ._test_miktex29\20150728\stack_exchange\mwe ä test.tex" - There is a funny Symbol following the umlaut, (which gets capitalized) does the update handle latin chars in the file name? – infowanna Jul 31 '15 at 6:48
  • @JosephWright - which module(s) got updated? (and what are you referring to?) On further tests I've now noticed that pdflatex in the newer MikTeX behaves the same as the older version - blanks get replaced with asterisks. Were you referring to a different Version of pdflatex?(i.e. Version 3.0?) – infowanna Aug 4 '15 at 10:02

Your Answer


By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Browse other questions tagged or ask your own question.