From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kaushal Modi Subject: Re: why prepend "file://" to abs paths in html output? Date: Mon, 10 Jul 2017 12:53:10 +0000 Message-ID: References: <87lgnz43qk.fsf@nicolasgoaziou.fr> <87h8yn3tsa.fsf@nicolasgoaziou.fr> <87bmou4u8a.fsf@nicolasgoaziou.fr> <874lumfqk7.fsf@gmail.com> <877ezh51ns.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a113f8e0c6639a70553f61112" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:35333) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dUYBq-0004Fd-5F for emacs-orgmode@gnu.org; Mon, 10 Jul 2017 08:53:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dUYBo-0000gr-Lo for emacs-orgmode@gnu.org; Mon, 10 Jul 2017 08:53:26 -0400 Received: from mail-lf0-x234.google.com ([2a00:1450:4010:c07::234]:35768) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dUYBo-0000fc-6t for emacs-orgmode@gnu.org; Mon, 10 Jul 2017 08:53:24 -0400 Received: by mail-lf0-x234.google.com with SMTP id b207so59617113lfg.2 for ; Mon, 10 Jul 2017 05:53:23 -0700 (PDT) In-Reply-To: <877ezh51ns.fsf@nicolasgoaziou.fr> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: Nicolas Goaziou , Tim Cross Cc: Carsten Dominik , emacs-org list --001a113f8e0c6639a70553f61112 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, On Sun, Jul 9, 2017, 6:45 AM Nicolas Goaziou wrote= : > > The following patch implements `org-html-root', which allows to export > file links as root-relative URL. Can you please attach the patch? I'm not sure the docstring is clear > enough, tho. > Also, HTML publishing process always bind the above to publishing > directory, without user intervention. > Matt and I are working on an exporter backend for Hugo, ox-hugo. We are exporting Org to a flavor of Markdown compatible with Hugo. The HTML exporter has some contribution in this exporter. If a link is "/foo/bar" in the Markdown file, Hugo assumes "foo" to be present in the "static/" dir in the site root. So the Markdown link auto expands to "example.org/static/foo/bar". But if the link was "/foo/bar" in the Org file to begin, with it would become "file:///foo/bar" in Markdown (as it is a derivation of ox-md). Though, we got around that by overriding the org-md-link function in ox-hugo. The complication arose when we needed to support "#+ATTR_HTML: :class something" above figure links. We then needed to let the html link exporter take up the link translation job instead of having ox-hugo do that directly (it is OK to have HTML snippets in Markdown). And thus this request. So, basically, upon exporting the following document to HTML: > > #+html_link_root: /tmp/ > [[/tmp/unicorn.jpg]] > > the link becomes > > 3D"unicorn.jpg" > Based on the example, that patch might work! =3D=3D=3D=3D=3D Reply to an earlier email: On Sat, Jul 8, 2017 at 3:14 PM Nicolas Goaziou wrote: > Hello, > > Carsten Dominik 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. > It depends.. if people are using Org files exported as HTML to open referenced files in their browser (though that would work only if they open those HTML pages only on that machine). But at least in one browser (Firefox), I noticed that the browser auto-added the "file://" prefix if user tried to access "/static/images/unicorn.jpg" directly from the address bar. I cannot think of any situation where [[/absolute/path/to/file]] would > match something like "", because "/" > never matches web root directory. > As mentioned above, one example is Hugo, which auto-interprets the presence of absolute links in the Markdown files (whether they are of Markdown or HTML style). Note that that "file:///static/images/unicorn.jpg" is not useful either, > but at least it is logical. > I can see the benefit if a browser does not support auto-detection of local links. But if the patch works, all should be good :) The only situation where we might do something is during publishing, > when we know what web root directory =E2=80=93 i.e., base directory =E2= =80=93 is. In > that case, we could replace absolute file names starting with web root > dir as root-relative URL. > In our case, we are delegating that step to Hugo. So Org does the job of content translation from Org to Markdown (plus inline HTML code for figures, etc) "as it is", and Hugo does the job of HTML, RSS, etc. generation, content management (what goes in what directory), link resolution, etc. > -- Kaushal Modi --001a113f8e0c6639a70553f61112 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,


On Sun, Jul 9, 2017, 6:45 AM Nicolas Go= aziou <mail@= nicolasgoaziou.fr> wrote:

The following patch implements `org-html-root', which allows to export<= br> file links as root-relative URL.

Can you please attach the patch?=C2=A0

I'm
=C2=A0not sure the docstring is clear
enough, tho.

Also, HTML publishing process always bind = the above to publishing
directory, without user intervention.

=
Matt and I are working on an exporter backend f= or Hugo, ox-hugo. We are exporting Org to a flavor of Markdown compatible w= ith Hugo. The HTML exporter has some contribution in this exporter.

If a link is "/foo/bar" in the Markdown file, H= ugo assumes "foo" to be present in the "static/" dir in= the site root. So the Markdown link auto expands to "example.org/static/foo/bar<= /a>".



Hello,

Carsten Dominik <dominik@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.=C2=A0 But once it= is clear that something
> is a link to a file, I guess you are right= =C2=A0 that it might not be needed in
> HTML.=C2=A0 We will see what = breaks.....

Thinking about it, we should probably not remove the &qu= ot;file://" prefix.

It= depends.. if people are using Org files exported as HTML to open reference= d files in their browser (though that would work only if they open those HT= ML pages only on that machine). But at=C2=A0least in one browser (Firefox),= I noticed that the browser auto-added the "file://" prefix if us= er tried to access "/static/images/unicorn.jpg" directly from the= address bar.

I cannot think of any situation where [[/a= bsolute/path/to/file]] would
match something like "<img src=3D&q= uot;/absolute/path/to/file"/>", because "/"
never= matches web root directory.

As mentioned above, one example is Hugo, which auto-interprets the presen= ce of absolute links in the Markdown files (whether they are of Markdown or= HTML style).

Note that that "file:///static/images= /unicorn.jpg" is not useful either,
but at least it is logical.
=

=C2=A0I can see the benefit if= a browser does not support auto-detection of local links. But if the patch= works, all should be good :)

The only situation where we = might do something is during publishing,
when we know what web root dire= ctory =E2=80=93 i.e., base directory =E2=80=93 is. In
that case, we coul= d replace absolute file names starting with web root
dir as root-relativ= e URL.

In our case, we are = delegating that step to Hugo. So Org does the job of content translation fr= om Org to Markdown (plus inline HTML code for figures, etc) "as it is&= quot;, and Hugo does the job of HTML, RSS, etc. generation, content managem= ent (what goes in what directory), link resolution, etc.=C2=A0
--

Kaushal Modi

--001a113f8e0c6639a70553f61112--