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.