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

[Jimmy Zelinskie]

URL:
  <http://savannah.gnu.org/bugs/?35395>

                 Summary: bad picture path with --html and --without
--no-split
                 Project: texinfo - GNU documentation system
            Submitted by: vincentb1
            Submitted on: dim. 29 janv. 2012 19:32:30 GMT
                Category: makeinfo
                 Release: texi2any CVS depo
                Priority: 5 - Normal
                Severity: 3 - Normal
              Item Group: bug
                 Privacy: Public
             Open/Closed: Open
             Assigned to: None
         Discussion Lock: Any
                  Status: None

    _______________________________________________________

Details:

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.




    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?35395>

_______________________________________________
  Message posté via/par Savannah
  http://savannah.gnu.org/

[Jimmy Zelinskie]

Follow-up Comment #1, bug #35395 (project texinfo):

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 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


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?35395>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/

[Jimmy Zelinskie]

Follow-up Comment #2, bug #35395 (project texinfo):

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.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?35395>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/

[Jimmy Zelinskie]

Follow-up Comment #3, bug #35395 (project texinfo):

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?


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?35395>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/

[Jimmy Zelinskie]

Follow-up Comment #4, bug #35395 (project texinfo):

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.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?35395>

_______________________________________________
  Message posté via/par Savannah
  http://savannah.gnu.org/

[Jimmy Zelinskie]

Follow-up Comment #5, bug #35395 (project texinfo):

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...

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?35395>

_______________________________________________
  Message posté via/par Savannah
  http://savannah.gnu.org/

[Jimmy Zelinskie]

Follow-up Comment #6, bug #35395 (project texinfo):

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.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?35395>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/

[Jimmy Zelinskie]

Follow-up Comment #7, bug #35395 (project texinfo):

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.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?35395>

_______________________________________________
  Message posté via/par Savannah
  http://savannah.gnu.org/

[Jimmy Zelinskie]

Follow-up Comment #8, bug #35395 (project texinfo):

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.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?35395>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/

[Jimmy Zelinskie]

Follow-up Comment #9, bug #35395 (project texinfo):

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:


  <target name="help-texi2html">
        <apply executable="sh"
                   dir="${dist-resources.dir}/help-files/" >
      <arg value="makeinfo"/>
      <arg value="--html"/>
      <arg value="--no-split"/>
          <srcfile />
          <fileset file="${src.dir}/help-files/*.texi"/>
        </apply>
  </target>



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


sh makeinfo --html --nosplit
C:msys1.0localprojectsjpicedtjpicedtjpicedthelp-filesfr.texi


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:


#!/bin/sh

source ~/.bash_profile
texinfo_home=c:/msys/1.0/local/projects/texinfo/texinfo/
makeinfo=${texinfo_home}tp/texi2any.pl

${makeinfo} "$@"


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:


C:msys1.0localprojectsjpicedtjpicedtdisthelp-files>sh makeinfo --html
--nosplit ../../jpicedt/help-files/fr.texi


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.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?35395>

_______________________________________________
  Message posté via/par Savannah
  http://savannah.gnu.org/

[Patrice Dumas]

On Sat, Feb 04, 2012 at 07:53:01PM +0000, Vincent Belaïche wrote:
>
> 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.

Indeed, I do that a lot.  This is inherited from texi2html, though,
so I figured there was something magical in perl regexp to consider
\ as / automatically.  Looks like it was wrong...

--
Pat

[Karl Berry]

    Indeed, I do that a lot.  This is inherited from texi2html, though,
    so I figured there was something magical in perl regexp to consider
    \ as / automatically.  Looks like it was wrong...

No, it would crazy to automatically make the meaning of \ and / in
regexps platform-dependent :).

In general, / works fine on Windows as a separator.  I'm not sure why
it's not working here, but I don't think it's our job to worry about it.
Vincent, if you need it to work, I think you should prepare the patch.
Sorry.

k

[Patrice Dumas]

On Sat, Feb 04, 2012 at 02:49:06PM -0800, Karl Berry wrote:
>     Indeed, I do that a lot.  This is inherited from texi2html, though,
>     so I figured there was something magical in perl regexp to consider
>     \ as / automatically.  Looks like it was wrong...
>
> No, it would crazy to automatically make the meaning of \ and / in
> regexps platform-dependent :).
>
> In general, / works fine on Windows as a separator.  I'm not sure why
> it's not working here, but I don't think it's our job to worry about it.

I know why, instead of dirname, for instance, there are regexp like,
l. 923 of texi2any.pl

  if ($input_file_name =~ /(.*\/)/) {
    $input_directory = $1;
  }

or l. 334, to determine if a path is absolute:
  if ($file =~ /^\//) {

Both will fail if the path separator is \.

Though, since I cannot test on windows, I'd prefer a patch also tested on
unix/linux rather than doing it myself.

--
Pat

[Karl Berry]

I think we should just declare \ paths to be known not to work.
Trying to support them seems like madness to me.  It will complicate
things everything.

k

[Karl Berry]

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

My initial reaction is that it would be better as a configuration
variable than a command line option.

I think I agree with Patrice that the default behavior should be simple
and not depend on other options/variables.  If the document says
@image{somedir/foo}
then the output should be <img src="PREFIXsomedir/foo.png">
where PREFIX is specified by the variable.  Is there any rational
alternative?

Although this means the prefix has to be manually set to ../ in the case
of split output and shared images, that seems a small price to pay.
(And gendocs.sh could do it, to handle the usual GNU manual style,
although virtually no manuals have images, anyway.)

Thanks,
Karl

[Patrice Dumas]

On Sat, Feb 04, 2012 at 03:00:36PM -0800, Karl Berry wrote:
> I think we should just declare \ paths to be known not to work.
> Trying to support them seems like madness to me.  It will complicate
> things everything.

I will fix the absolute path detection in any case, as my wild guess
is that it should not work on windows even if separatir is / and it
seems that it is easily handled by File::Spec.

Otherwise I tend to agree that we should just declare \ paths to be
known not to work, until somebody does a patch.  And even doing a patch
may not be the only condition, as there also would also be a need
for somebody taking care that it still works in the future which implies
following the development.

--
Pat

[Karl Berry]

    Otherwise I tend to agree that we should just declare \ paths to be
    known not to work, until somebody does a patch.  

I've come to believe we should not even accept a patch.  Any such
support would tend to be pervasive, destabilizing, and require further
work in who-knows-how-many-places.  And furthermore, \ paths are not
going to work in texinfo.tex, ever.

Texinfo has existed for some 25 years without supporting \ paths, so I
simply cannot believe we need to start now.

k

[Patrice Dumas]

On Sat, Feb 04, 2012 at 03:19:49PM -0800, Karl Berry wrote:

>     Otherwise I tend to agree that we should just declare \ paths to be
>     known not to work, until somebody does a patch.  
>
> I've come to believe we should not even accept a patch.  Any such
> support would tend to be pervasive, destabilizing, and require further
> work in who-knows-how-many-places.  And furthermore, \ paths are not
> going to work in texinfo.tex, ever.
>
> Texinfo has existed for some 25 years without supporting \ paths, so I
> simply cannot believe we need to start now.

Ok.  I sort of assumed that makeinfo in C supported \ paths.

--
Pat

[Eli Zaretskii]

> Date: Sun, 5 Feb 2012 00:27:18 +0100
> From: Patrice Dumas <pertusus@...>
>
> On Sat, Feb 04, 2012 at 03:19:49PM -0800, Karl Berry wrote:
> >     Otherwise I tend to agree that we should just declare \ paths to be
> >     known not to work, until somebody does a patch.  
> >
> > I've come to believe we should not even accept a patch.  Any such
> > support would tend to be pervasive, destabilizing, and require further
> > work in who-knows-how-many-places.  And furthermore, \ paths are not
> > going to work in texinfo.tex, ever.
> >
> > Texinfo has existed for some 25 years without supporting \ paths, so I
> > simply cannot believe we need to start now.
>
> Ok.  I sort of assumed that makeinfo in C supported \ paths.

It does, indeed.

[Patrice Dumas]

On Sun, Feb 05, 2012 at 06:04:18AM +0200, Eli Zaretskii wrote:
> > Date: Sun, 5 Feb 2012 00:27:18 +0100
> > From: Patrice Dumas <pertusus@...>
> >
> > Ok.  I sort of assumed that makeinfo in C supported \ paths.
>
> It does, indeed.

Then I guess, we should accept patches.  Hopefully, this should not be
too messy, although using / is pervasive, I don't think the use is exotic
and cannot be replaced by File::Spec stuff.

--
Pat