On 18/06/2026 5:19 am, Julien Dallot wrote:
Based on what we discussed so far, here are some high-level guidelines we may want to follows:
- we want to be able to include arbitrary metadata inside an org link (in plain text form)
"Metadata" is too general to my taste. E.g. position or region in the
target document is more specific. I do not think, it is reasonable to
store e.g. author name inside file: or http: links (besides, perhaps, as
a part of the title attribute).
- we want to be able to store arbitrary metadata in the org element (once the
link was parsed)
- whenever possible, we want to follow web standards for links.
Based on those criteria, here is a possible alternative for the pdf link I presented at the beg of this thread:
[[file:<path>#page=1#highlight=0.240196,0.478535,0.331699,0.494949]]
It was a random example created while looking into the RFC for PDF.
and here is the "web-compatible" equivalent of current org link with
::<search-text> at the end:
[[file:<path>#:~:text=<search-text>]]
There are more options to specify text fragment, some are not supported
by Org.
The idea is that the link content (inside [[]]) is an (almost) working web link.
As is, it actually works: firefox will open the pdf at the right page (if you take the
"highlight" part out).
Firefox supports zoom=z,x,y. One may obtain a link through the
">>"/"Current page" menu.
Note that some post-treatment is necessary to reliably convert any
org link to a web link, just to replace white spaces with special
characters "%20" for instance --- but it seems major web browsers
(firefox and chrome) do this conversion automatically.
Notice that the links above do not come with the usual separator "::".
Yes, and Org should treat links in a backward compatible way somehow.
Although desirable, this compatibility with web seems fragile for many reasons:
- adding any keyword that's not recognized by the web browser makes the whole
set of keywords useless (as I try rn).
Firefox becomes more tolerant if "&" is used as a separator *between*
parameters instead of "#". Anyway, parsing fragment may be required for
other viewers. I have not found docs concerning okular (besides
"#nameddest"), but it supports "#page=5". I am not sure how to combine
page number and search text in URL for any viewer. Parameters may be
passed through command line options though.
I only did superficial documentation there and may be missing key aspects.
But wondering what are your thought on this?
I mostly agree with your summary. Unfortunately I do not have a roadmap
with actionable steps.
