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
`@image{someimage}' 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/
