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

[Vincent Belaïche]

Following up only by email, as recommended by Karl.

Concerning the option name (if any command line option is ever to be 
added), should that be

--image-link-prefix

or just

--link-prefix


I am wondering: don't you have the same issue with command line option 
--css-ref. In the command line you give it relative to current 
directory, but in generated HTML, without --no-split you would need some 
../ prefix, wouldn't you? Or, do you assume that in that case the user 
is supposed to give directly the path relative to the place where the 
HTML is generated. In such a case --image-link-prefix is better, I do agree.

Concerning now the question whether a command line option or an 
environment variable is better, I think that you could have a very 
general environment variable that is a list of command line options that 
are automatically placed before all the other options, and which you can 
overload by subsequent explicit command line options. The problem with 
environment variables is that they are visible by all applications, so 
they should be reasonably few. So typically an application has a number 
of command line options that is one order of magnitude greater than the 
number of environment variables. So, in a nutshell, that should not be 
`either ... or', but that kind of issue should be possible to tackle 
both via the environment or via some command line option.

Now, concerning whether `texi2any --html some.texi' will convert 
address@hidden' to `<img src="someimage.xxx" />' or to `<img 
src="../someimage.xxx" />', my opinion is as follows: you have different 
kinds of users: novice users and experimented users. It should be 
possible that novice users can use the tool with only knowing a very 
minimum set of options, like just the option specifying the type of 
output. So the tool should work fine for a novice user that has only to 
know that --html will generate HTML. In other words, it would be quite a 
pity if `texi2any --html some.texi' does not work as it is, as this 
means that the novice user will have to read more extensively the manual 
to find that (s)he need this quite lengthy-named option 
--image-link-prefix. Surely (s)he would need to read about it in the 
case that (s)he wants to do some more complex generation (like using 
--ouptut/-o options together). Being friendly both to novice and 
experimeted users is the objective which I targetted with my proposal.

Now, what I propose is to simplify my proposal as follows: do not test 
any longer the presence of some path in --output=FILE as in my original 
proposal, and simply do as follows:
- with --html, w/o --no-split, and w/o --image-link-prefix : prepend `../'
- with --html --no-split and w/o --image-link-prefix : no prepending 
anything
- with --html --image-link-prefix=PREFIX and with or w/o --no-split : 
prepend PREFIX


VBR,
   Vincent.


Patrice Dumas a écrit :
> 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/
>
>
>