Re: Displaying images for html output

[Christopher Dimech]

> Sent: Wednesday, November 18, 2020 at 10:47 PM
> From: "Gavin Smith" <gavinsmith0123@gmail.com>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: "help-texinfo gnu" <help-texinfo@gnu.org>
> Subject: Re: Displaying images for html output
>
> On Wed, Nov 18, 2020 at 10:15:40PM +0100, Christopher Dimech wrote:
> > > > Thanks for sending the input and the output.  This problem only occurs
> > > > when the image file is not found.  I've tried to fix it in commit
> > > > e2d579377.
> > >
> > > Does it really! I have to check that out, give me a moment.
> >
> > No.  The file exists and I use the correct path relative to
> > index.html. So the path is correct as far as html is concerned.
>
> As you said in another email the file name should be relative to
> the Texinfo file for consistency with other output formats.

Correct.  I suppose you have made the change.  My comment was on
how I had tested it. At that time in test.texi the path that
a user had to put for html output was relative to the index file.

> I doubt that relative names beginning "../" were much considered
> when @image was implemented (or even file names with directory parts
> at all).

Relative paths are very good, because if you copy your document project
somewhere else or on another machine, you will still be able to execute
the texinfo commands and nothing will break.  And if you give a copy to
your friend, he can get to work straightaway, ne need to change paths.


> I haven't thought of a clear answer for this issue yet.  I think that
> for split output, the image files need to be copied into the output
> directory and the file names should be given under that, not beginning
> "../".  Alternatively, you could create a symbolic link to a directory
> containing the image files under the output directory.
>
> It's odd that the include path should be searched for image files.
> This makes sense for TeX but not for other formats, as there is no
> search path for image files for HTML or Info.  It would only make sense
> if texi2any was going to copy the image files to the output location.

So the user has to transfer the files somewhere and picks them from there?
'<img src="https://path/file.svg>' always has some sort of path anyway.

For large projects, image files are put in hierarchical directory structures.
If you copy everything as is, your docu.texi will help you as the location
of images is structured. If you put everything together, it will be a mess
to manage.  It is not a critical problem if internally texinfo makes a copy
of the image files and refers to that.  But don't mess the texinfo code itself.
In the source code users must be able to use a directory structure for images.