bug-texinfo
[Top][All Lists]
Advanced

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

Re: images for Info


From: Karl Berry
Subject: Re: images for Info
Date: Thu, 20 Mar 2003 09:35:18 -0500

Hi Jan,

    I've had a quick look at images for Info and made a proof of concept
    code for using images with Emacs' Info viewer.  

Excellent!  Thanks for putting in this work.

    should we create a new command?

I don't see any reason to.  Seems cleaner for @image to just write
whatever we decide.

    The most important thing to decide on is the image tag.  

Indeed.  Here are some issues that come to mind with [image: /file/name] --

1) seems desirable to have a way to continue to embed .txt files for
   plain text info viewers (like standalone info).  So the tag could be
   something like [image start: /file/name] ...txt version of /file/name...
   [image end: /file/name].

2) I bet there will be a desire to supply the image in several formats,
   and supply other information about the image.  So maybe it should be
   [image: cmd=start,file=/file/name] so we can add other attributes later
   in the same syntax.

3) We have to have some way of quoting the tag, so that it can be
   described in a manual :).  Perhaps control characters are the way to
   go, as in: address@hidden@^Himage: address@hidden@^H.
   
   I just checked, and the null/backspace combination does show up
   literally in standalone info, so users of old info programs with new
   info files would see the control characters.  I don't think that's a
   serious drawback.

4) Actually, there are more quoting problems for the filename (what if
   it contains a ] or a CTRL-_, for instance).  Maybe C/Elisp
   style-quoting is the right thing for that:
   address@hidden@^Himage: ..., 
file="/file/name\"with\0\hweird.chars"address@hidden@^H.

5) It think it would be nice if it were at least possible to embed the
   actual images in the info file, instead of having to refer to
   external files.  Perhaps a base64 or base95 encoding of the binary data?

6) Perhaps we should introduce some kind of version identifier in info
   files.  I'm not entirely sure it's necessary for this, though.

What do you (or anyone else...) think of all that?

Thanks,
karl




reply via email to

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