You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
XBM and XPM are two obsolete image formats that were used by the X window system.
It would be nice if image were able to decode them, because some image viewer programs indirectly use image, among them GNOME's Loupe. I happen to have 29 XPM and 88 XBM images scattered through /usr.
Edit: XBM file frequency statistics, if you are interested.
I wrote a script to count file endings for various image formats in the output of pacman -Fl on Arch Linux, which lists all files in all installable packages in the main repositories. The results are of course weighted towards established projects, rather than newer ones, toward images used for or by programs rather than graphics, towards programs like emacs with multiple variant packages, and toward formats for Linux. Counts may also be distorted by symlinks. A † indicates the entry is corrected for false positives (e.g., .pm is always Perl, not XPM, .ff can be force field data, .pfm is a often a font file instead of Portable Float Map, etc.)
Looking over the packages in more detail, .xbm mostly lives in old GUI libraries and programs targeting X11; .xpm is mostly used by icon themes and by random applications that provide an XPM icon. XBM occurs a bit more often than PBM, while (thanks mainly to the icon theme effect that boosts PNG/SVG so much) XPM is a bit more common than the .pbm/.pgm/.ppm/.pnm family.
XBM and XPM can be created by ImageMagick, netpbm (via ppmtoxpm and pbmtoxbm), and libXpm; I am aware of loaders for both formats in imlib2, gdk-pixbuf, and Qt; xscreensaver has its own runtime XPM loader, and I wouldn't be surprised if some other old programs do the same. Because XBM/XPM are interpretable as C headers, they may be used to build some old programs.
Existing XPM decoders are mostly written in C and have historically had security issues. Even if they were safe and free of accidentally quadratic code, integrating them into Rust programs is inevitably painful.
It should not be difficult to make a simple, pure-Rust implementation, which does not panic or abort except on allocation failure. (XBM only needs an image buffer; XPM needs an image buffer and a resizable vector to store palette information.) Unsafe code and additional dependencies are not required. I'd guess at most 200 lines for XBM, and 500 for XPM would be needed. (If I have time, I'll try to write one and see if my guess is right. Edit: XBM took 500 lines, and XPM 900, although half of it is basic parsing+error handling helper code, and XPM has an 800-line color table which is put in an external crate to isolate its X11 license (= MIT + no advertising clause). See https://github.com/mstoeckl/image/commits/xbm/, https://github.com/mstoeckl/image/commits/xpm/, and https://github.com/mstoeckl/x11r6colornames)
The formats are uncompressed, and XBM can be decoded in O(n) time, where n is the file size; XPM in deterministic O(n log n) time.
XPM allows specifying colors by name, which would require embedding a copy of the 17kB X11 color name table. (Or it can be ignored: other than "black" and "white" I haven't seen any color names be used.)
XPM images technically support multiple contexts, where the palette may differ depending on whether one is rendering a color, grayscale (1,2 or 8 bit), or configurable-palette image; but in practice the color mode is the only one used, so I doubt anyone will ever ask for a different mode.
Since XBM/XPM are old, inefficient, and unlikely to be of interest for anything but image viewers, they may be worth putting in an 'obsolete-formats' library feature group that is disabled by default, so typical users can avoid compiling them and save 50kB or so of code+data.
XBM and XPM are two obsolete image formats that were used by the X window system.
It would be nice if
imagewere able to decode them, because some image viewer programs indirectly useimage, among them GNOME'sLoupe. I happen to have 29 XPM and 88 XBM images scattered through/usr.Edit: XBM file frequency statistics, if you are interested.
I wrote a script to count file endings for various image formats in the output of
pacman -Flon Arch Linux, which lists all files in all installable packages in the main repositories. The results are of course weighted towards established projects, rather than newer ones, toward images used for or by programs rather than graphics, towards programs like emacs with multiple variant packages, and toward formats for Linux. Counts may also be distorted by symlinks. A † indicates the entry is corrected for false positives (e.g.,.pmis always Perl, not XPM,.ffcan be force field data,.pfmis a often a font file instead of Portable Float Map, etc.)Looking over the packages in more detail,
.xbmmostly lives in old GUI libraries and programs targeting X11;.xpmis mostly used by icon themes and by random applications that provide an XPM icon. XBM occurs a bit more often than PBM, while (thanks mainly to the icon theme effect that boosts PNG/SVG so much) XPM is a bit more common than the .pbm/.pgm/.ppm/.pnm family.XBM and XPM can be created by ImageMagick, netpbm (via
ppmtoxpmandpbmtoxbm), and libXpm; I am aware of loaders for both formats inimlib2,gdk-pixbuf, and Qt; xscreensaver has its own runtime XPM loader, and I wouldn't be surprised if some other old programs do the same. Because XBM/XPM are interpretable as C headers, they may be used to build some old programs.XBM has a very simple specification at https://www.x.org/releases/X11R7.7/doc/libX11/libX11/libX11.html#Manipulating_Bitmaps. XPM's spec is at http://www.x.org/docs/XPM/xpm.pdf .
Implementation
Existing XPM decoders are mostly written in C and have historically had security issues. Even if they were safe and free of accidentally quadratic code, integrating them into Rust programs is inevitably painful.
It should not be difficult to make a simple, pure-Rust implementation, which does not panic or abort except on allocation failure. (XBM only needs an image buffer; XPM needs an image buffer and a resizable vector to store palette information.) Unsafe code and additional dependencies are not required. I'd guess at most 200 lines for XBM, and 500 for XPM would be needed. (If I have time, I'll try to write one and see if my guess is right. Edit: XBM took 500 lines, and XPM 900, although half of it is basic parsing+error handling helper code, and XPM has an 800-line color table which is put in an external crate to isolate its X11 license (= MIT + no advertising clause). See https://github.com/mstoeckl/image/commits/xbm/, https://github.com/mstoeckl/image/commits/xpm/, and https://github.com/mstoeckl/x11r6colornames)
The formats are uncompressed, and XBM can be decoded in
O(n)time, wherenis the file size; XPM in deterministicO(n log n)time.XPM allows specifying colors by name, which would require embedding a copy of the 17kB X11 color name table. (Or it can be ignored: other than "black" and "white" I haven't seen any color names be used.)
XPM images technically support multiple contexts, where the palette may differ depending on whether one is rendering a color, grayscale (1,2 or 8 bit), or configurable-palette image; but in practice the color mode is the only one used, so I doubt anyone will ever ask for a different mode.
Since XBM/XPM are old, inefficient, and unlikely to be of interest for anything but image viewers, they may be worth putting in an 'obsolete-formats' library feature group that is disabled by default, so typical users can avoid compiling them and save 50kB or so of code+data.
Related: #2367 .
The text was updated successfully, but these errors were encountered: