XPM images

XPM images

[Oliver Scholz]

[-- Attachment #1: Type: text/plain, Size: 784 bytes --]

Attached is my library to convert XPM images. If you like to include
it in Emacs, I would now go on and write a patch for images.el to use
it, if there is no XPM support compiled in.

But there are a few issues:

* The "splash.xpm" image that is displayed with the startup-message,
  is a little bigger. While the Lisp-conversion is IMO fast enough for
  small images like icons, it would slow down the startup notably to
  use it on splash.xpm.

* AFAICS the modified code in images.el would have to check the
  variable `image-types' to see, if XPM support is compiled in. This
  is fine so far, but my modification would lead to the end that
  emacs displays XPM images correctly, while ...

   (image-type-available-p 'xpm)

  ... returns nil.

What do you think?

    -- Oliver


[-- Attachment #2: xpm.el --]
[-- Type: application/emacs-lisp, Size: 12369 bytes --]

[-- Attachment #3: xpm-macs.el --]
[-- Type: application/emacs-lisp, Size: 4678 bytes --]

[-- Attachment #4: Type: text/plain, Size: 73 bytes --]


-- 
5 Vendémiaire an 211 de la Révolution
Liberté, Egalité, Fraternité!

Re: XPM images

[Richard Stallman]

    * The "splash.xpm" image that is displayed with the startup-message,
      is a little bigger. While the Lisp-conversion is IMO fast enough for
      small images like icons, it would slow down the startup notably to
      use it on splash.xpm.

We have a file splash.pbm as well.  I presume that Emacs will use that
rather than use your code, right?  So the slowdown is only hypothetical,
right?

Re: XPM images

[Oliver Scholz]

Richard Stallman <rms@gnu.org> writes:

>     * The "splash.xpm" image that is displayed with the startup-message,
>       is a little bigger. While the Lisp-conversion is IMO fast enough for
>       small images like icons, it would slow down the startup notably to
>       use it on splash.xpm.
>
> We have a file splash.pbm as well.  I presume that Emacs will use that
> rather than use your code, right?  So the slowdown is only hypothetical,
> right?

Not necessarily. It depends on the chosen solution. The decision
between splash.pbm and splash.xpm is made in startup.el, based on
functions provided by image.el. So if I go on and hook the
Lisp-conversion into images.el (I guess that would be `create-image'),
it _could_ affect the choice of the image. Of course, I could also
make sure in startup.el that this does not happen. That's why I
asked. Another solution could be to use PPM instead of XPM for the
coloured image, which is, as Gerd said, always supported.

    -- Oliver

-- 
Oliver Scholz               6 Vendémiaire an 211 de la Révolution
Taunusstr. 25               Liberté, Egalité, Fraternité!
60329 Frankfurt a. M.       http://www.jungdemokratenhessen.de
Tel. (069) 97 40 99 42      http://www.jdjl.org

Re: XPM images

[Richard Stallman]

    Not necessarily. It depends on the chosen solution. The decision
    between splash.pbm and splash.xpm is made in startup.el, based on
    functions provided by image.el. So if I go on and hook the
    Lisp-conversion into images.el (I guess that would be `create-image'),
    it _could_ affect the choice of the image. Of course, I could also
    make sure in startup.el that this does not happen.

It would be important to do that.

Re: XPM images

[Richard Stallman]

    ;; `defstruct' generates a bunch of ugly byte-compiler warnings, so we
    ;; do this manually.
    (defun make-xpm-pixmap (&rest keyword-args)
      "Create and return a `xpm-pixmap'.

I am having trouble understanding the code because nothing says
what purpose this data structure is used for.  The file needs
an overall description of the logic.

It also needs the info on what the entry points are and what they do.

None of the functions says it produces or outputs a PPM,
and I can't figure out which function is supposed to do that.

Re: XPM images

[Oliver Scholz]

Richard Stallman <rms@gnu.org> writes:

>     ;; `defstruct' generates a bunch of ugly byte-compiler warnings, so we
>     ;; do this manually.
>     (defun make-xpm-pixmap (&rest keyword-args)
>       "Create and return a `xpm-pixmap'.
>
> I am having trouble understanding the code because nothing says
> what purpose this data structure is used for.  

It is only an intermediate storage format, because I wanted the
functions that generate the PPM-string and the final image to be as
ignorant as possible of what the parsing-functions do. This was my
idea of cleanness at that time and it has proven to be at least
valuable for myself during the course of writing. But if this
separation seems unnecessary, it is quite possible to remove this
code.

> The file needs an overall description of the logic.

I see. I will add such a commentary section.

> It also needs the info on what the entry points are and what they do.

My apologies. Only two functions are supposed to be used from the
"outside": `xpm-image-from-file' and `xpm-image-from-string'. But now
that I am currently looking at images.el again, I think that I should
merge them into a single function `xpm-create-image' which takes
similar arguments as `create-image'. This makes a patch to images.el
simpler.

> None of the functions says it produces or outputs a PPM,
> and I can't figure out which function is supposed to do that.

The only place where PPM occurs is the function
`xpm-pixmap-to-ppm-string' which takes the data structure you
mentioned above as argument and returns a string (which, when saved to
a file, would be a valid PPM image.) PPM is, again, only an
intermediate format (as the format was indeed invented only to be an
intermediate format in image conversion). Besides that, the whole
process of converting to and applying PPM was meant to be
transparent. What the two main functions `xpm-image-from-string' and
`xpm-image-from-file' actually return is an image descriptor, as a
function like `insert-image' takes it as an argument. But I refer to
the image descriptors in the doc-strings only as "images"; thus
mimicking the documentation strings of `insert-image', `create-image'
or `find-image'.

    -- Oliver

-- 
Oliver Scholz               9 Vendémiaire an 211 de la Révolution
Taunusstr. 25               Liberté, Egalité, Fraternité!
60329 Frankfurt a. M.       http://www.jungdemokratenhessen.de
Tel. (069) 97 40 99 42      http://www.jdjl.org

Re: XPM images

[Richard Stallman]

    My apologies. Only two functions are supposed to be used from the
    "outside": `xpm-image-from-file' and `xpm-image-from-string'.

Those names suggest functions that return an xpm image.  However, this
file is supposed to convert xpm to ppm.  So those names are confusing.
The function names for functions that return ppm images should
probably say they return ppm images.  At the very least the doc strings
should say so.

    Besides that, the whole
    process of converting to and applying PPM was meant to be
    transparent. What the two main functions `xpm-image-from-string' and
    `xpm-image-from-file' actually return is an image descriptor, as a
    function like `insert-image' takes it as an argument. But I refer to
    the image descriptors in the doc-strings only as "images"; thus
    mimicking the documentation strings of `insert-image', `create-image'
    or `find-image'.

That convention is very hard to understand; I recommend you find
a clearer way to describe this.