Re: link handling in js-reader

[Per Bothner]

On 3/3/21 9:07 AM, Gavin Smith wrote:
> On Wed, Mar 03, 2021 at 08:09:01AM -0800, Per Bothner wrote:
> > The JavaScript info reader calls the fix_links function to convert
> > cross-references to special "magic" links that load a different page
> > (or scroll within the current one). "External" references are unchanged,
> > except the 'target' attribute is set so they open in a new tab.


> Is this problem just for links to images?  Are there other "internal"
> links that could have this problem?

No, it is not image-specific.  In this case the source is:

@uref{images/domterm-panes-1.png,@image{images/domterm-panes-1}}

The idea is to have a reduced-size (possibly lower-resolution) image,
clicking on which brings up the full-size version.  That in this case
the "thumbnail" is the same image file as the link is coincidental
(and non-optimal).

Note that treating links to subdirectories as external will
probably solve my immediate problem, but the open question is whether
to also exclude non-html files in the same directory (and how to
define "non-html").

> Was the link to the image generated with @uref or was it just created
> with @image?

Yes and no, but the issue is the @uref - the @image is not a problem.

> If it's the former, perhaps there should be some way of
> linking images automatically for HTML output (maybe work to be done for
> the future).

I'm thinking it might make sense for a locally-installed manual
to have reduced-resolution thumbnails in a subdirectory of the html files,
but with links tp full-size images elsewhere (maybe on the web).
(The locally-installed manual could be a zip file, assuming a server
that can serve those up.  In the future I envision using an epub file,
which is just a zip file with some extra structure.)
It might be nice to have texinfo support this mode directly,
but it's not difficult to do it by hand or with modest scripting.

> > Or we can use better heuristics: Only treat as internal references ones
> > that are in the same directory (no '/' in the URL) *and* whose
> > extension is either '.html' or '.xhtml' (for future xhtml/epub support)
> > - e.g.. images are "external".  Or maybe require the file extension in
> > the link to match that of the current page for it to be considered internal.
> >
> > I'm leaning towards the latter approach, which would only
> > require a modest change to fix_links.
>
> If it's a simple fix then that sounds good.  .htm could be another extension.
>
> Another idea is to exclude links to images, but then you would have to have
> a list of image file extensions, which is not as good.

I'm considering that an internal link would have to match either the extension
of the current page (which provides flexibility, including handling 
.htm/.xhtml/.html
along with upper-case versions) *OR* ".html" (as a fallback "just in case 
somebody
does something weird").

--
        --Per Bothner
per@bothner.com   http://per.bothner.com/