Hello everyone,
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) - 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]] and here is the "web-compatible" equivalent of current org link with ::<search-text> at the end: [[file:<path>#:~:text=<search-text>]] 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). 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 "::". Then, the above format may cause issues if the path contains "#", making the end of the path and beginning of metadata unclear. A possible solution may be to systematically start the metatdata with "#:~:" instead of "#". This char sequence is called a ~fragment directive~ and it seems to do the job well for us: " Otherwise known as the fragment directive, this sequence of characters tells the browser that what comes next is one or more user-agent instructions, which are stripped from the URL during loading so that author scripts cannot directly interact with them. User-agent instructions are also called directives. " coming from [[https://developer.mozilla.org/en-US/docs/Web/URI/Reference/Fragment/Text_fragments#:~:text=fragment%20directive][there]] 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). So its seems that if we want to add an emacs-specific keyword, then the whole link becomes corrupted --- it still opens, but no further action is performed (like scrolling to the right pdf page) - neither firefox nor chrome support region highlighting for now ("#highlight=<lt>,<rt>,<top>,<btm>") - (certainly minor) as discussed, it creates links that are harder to parse for a human compared to plists. I only did superficial documentation there and may be missing key aspects. But wondering what are your thought on this? Julien "Christian Moe" <[email protected]> writes: > Max Nikulin <[email protected]> writes: >> I am against Christian's idea to combine properties identifying >> document fragment (your proposal, they may vary across media types) >> and link attributes for export backends (often independent of file >> type) in link path part that is used for search. > > Fwiw, you convinced me. :) > > Regards, > Christian
