Samuel Bronson writes:
So, how does Xlib do it with a file, then?
With files written by XWriteBitmapFile, it knows that the first two
(or four) lines will be in a specific format, and can parse them as my
Lisp function did. This format is defined here:
But in general, Xlib can't do it with a file, either. An XBM is just
a C program fragment, containing an (unsigned) char literal (in X10,
shorts were accepted, too!) By convention it also contains #defines
for width and height and optionally the hotspot position, but I've
seen a number of these that don't conform to the X spec above. Xlib
can't handle those (and my code handles a strict superset of those
that Xlib can).
If that's what you meant, couldn't you just make the :file
for "xbm" and re-use the C code from libXmu for the parsing?
No, because image-mode allows you to *create* images in XBM format,
and we don't necessarily want to have to write a file to view it.
We don't exactly know files on disk are properly formatted,
No, but that's not our problem. Buffer content, which may or may not
correspond to any given file on disk, and which may or may not be in
standard format, is our problem.
I figured that whatever small thing you used on Windows could
easily be stolen from for this purpose.
It's not that easy (buffers are not C strings). I finally did find
the "small thing", it's in a file I didn't know existed
(src/glyphs-shared.c), which exists apparently only for this purpose
(allowing Windows to read standard XBMs). The code is highly
optimized and obscure. It does no error-checking, and is technically
incorrect (it assumes the file is 100% ASCII and ignores the locale).
It would be annoying to generalize it to do error-checking.
Unless there's an efficiency issue, I'm much happier writing these
things in LISP so that users can fix my mistakes without recompiling,
relinking, and redumping XEmacs. :-)
XEmacs-Beta mailing list