Re: Exporting Hyperlinks ?

[Max Nikulin]

On 08/11/2023 15:02, David Masterson wrote:
> Max Nikulin writes:
>
> > On 07/11/2023 19:36, Ihor Radchenko wrote:
> > > If \href{file.pdf#anchor} can work, we should indeed use it when
> > > publishing org->pdf.
> >
> > It would be nice to have a LaTeX package that redefines \label to
> > generated \hypertarget from its argument.
>
> This would make it easy to create a PDF "website" that doesn't depend on
> a webserver like HTML.  A PDF website could easily be put on a USB key
> to take with you and access via a mobile phone.  This would be secure
> because no network interaction.  This is the use case I've been working
> toward for years.

I do not see clear advantages over a set of HTML files with relative 
links <a href="another.html#relative-links">relative links</a>. I am 
unsure concerning permissions to open sibling files for mobile 
applications (both HTML and PDF ones).

I expect that LaTeX still has issues with generation of PDF files 
suitable for reflow. With proper CSS styles, HTML are are more flexible 
in respect to adapting for particular screen size. ePUB is an HTML-based 
format, but links to other files may be prohibited.

> > Ideally, xr-hyper workflow should be supported as well. A downside is
> > anchors are not stable and unrelated to labels.
>
> Stable in the sense that the CUSTOM_ID could be moved to new file?
> Could IDs play a roll here?

No, I have in mind another case. LaTeX generates anchors like 
#section.6. If you insert another section, this one becomes #section.7. 
So all files having doc.pdf#section.6 links must be regenerated. Links 
based on CUSTOM_ID doc.pdf#export_note continue working even after 
rearranging structure of the target file. This is especially painful if 
target file is out of your control.

I consider the following link as a stable one:
https://www.gnu.org/software/grub/manual/grub/grub.pdf#true

When a heading with ID is moved to another file then anyway all files 
referencing it must be regenerated.