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

[Patrice Dumas]

On Sun, Feb 05, 2012 at 01:36:35PM +0100, Vincent Belaïche wrote:
> 
> 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.

--css-ref is used in the <link> as is so the user should know what he
puts here. --css-include file is directly included.  For now the only
paths are image paths.

> Concerning now the question whether a command line option or an 
> environment variable is better, I think that you could have a very 

It is not environment variables, in texi2any, to avoid cluttering the
command line options, there are many customization options that are set like
texi2any --set-init-variable IMAGE_LINE_PREFIX=../ file.texi

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

Not really disagreeing here, but it is not completly obvious what means
--html not working.  The main problem here is that there is no result
that is more intuitive than another.  A user (novice or experimented...)
may expect both 

* relative image files are images files found when generating 
* image files relative to the final directory

'Relative image files are images files found when generating' works well
if the manual is built locally and used locally.  But if the manual is 
to be distributed, like, put on a web site, it makes more sense to have 
the 'image files relative to the final directory' and let the user copy 
the image files at the right place.  That's what Reinhold thought, at least.

> 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

That's already better, yet, the fact that with --output neither 
the 'relative image files are images files found when generating' nor
'paths relative to the final directory' really works is unsettling.
Though I think I still prefer the simplest possibility of a file relative
to the final directory, I think that this could be acceptable.

Karl?

-- 
Pat