Re: images for Info

[Jan Nieuwenhuizen]

address@hidden (Karl Berry) writes:

> So I'd prefer to use address@hidden ... address@hidden over just 
> address@hidden@] because it
> makes it that much more unlikely to coincide with any real manual
> text.

> Finally, I see no harm in having the ^H there.

Ok, that makes sense; I'll change it to address@hidden

> Well, the reason is that info files can then remain self-contained, to
> be easier to install/copy/etc.  However, this certainly isn't a
> requirement in order to be able to display images at all, so it's fine
> not to do it.

> Or at least a copy thereof...

Yes; in the case of the LilyPond (possibly the first info manual to
use this feature :-) this would amount to about 5MB; maybe a bit
wasteful even today.

> The Texinfo @image argument is generally a simple filename,
> as you know, not an absolute path (and this is a good thing):
> @image{foo}
> and therefore the foo.png file is going to have to be installed in
> $(infodir) in order for info to find it.  And I doubt that (m)any sites
> will find it convenient to refer to an image within $(infodir) for their
> web pages.

Possibly.  The LilyPond installation installs PNGs in
[/usr]/share/lilypond/<version>/doc/<..> somewhere, and both HTML and
INFO can easily refer to them.  If distribution packagers want to make
it more difficult, that's up to them :-)

> We'll have to warn users (in the manual) that they'll have to copy
> the image files along with the .info* files.

Yes.

> My only comment is that the docstring for split-parameter-string
> could be a bit more descriptive as to what the format is of the
> PARAMETER-STRING's that it's splitting :).

> Also, the function name should probably be something less generic, 
> perhaps just Info-split-parameter-string.  There are all kinds of
> parameters that could be split.

Yes, of course; I'll fix this.  As an aside, I wanted to use symbols
in the -alist instead of the ugly assoc-string, but I couldn't find
the elisp equivalents for GUILE's string->symbol.

> Oh, and is there something in there that replaces a quoted \" with an
> actual "?

Oops.  I'll fix that too.  Emacs must have code that handles escaping
in strings?

I'll look into the remaining issues, and have a go at makeinfo later
this week.

Greetings,
Jan.

-- 
Jan Nieuwenhuizen <address@hidden> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org