Bugs item #377, was opened at 2005-07-02 21:43
You can respond by visiting: 
http://sarovar.org/tracker/?func=detail&atid=493&aid=377&group_id=106

Category: Image inclusion
>Group: v1.21a
>Status: Closed
>Resolution: Wont Fix
>Priority: 3
Submitted By: Georg Baum (baum)
Assigned to: Martin Schröder (oneiros)
Summary: unqoute image filenames not only on windows

Initial Comment:
The file 
pdftex-1.30.0-rc1/src/texk/web2c/pdftexdir/writeimg.c 
contains in the function readfile() a code block to 
unqoute file names which is inside #ifdef WIN32 ... 
#endif.
This code should be enabled on all platforms (or at
least on linux), since quoted filenames (which are
necessary if the name contains spaces) do not only work
well on linux.

Thanks,


Georg

----------------------------------------------------------------------

Comment By: Heiko Oberdiek (oberdiek)
Date: 2005-07-05 10:57

Message:
Logged In: YES 
user_id=1276

Hello,

> I manually copied and cited your message because I could 
> not find out how to do that correctly with the tracker 
> system :-( 

Also the tiny typein area and the order of postings is
very annoying. Perhaps we should better continue the
discussion on the ntg-pdftex mailing list.

>> Now you want the limitation of windows that quotes 
>> cannot be used apply on the other systems? 
> 
> I want to trade in the use of quotes for the use of
> spaces. 
> Since you can only have one (not really, see below) it is 
> from a user's point of view better to support spaces on
> all 
> platforms and not spaces on windows and quotes on other 
> platforms. 

>From a user's point it is better to support all
characters instead of randomly choosen ones.
The quoting method makes things worse:
* There is no method to detect, whether quoting is
  supported:
  \includegraphics{"abc def.png"}
  The graphics package does not know, whether the
  TeX compiler will look for {abc def.png},
  {"abc def.png"}, or {"abc}.
  Now you cannot use *both* quotes *and* spaces.
* A very long time, spaces are considered "fancy"
  in file names, it is asking for trouble, because
  they are not supported on DOS file systems.
  But nowadays, spaces become "normal" despite the
  trouble (also on windows systems).
  The difference in our problem descriptions seems
  to be that you want to have *spaces* as usable
  characters in filenames, my conclusion is that
  we must allow *any* character as usable. Otherwise
  we will have bug reports about quotes.
* And if we have a solution with *all* characters,
  there will be no problems with different encodings
  including ucs-2 or ucs-4.

Yours sincerely
  Heiko 

----------------------------------------------------------------------

Comment By: Georg Baum (baum)
Date: 2005-07-04 18:55

Message:
Logged In: YES 
user_id=2590

Hello, 
 
I manually copied and cited your message because I could 
not find out how to do that correctly with the tracker 
system :-( 
 
> I must disagree, "the same behaviour on all platforms" 
> can not mean to add the limitations of all platforms. 
 
No, that is not my intention. 
 
> Now you want the limitation of windows that quotes 
> cannot be used apply on the other systems? 
 
I want to trade in the use of quotes for the use of spaces. 
Since you can only have one (not really, see below) it is 
from a user's point of view better to support spaces on all 
platforms and not spaces on windows and quotes on other 
platforms. 
 
> There are operating systems that deal with 8+3 file 
> names only. Do you want to forbid long file names, 
> for example? 
 
Of course not. 
 
> Thus we are loosing both quotes and spaces. Spaces still 
> cannot be used in general. Other TeX engines 
> does not know about quoting. There is no secure way 
> to know, whether quoting is working. Thus code that 
> is intended for different systems must avoid spaces. 
 
And quotes (in the filename itself, not for quoting), so 
this is not really an argument to support them. 
Concerning other implementations: \includegraphics{foo.png} 
does not work with plain latex, but with pdflatex. The same 
would apply to spaces in filenames, so I see no big problem 
there. 
 
> And the current quoting scheme does not solve the 
> problem at all, it moves the problem from spaces to 
> quotes, spaces can still not be used and quotes are 
> now made unavailable. Also the quoting scheme does 
> not allow quoting of the quotes themselves. 
 
It does (although I am not sure whether that is intended): 
Only the first quote is stripped from two consecutive 
quotes, e.g. the string '"a""bc"' is transformed into 
'a"bc'. 
 
> A solution would allow *all* characters. 
> The solution should be able to deal with utf-8 or 
> even ucs-2/4 encoded file names. 
 
Agreed. If you think that the quoting is so bad then why 
not remove it altogether and tell users to use \pdfximage? 
 
My problem with the current implementation is the 
inconsistency: If filenames with spaces work on windows if 
quoted, I expect that they work on linux, too, since the OS 
supports them. Of course I can't expect the same from 
filenames with quotes: They are not supported by windows, 
so they can't be supported by pdftex on windows. 
 
I hope I have made my point clear. I can live with it if 
you still don't agree, so I'll stop arguing now. 
 
 
Georg 

----------------------------------------------------------------------

Comment By: Heiko Oberdiek (oberdiek)
Date: 2005-07-04 16:07

Message:
Logged In: YES 
user_id=1276

Hello,

I must disagree, "the same behaviour on all platforms"
can not mean to add the limitations of all platforms.
Now you want the limitation of windows that quotes
cannot be used apply on the other systems?
There are operating systems that deal with 8+3 file
names only. Do you want to forbid long file names,
for example?

Thus we are loosing both quotes and spaces. Spaces still
cannot be used in general. Other TeX engines
does not know about quoting. There is no secure way
to know, whether quoting is working. Thus code that
is intended for different systems must avoid spaces.
  And the current quoting scheme does not solve the
problem at all, it moves the problem from spaces to
quotes, spaces can still not be used and quotes are
now made unavailable. Also the quoting scheme does
not allow quoting of the quotes themselves.

A solution would allow *all* characters.
The solution should be able to deal with utf-8 or
even ucs-2/4 encoded file names.
  That is already given by the syntax of \pdfximage.
Thus new primitives \pdfinput, \pdfopenin, \pdfopenout
with  would allow any file name and a
macro code can test, whether this feature is available
by testing the command names.

Yours sincerely
  Heiko 

----------------------------------------------------------------------

Comment By: Georg Baum (baum)
Date: 2005-07-04 13:46

Message:
Logged In: YES 
user_id=2590

I agree that the quote stripping is a hack and should
eventually be replaced by something better.
I do think however that the behaviour on all platforms
should be the same if it is at all possible. Right now,
filenames with quotes work on linux and not on windows, and
quoted filenames with spaces work on windows but not on linux.
Thanks for the hint to pdfximage, I did not know about that
(coming from standard LaTeX and always using \includegraphics}

Georg

----------------------------------------------------------------------

Comment By: Heiko Oberdiek (oberdiek)
Date: 2005-07-04 13:13

Message:
Logged In: YES 
user_id=1276

Hello,

it is a very bad idea, quotes are perfectly legal
in linux and other operating systems. Also image
inclusion is done by \pdfximage that uses
, by , text surrounded
by curly braces (catcode 1 and 2) *all* possible
file names can be given including quotes and spaces.

We need rather new primitives for
\input, \openin, and \openout to provide the file
names as . The all file names can
be given without the need of quoting at all.
See also the discussion about \pdfinput in
the ntg-pdftex mailing list.

Yours sincerely
  Heiko 

----------------------------------------------------------------------

You can respond by visiting: 
http://sarovar.org/tracker/?func=detail&atid=493&aid=377&group_id=106