Ni Nicolas, I think I agree.
If I export org files as HTML for use on my local system, I probably want 'real' links and file:/// is probably the right thing as I don't want to have to also install the files in a local web server. However, when I want to export files to HTML and have them served by a web server, file:/// is not the right thing. Perhaps we need a way to easily set a context for web exports. If the context is set, then use it, otherwise, use file:/// (actually, I thought this was already there, but it has been a while since I did html exports where links were necessary). Tim Nicolas Goaziou writes: > Hello, > > Carsten Dominik <domi...@uva.nl> writes: > >> I think it can be useful to write file: in the org-mode file, to make a >> clear distinction from internal links. But once it is clear that something >> is a link to a file, I guess you are right that it might not be needed in >> HTML. We will see what breaks..... > > Thinking about it, we should probably not remove the "file://" prefix. > > I cannot think of any situation where [[/absolute/path/to/file]] would > match something like "<img src="/absolute/path/to/file"/>", because "/" > never matches web root directory. > > IOW, to re-use the OP's example, [[/static/images/unicorn.jpg]] is never > a valid Org link, in the sense that it points to a non-existing file. > Since the OP is writing a link only valid during HTML export, he might > as well write raw HTML. > > Note that that "file:///static/images/unicorn.jpg" is not useful either, > but at least it is logical. > > The only situation where we might do something is during publishing, > when we know what web root directory – i.e., base directory – is. In > that case, we could replace absolute file names starting with web root > dir as root-relative URL. > > WDYT? > > Regards, -- Tim Cross
