bugtexinfo - GNU documentation system - Bugs: bug #35395, bad picture path with --html and...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #35395: bad picture path with --html and --without --no-split

Submitted by:  Vincent Belaïche <vincentb1>
Submitted on:  Sun 29 Jan 2012 07:32:30 PM UTC  
 
Category: makeinfoRelease: texi2any CVS depo
Priority: 5 - NormalSeverity: 3 - Normal
Item Group: bugPrivacy: Public
Open/Closed: ClosedAssigned to: Patrice Dumas <pertusus>
Status: Fixed

(Jump to the original submission Jump to the original submission)

Wed 12 Sep 2012 08:46:57 AM UTC, comment #11:

Sorry, the comment was for the other bug.

This is also fixed, with a customization variable, IMAGE_LINK_PREFIX, to be used like

texi2any --set-customization-variable IMAGE_LINK_PREFIX=../somewhere

Patrice Dumas <pertusus>
Project MemberIn charge of this item.
Wed 12 Sep 2012 08:43:54 AM UTC, comment #10:

This should be fixed in CVS, by using portability functions for file names.

Patrice Dumas <pertusus>
Project MemberIn charge of this item.
Sat 04 Feb 2012 07:53:01 PM UTC, comment #9:

Bonsoir Patrice,

Concerning the problem with html file not generated in the right
place, I did use the latest CVS. However, it seems that the
problem is connected with filename format in MSWindows, and this
is why you could not reproduce it.

FYI, I am starting the compilation from ant with that kind of
target specification:

Well, as ant expands filenames to absolute names this means that
the actual command is (under MSWindows):

above:

  • `jpicedt' is the source directory
  • `dist' is the directory for distribution.
  • `makeinfo' is just a wrapper bash script to texi2any it reads as follows:

FYI sh is the MSYS sh. I am doing this wrapper trick because I
would like the build.xml ant buildfile to be portable to work
also under Linux (assuming that jPicEdt other developpers under
Linux would have some aliasing of makeinfo to texi2any in their
~/.bash_profile).

So, to recap, I am using a bash script to launch an MSWindows
based Perl engine runing your scripts, and taking filename
arguments with supposedly MSWindows separator, ie `\'.

Please note that if I used that command line from and MSDos
console:

Then the output is generated in the right place. Hopefully, that
makes clearer the case.

My understanding is that it is a portability bug of texi2any:
somewhere you are tampering with filenames directely with
regexping hardcoded `/' separators, rather than using only
library functions like Perl counterparts of Bash dirname,
basename and suchlikes.

Please note that I could make my ant buildfile robust to this
problem by using ant file translation feature. If you think that
this is only my problem and not yours, then I will do that.

Well, my personal feeling is that MSWindows is the real problem,
but it is not my choice to always use MSWindows as at home I am
borrowing my wife's PC.

Vincent.

Vincent Belaïche <vincentb1>
Sat 04 Feb 2012 04:31:45 PM UTC, comment #8:

I cannot reproduce the issue with the manual created in the source manual directory. Did you use a recent CVS update?

Concerning your proposition, it seems to me that the command line option should better be called --image-link-prefix

The remaining of your scheme makes sense, but I think that it is too complicated. I think that it is better to have something simple rather than something that tries to adapt to some situations.

My current opinion is to have --image-link-prefix set to nothing in the default case, so that the images paths are always relative to the output directory in the default case, and let the user adjust the path if it is not what they want.

Patrice Dumas <pertusus>
Project MemberIn charge of this item.
Sat 04 Feb 2012 09:37:27 AM UTC, comment #7:

Salut Patrice and al.,

After some further thoughts my suggestion would be as follows:

- provide a new command line option --link-prefix that allows the user to force some prefix for relative links

- if the user does not explicitely give some output directory with --output or -o, then add prefix `../' automatically when the --html w/o --no-split options are used.

- if the user sets some output directory name with --output=FILE --html, but w/o --no-split and w/o --link-prefix then do not prepend `../' if FILE has some path specified, but do prepend `../' if FILE hasn't any path (i.e. basename extraction does not change FILE)

so:
--html --output=./somedir

won't prepend `../'

but
--html --output=somedir

will prepend `../'

- if the users sets some prefix with --link-prefix, simply use this prefix, which overrules all the rules above.

If you agree with this proposition, then I can contribute the documentation update.

Vincent Belaïche <vincentb1>
Thu 02 Feb 2012 12:20:26 AM UTC, comment #6:

The second issue indeed seems to be a bug. The manual should be created relative to the current directory.

Regarding the first issue, a problem arise if you specify an output directory. Then ../ is not correct anymore. I had code to find the relative directory in the general case too, but it is not clear that it is right to do.

Patrice Dumas <pertusus>
Project MemberIn charge of this item.
Mon 30 Jan 2012 09:18:06 PM UTC, comment #5:

It's really a pity that Savannah does not let me correct all the typoes I made in my previous comment :-( --- good that it was in English, so I have some illusory excuse...

Vincent Belaïche <vincentb1>
Mon 30 Jan 2012 09:09:59 PM UTC, comment #4:

Salut,

I also think that absolute path don't make sense, because one likes to move a manual around.

Also, you need to keep in mind that texi2any issues a warning when the image file is not found, so when you run texi2any, you have an idea where is image files are, and because you have this idea you are able to set the relative paths to this files referred from the generated HTML location. Generally speaking this simply consist in take the relative path as is with --no-split option, and with ../ prefix without --no-split, as Karl suggested.

Concerning this I found another issue, let me tell you what. I want to generate jPicEdt manual, and include it into the distribution jar file. So I proceed as follows:

1. I first erase the whole content of directory
/jpicedt/distribution/help-files

please note that /jpicedt/distribution is the directory that is gneerated and jarred to produce the distribution, so one destroys /jpicedt/distribution to rebuild all cleanly.

2. Then I copy all the pictures of interest into a new directory:
/jpicedt/distribution/help-files/img

3. Then I run the following command:

current directory =
/jpicedt/distribution/help-files/

command line =
texi2any --html --no-split /jpicedt/source/help-files/fr.texi

(fr.texi is the manual in French, and it contains some @image commands like this @image{img/mypicture, ...}

texi2any does not bark that it does not find the picture files because it is using the current directory for testing the file presence, and all the picture are in currentdirectory/img, which is consistent with the @image{...} file paths.

However the file fr.html is generated as /jpicedt/source/help-files/fr.html. This is not consistent, it should have been generated as /jpicedt/distribution/help-files/fr.html.

What I am meaning is that if you test the file presence relative to some/place , then you have to place the generated HTML in the same location some/place in the case of --no-split, or in new directory some/place/fr and without --no-split (when we have @setfilename fr.info). Otherwise does it make any sense to test the presence relative to some/place. In other words, it should be possible to configure some/place to be either the current directory or the directory where the top texi source file is placed, but not to have some/place have different values for different things.

Ok, this issue is not a big issue, because I can copy first fr.texi from /jpicedt/source/help-files/ to /jpicedt/distribution/help-files/, and then run the command.

current directory =
/jpicedt/distribution/help-files/

command line =
texi2any --html --no-split fr.texi

and then erase fr.texi

Vincent.

Vincent Belaïche <vincentb1>
Sun 29 Jan 2012 11:01:18 PM UTC, comment #3:

if "complete image paths" means "absolute", then i certainly agree we don't want to use absolute file names in the output. but that doesn't mean there couldn't be an option to alter what relative path is output.

Specifically. for the case Vincent is talking about (which is the most common scenario I've seen), what's needed is to prefix "../" to what the user supplied, for split output only. it corresponds to an output layout like this:

foo.html
html_node/index.html
img/bar.img

i don't propose hardcoding the particular case of prepending "../" as a configuration variable, but perhaps there could be a way to specify a prefix, suffix, and/or general transformation of the image directory supplied by the user. maybe a way to specify a perl expression that is applied before it is output?

wdyt?

Karl Berry <karl>
Project Administrator
Sun 29 Jan 2012 10:49:26 PM UTC, comment #2:

There is this changelog entry in texi2html (2008-08-18).

  • texi2html.init: in the default case, don't complete image paths

as suggested by Reinhold. It is what makeinfo does, completing
paths is confusing and use case is dubious. Complete paths
if $COMPLETE_IMAGE_PATHS is set.

(COMPLETE_IMAGE_PATHS is not used anymore in tp/). If I recall well, the idea was that path was unreliable anyway since manuals were likely to be moved and then it was simpler to use the path considering it to be relative to the final manual and let the user copy the image files at the right place.

Patrice Dumas <pertusus>
Project MemberIn charge of this item.
Sun 29 Jan 2012 10:34:32 PM UTC, comment #1:

hi Vincent -- i agree it's a problem, but if you have @image{img/somepicture}, i don't see how makeinfo can guess anything else. granted that the usual organization on http://www.gnu.org is like you describe, it's not universal. and usually, there are no images at all. guessing something different for split vs. non-split output seems like a morass to me.

however, what i can imagine is to have some config var that would alter the output <img> locations. patrice, i know we've talked about this a little. did we ever do anything :)?

thanks,
k

Karl Berry <karl>
Project Administrator
Sun 29 Jan 2012 07:32:30 PM UTC, original submission:

Hello Patrice,

Karl wrote to me that texi2any now works fine for HTML output. I have noticed the following issue with the version on CVS depo:

when I compile with option --html some file fr.texi, with current directory /some/dir/, then all the files are placed under some/dir/fr. Now fr.texi contains some macro @image{img/somepicture}, and I have the somepicture.png file in /some/dir/img/somepicture.png

Now, I get some html output /some/dir/fr/someoutput.html that contains <img src="img/somepicture.png ... />, this is incorrect because there is no picture /some/dir/fr/img/somepicture.png, so texi2any should have generated <img src="../img/somepicture.png ... /> instead.

So, if I use --no-split, that works fine, because in that case I get a single file /some/dir/fr.html.

BR,
Vincent.

Vincent Belaïche <vincentb1>

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by pertusus (Posted a comment)
  • -unavailable- added by karl (Posted a comment)
  • -unavailable- added by vincentb1 (Submitted the item)
  • -unavailable- added by vincentb1 (Bonne année 2012 --- si, si, on a le droit jusqu'à fin janvier !)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 12 Sep 2012 08:43:54 AM UTCpertususOpen/ClosedOpen=>Closed
      Assigned toNone=>pertusus
      StatusNone=>Fixed
    Sun 29 Jan 2012 07:32:30 PM UTCvincentb1Carbon-Copy-=>Added pertusus

    Back to the top


    Powered by Savane 3.1-cleanup1