Re: [Texi2html-bug] path to @images with output dir and cwd!=texifiledir

[Reinhold Kainhofer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Mittwoch, 13. August 2008 schrieb Patrice Dumas:
> On Sun, Aug 10, 2008 at 05:41:31PM +0200, Reinhold Kainhofer wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Hi Patrice,
> > Another issue I'm encountering with path names: I have a file with
> >     @image{lily-flat-bw,,,png}
> > Now, texi2html seems quite inconsistent with the path to the image if
> > output dir is used:
> >
> > Case a) In "testdir/image_relative" run
> >     texi2html --split=section --out=out-www/ texi2html_images.texi
> > The img in out-www/texi2html_images.html will now be
> >        <img src=".././lily-flat-bw.png" alt="png">
> > which accidentaly works, but not as intended.
>
> Why not as intended?

Because makeinfo --html always produces src="lily-flat-bw.png", so I thought 
that since I didn't give any path information, the link should also not 
include any path information.

> > Case b) Now, in "testdir", run
> >     texi2html --split=section --out=images_relative/out-www/  \
> >         images_relative/texi2html_images.texi
> > The img in images_relative/out-www/texi2html_images.html will be:
> >        <img src="../images_relative/lily-flat-bw.png" alt="png">
> > Obviously, the link is wrong.
>
> This is a bug. Though I verified that the path from the document to the
> working dir is right, I completly messed up the path afterwards. So
> strange. This should be fixed in cvs. Now it is
> src="../../images_relative/lily-flat-bw.png"
> which is right (though maybe unnecessarily complicated).

Actually, this breaks as soon as you move the file to a different directory. 
It assumes that the png file is in a directory called images_relative, so you 
cannot rename that dir afterwards. The problem I'm having is 
that ../../images_relative/ is not simplified to ../

> > For comparison: makeinfo --html in all cases generates
> >      <img src="lily-flat-bw.png" alt="png">
> > i.e. the img file is in the same dir as the html file, which is what I
> > would expect, too.
> >
> > Since my original @image call didn't include any path information,
> > shouldn't the output also be without path information?
>
> It is not obvious. The image files are searched in directories
> relative to the manual directory, with -I taken into account.
> It is what makeinfo does (unless I am missing something) and I
> decided to mimic it in texi2html. But then the paths are wrong if the
> out file is not in the manual directory, so I decided to give the paths
> corresponding with the detected image file, otherwise what is the point
> of detecting the image file paths?

Okay, here is our use scenario: We have a .texi file and a .png file in a 
directory out-www and generate a *-big-page.html in out-www and a split 
document in out-www/lilypond/. The CWD for the texi2html calls is the parent 
dir of out-www.

Now, the files from out-www are then installed by "make web" into some other 
directory, so all pathes that include out-www will be wrong. Right now that's 
the case, since the link to the image in out-www/*-big-file.html 
is ../out-www/image.png, while it should rather be image.png only. The 
*-big-file.html is then installed to a a directory named user/, 
so ../out-www/ is no longer pointing to a file parallel to the .html file.
Simlarly, in out-www/lilypond/index.html the link is ../../out-www/image.png 
rather than ../image.png.

So, in short: we can live with the current situation, as soon as pathes are 
flattened out as much as possible. Then I'm fine with the current way (which 
actually saves us the step of copying the .png files to the subdirs ;-) )

Actually, thinking of it, we can live with it, but it's far from ideal, 
because it means that one cannot simply take one of lilypond's manual (e.g. 
lilypond-learning), but that you have to take the whole dir structure, 
because the files in lilypond-learning/ depend on several image files being 
in its parent directory... These directories are no longer self-contained.

> Still it is unclear that it is right since I believe that in most
> realistic cases of complex out directories, the image files
> are to be moved to the directory too. So the image file paths at
> document generation time are not relevant. I guess this is your use
> case, typical of putting some doc on the web (I ran on this issue too).

Yes, but we are also copying the files from the dir with the .texi files, so 
the links will work, as long as they don't include the explicit dirname of 
the directory with the .texi files.

> We  really need to draft a specification of what we want, as Karl said
> and currently it is very unclear to me. Do you have a clear idea of what
> should be the right behaviour?

Actually, there are two possible behaviors:
1) @image{file.png} means "take the .png file in the same directory", i.e. 
src="file.png", irrespective of the --outdir setting. This means that one has 
to manually copy the .png file to the outdir, but has the advantage that you 
can copy the outdir somewhere else (e.g. a server) and everything will work.

2) @image{file.png} means "there is a .png file parallel to the .texi file. 
Use relative pathes (from outdir to the texi dir) to get exactly this file", 
i.e. src="./path/from/html/to/png/in/texi/dir/file.png". The advantage is 
that you don't have to copy the .png file, but unfortunately you will no 
longer be able to copy only the outdir to a server. You'll either have to 
duplicat the whole dir structure on the server of manually change the html...

For simplicity, I would favor 1), mainly because I think it is quite important 
that directories are as self-contained and independent from each other as 
possible and that moving/renaming them on a web site is easy.

Cheers,
Reinhold

- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: address@hidden, http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iD8DBQFIowZUTqjEwhXvPN0RAuhLAJ9hNr2kB65+AzpChOZYkzkX0tTcbACgs5XI
qYoda9tcqiIEpA2AQdM57KM=
=QRA8
-----END PGP SIGNATURE-----