On Thu, 15 Jan 2009, Uwe Stöhr wrote:
I don't understand your concerns. I listed the 3 possibilities to fix
this and why I have chosen the one I implemented. There is not other way
to fix this, see also the last sentence of this mail. We also do this
all the time: When you enter a "#" in normal text, it becomes in the
background a "\#". The same is here, when you enter a "\" it becomes in
the background now a "%5C% - valid LaTeX.
Couldn't the following be an option. In case the users has tried to add a
character that's unwise, a dialog is shown. This dialog lists the unwise
characters as well as how they could be encoded (\ = %5C).
It should probably also tell the user that the text displayed in paper
does perhaps not be same as the actual encoded url used for link
generation? (I'm assuming this is possible, I don't remember at the
moment).
/home/juergen/test\test/somefile.pdf is valid on Unix. How am I supposed
to
enter such a path?
\href has nothing to do with paths of OSes. It follows the definitions of
URLs. So everything you can enter in this field is an URL, not a file path.
Strictly speaking and not sure if it matter, is it URLs or URIs?
Also, AFAIK there could be a significant difference in what's allowed for
file:... versus http:....
When you use the option that a URL is a path to a file it is still an URL and
therefore the resulting link will open the file via a URL browser and not the
usual file explorer.
(Just for my interest: is /home/juergen/test\test/somefile.pdf equivalent to
/home/juergen/test\test\somefile.pdf ?)
No. You can have a file named test\somefile.pdf, that resides in the
directory /home/juergen/test. For a URI, the \ should be encoded with %5C.
Also note that you could even have a file called test/somefile.pdf...
i.e. a file that'd be encoded as test%2Fsomefile.pdf (if it's %2F, I
think I wrote the value somewhere else).
I'm not sure it's sound to just transcribe all the '\' to '/' without
at least a warning. If for instance I'm pasting the name of a file,
the '\' in the actual path should be really be transcribed as %5C.
You are completely right. I made a mistake that I escaped the "%" character
in the URL field while it is allowed there. The attached patch fixes this and
I also now correctly translate "\" to "%5C" so that
D:\TEst\1.jpg
leads now to
\href{file:D:%TEst%5C1.jpg}{D:\textbackslash{}TEst\textbackslash{}1.jpg}
This can be handled by IE and Firefox. Interestingly they both translate the
"%5C" to "/". So in the end they do the same I did in my first patch and am
now wondering why I was not allowed to.
To be honest, I don't know if the above is always valid... What's
"D:\TEst\1.jpg" could theoretically be interpretid as:
The file D%xx%xxTEst%xx1.jpg
: \ \
or as
The file 1.jpg residing in the directory D/TEst.
I agree that on a Windows system the latter is way more likely, but it
doesn't have to be the case. Oh, and we should probably check if ':' is
one of the unwise characters.
Is it transcribed today?
As for how IE and Firefox interprets URIs, browsers do all kinds of things
it "thinks" the user want's it to do... Unfortunately we can't solely
rely on testing the URIs in browsers to see that they are valid, because
browsers do these automatic transcribings to be "helpful" and they don't
all do them the same way. So something that works in one browser doesn't
have to work in all.
Btw, I hope you tried it by clicking on a link in a PDF, because the
browser might treat a URI coming from that source differently compared to
something a user manually enters in the location bar.
Anyway, I think it'd be really good to show the user at least a warning
that certain characters have been automatically transcribed...
regards,
/Christian
--
Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
