Embedding from Siag

As of 2.23, Siag supports embedding. Both the server and the client specification are implemented in a fully conforming fashion. As an example, here is an object created from Siag:



Embedded table from Siag It may not be pretty, but it's there and it works. The object can be "opened": Siag starts with the document loaded. All in all, it's much better than nothing.

The most basic use of this feature is for plain images, with no regard to the "objectisms". However, the XBM format is not very good for this purpose. It is black-and-white and uses a lot of disk space even for small pictures. There are a few other candidates for the job:



Comparison of image formats Here is a discussion of the pros and cons of some of the more interesting formats.

GIF

Pro: the compressed image is very efficient for storing simple images like screenshots. It can also be displayed in Netscape. This is valuable, because it enables the objects to be used in WWW documents.

Con: the compression algorithm is patented. This is most unfortunate, because it pretty much rules out its use in free software.

JPEG

Pro: can also be displayed in Netscape. The compressed format is efficient for images containing many colours, like photographs.

Con: the compression is "lossy" and not well suited for images with few colours.

Postscript

Pro: the embedding code must be able to generate Postscript anyway, for the embed_print function. The format is very efficient for some types of images.

Con: it is not realistic to link every application with code to parse Postscript. Bitmapped images cannot be efficiently stored as Postscript.

XBM

Pro: the only completely standard X11 image format.

Con: unefficient. Monochrome.

XPM

Pro: Supports colour. Almost an X11 standard: any implementation of X which does not support XPM is broken.

Con: not particularly efficient, but better than XBM. Would be almost perfect, were it not for the fact that Netscape can't display XPM. Chimera can, however.

PNG

Portable Network Graphics has been plugged as the image format for the future, but the truth is that very few programs support it.

Conclusion

There is no colour format that is supported by Netscape and suitable for this purpose, so if Netscape compatibility is an issue, we are stuck with XBM and black-and-white.

If we ignore Netscape, compatibility with the rest of the world becomes the next important issue. XPM is as close to a standard colour format as we will get. It is very annoying, though, that the format is so unefficient: A GIF of a simple image is 1/20 the size of an XPM of the same image. How come nobody has thought of compressing XPM with gzip? Compressing XPM files with gzip reduced the size with 90 % for a small sample I tested.

XPM shares with XBM the property that the file format is plain C which can trivially be #included in C source files. This makes it monumentally simple to create a basic object server.