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: None Status: Open Resolution: None Priority: 5 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: 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 <general text> 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 <general text>, by <general text>, 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 <general text>. 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