help-texinfo
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Displaying images for html output


From: Christopher Dimech
Subject: Re: Displaying images for html output
Date: Sun, 22 Nov 2020 18:53:48 +0100

> Sent: Sunday, November 22, 2020 at 6:46 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 09:47:09PM +0000, Gavin Smith wrote:
> > 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.
> >
> > I doubt that relative names beginning "../" were much considered
> > when @image was implemented (or even file names with directory parts
> > at all).
> >
> > 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.
>
> Another idea which I didn't think of before is, when the file
> name begins ../, to transform this for split output by adding an
> additional ../ to the front.  Then the relative name would be correct
> for split output.  I don't support this idea, though: I think that
> it's wrong for file names for images to begin with ../ as these names
> are relative to the .texi input file, not for the HTML output files
> which could be copied away from the .texi input file to another location.

There exists the problem that for html, it is likely that one will use images 
with
reduced number of pixels, otherwise the image will be excessively large when 
compared
to the text.  This will produce a low resolution image when using dvi and pdf 
output.

> What could work, though, is just to strip all directories from the
> file name when outputing the <img> elements, as well as copying the
> image files into the output directory.  Then the output HTML manual
> would be complete.  This wouldn't work in case there were two
> image files ../a/foo.png and ../b/foo.png but in that case you should
> run texi2any -I .. and specify the names as a/foo.png and b/foo.png,
> which would cause a and b directories to be created in the output
> directory under the change we are considering.
>
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]