[Top][All Lists]

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

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

From: Vincent Belaïche
Subject: Re: [bug #35395] bad picture path with --html and --without --no-split
Date: Sun, 05 Feb 2012 13:36:35 +0100
User-agent: Thunderbird (Windows/20090812)

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


or just


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


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:


  Message sent via/by Savannah

reply via email to

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