12 Jul
2005
12 Jul
'05
8:24 p.m.
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