Re: [NTG-pdftex] [texhax] Passing Underscore
![](https://secure.gravatar.com/avatar/c1389d0584ea3ced1cff3450a93f7372.jpg?s=120&d=mm&r=g)
"John" == John R Culleton
writes:
Very interesting, although I usually rename all those (IMO silly) Windows type filenames with spaces in them.
I do so as well. It's more a GUI than a Windows problem.
Now what about two spaces in a row? Just curious.
I tried and it seems that there is a severe bug in pdftex. \input "foo bar" loads the file "foo bar.tex" which is certainly not desired behavior. I send this mail to the pdftex developers list as well. Maybe this problem had been fixed already, I'm using "This is pdfeTeXk, Version 3.141592-1.30.4-2.2 (Web2C 7.5.5)" Regards, and thanks for the hint, Reinhard -- ---------------------------------------------------------------------------- Reinhard Kotucha Phone: +49-511-4592165 Marschnerstr. 25 D-30167 Hannover mailto:reinhard.kotucha@web.de ---------------------------------------------------------------------------- Microsoft isn't the answer. Microsoft is the question, and the answer is NO. ----------------------------------------------------------------------------
![](https://secure.gravatar.com/avatar/39c2e81c07187f15629693891664005b.jpg?s=120&d=mm&r=g)
Reinhard Kotucha wrote:
"John" == John R Culleton
writes: Very interesting, although I usually rename all those (IMO silly) Windows type filenames with spaces in them.
I do so as well. It's more a GUI than a Windows problem.
Now what about two spaces in a row? Just curious.
I tried and it seems that there is a severe bug in pdftex.
\input "foo bar"
loads the file "foo bar.tex" which is certainly not desired behavior.
Well, it may not be "desired", but it's certainly consistent with TeX's underlying scanner/parser, which will have already elided multiple spaces into a single space before \input gets a chance to see things. If you change TeX's behaviour here, you really are getting away from TeX as a consistent platform, and in grave danger of creating a chimera, which I don't think is actually your intention or your desire ... ** Phil.
![](https://secure.gravatar.com/avatar/c1389d0584ea3ced1cff3450a93f7372.jpg?s=120&d=mm&r=g)
"Philip" == Philip TAYLOR
writes:
Well, it may not be "desired", but it's certainly consistent with TeX's underlying scanner/parser, which will have already elided multiple spaces into a single space before \input gets a chance to see things. If you change TeX's behaviour here, you really are getting away from TeX as a consistent platform, and in grave danger of creating a chimera, which I don't think is actually your intention or your desire ...
Nobody forces you to use double quotes. TeX still works as it did 20 years ago. Why do we need a TeX parser to process filenames? What is the advantage if files are inaccessible? Regards, Reinhard -- ---------------------------------------------------------------------------- Reinhard Kotucha Phone: +49-511-4592165 Marschnerstr. 25 D-30167 Hannover mailto:reinhard.kotucha@web.de ---------------------------------------------------------------------------- Microsoft isn't the answer. Microsoft is the question, and the answer is NO. ----------------------------------------------------------------------------
![](https://secure.gravatar.com/avatar/c4fb1aecd98bbaa9856f8c421db294e0.jpg?s=120&d=mm&r=g)
On Tue, Sep 19, 2006 at 11:18:31PM +0100, Philip TAYLOR wrote:
Reinhard Kotucha wrote:
>"John" == John R Culleton
writes: Very interesting, although I usually rename all those (IMO silly) Windows type filenames with spaces in them.
I do so as well. It's more a GUI than a Windows problem.
Now what about two spaces in a row? Just curious.
I tried and it seems that there is a severe bug in pdftex.
\input "foo bar"
loads the file "foo bar.tex" which is certainly not desired behavior.
Well, it may not be "desired", but it's certainly consistent with TeX's underlying scanner/parser, which will have already elided multiple spaces into a single space before \input gets a chance to see things. If you change TeX's behaviour here, you really are getting away from TeX as a consistent platform,
The syntax with quotes already excludes legal file names
on many file systems and operating systems, where quotes
are legal characters in file names. Therefore the quote extension
isn't a refinement of \input's syntax. It would be much better
to have separate primitives that uses <general text> for file
names as done in \pdfximage. Also it would be easy to test,
whether the new primitives are present. I don't know a
reliable way to test the supported syntax of \input.
Yours sincerely
Heiko
![](https://secure.gravatar.com/avatar/565476157eb3895a9c928ffce26d988d.jpg?s=120&d=mm&r=g)
Hi, Reinhard Kotucha wrote:
"John" == John R Culleton
writes: Very interesting, although I usually rename all those (IMO silly) Windows type filenames with spaces in them.
I do so as well. It's more a GUI than a Windows problem.
Now what about two spaces in a row? Just curious.
I tried and it seems that there is a severe bug in pdftex.
\input "foo bar"
It would be a severe bug if the documentation said this would work and it did not, but that is not the case. As it stands, this is a documented limitation: multiple consecutive spaces are always collapsed into one. There is no easy way to extend pdftex, because the token scanning routines do not know exactly when a filename is being read. Consider, for instance, \LaTeX's \include command, that accepts a filename as an argument, and could itself be part of a macro expansion. That said, pdftex *can* read files with multiple spaces in them, if you are able to intercept the tokenizer fast enough. either \catcode`\ =12\relax\input"foo bar"\catcode`\ =10\relax or {\catcode`\ =12\gdef\notaspace{ }} \input"a\notaspace\notaspace b" works fine. Cheers, Taco
![](https://secure.gravatar.com/avatar/c4fb1aecd98bbaa9856f8c421db294e0.jpg?s=120&d=mm&r=g)
On Wed, Sep 20, 2006 at 08:16:08AM +0200, Taco Hoekwater wrote:
That said, pdftex *can* read files with multiple spaces in them, if you are able to intercept the tokenizer fast enough.
either \catcode`\ =12\relax\input"foo bar"\catcode`\ =10\relax or {\catcode`\ =12\gdef\notaspace{ }} \input"a\notaspace\notaspace b" works fine.
or
\input "a \space b"
\pdfximage{a \space b.png}
Yours sincerely
Heiko
![](https://secure.gravatar.com/avatar/162f5e55e490806bd481ef2cc36749e7.jpg?s=120&d=mm&r=g)
On Sep 20, 2006, at 2:16 AM, Taco Hoekwater wrote:
It would be a severe bug if the documentation said this would work and it did not, but that is not the case. As it stands, this is a documented limitation: multiple consecutive spaces are always collapsed into one.
FWIW, I find the rules for handling filenames arcane enough that in a recent project[1], rather than try to sort out all of the special cases, I transferred all of the filenames into a spreadsheet (they had to be preserved) then duped them, then massaged the duped column so as to normalize it to something TeX could easily handle, used a utility (File Wrangler) to do the same to a duplicate set of the files, then wrapped everything up in a TeX macro which typeset the unmodified filename in a verbatim environment and used the modified filename to pull in the graphic and print it on the same page as the typeset filename at 90% of its original size. William [1] reprinting a ~7,000 pg. government handbook where all the pages were provided as single page .pdf files. -- William Adams senior graphic designer Fry Communications This email message and any files transmitted with it contain information which is confidential and intended only for the addressee(s). If you are not the intended recipient(s), any usage, dissemination, disclosure, or action taken in reliance on it is prohibited. The reliability of this method of communication cannot be guaranteed. Email can be intercepted, corrupted, delayed, incompletely transmitted, virus-laden, or otherwise affected during transmission. Reasonable steps have been taken to reduce the risk of viruses, but we cannot accept liability for damage sustained as a result of this message. If you have received this message in error, please immediately delete it and all copies of it and notify the sender.
participants (5)
-
Heiko Oberdiek
-
Philip TAYLOR
-
Reinhard Kotucha
-
Taco Hoekwater
-
William Adams