Bug 156058 - imlib2 doesn't like "\\" in XPMs
imlib2 doesn't like "\\" in XPMs
Product: Fedora
Classification: Fedora
Component: imlib2 (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dams
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2005-04-27 02:55 EDT by Ignacio Vazquez-Abrams
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-05-09 15:31:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Ignacio Vazquez-Abrams 2005-04-27 02:55:10 EDT
When imlib2 encounters a pixmap that uses "\\" (which is actually "\" as per C
spec) it segfaults. This can be seen in /usr/share/icons/notecase.xpm that comes
in the notecase package in Extras. Both feh and epsilon crash when trying to
process it. ImageMagick has no problem displaying it.
Comment 1 Michael Schwendt 2005-05-09 09:48:12 EDT
Not quite. ImageMagick has other problems displaying it. Gthumb, gqview, and
netpbm-progs, too. They all parse and display the lines, which include \\,
incorrectly. And actually, the original XPM documentation is not clear whether
Standard C escaped character sequences can be used as pixel values, which are
defined with a constant "characters per pixel" value. Theoretically, you could
use \\\\ to get \\ in the compiled string and hence have four characters per
pixel in the source file and two characters per pixel in the binary data. Very
ugly for a file format that's supposed to be editable in a text-editor.

Suggestion: Report it upstream for both "notecase" and "imlib2".
Comment 2 Michael Schwendt 2005-05-09 15:31:32 EDT
I've imported a fix for this but want to point out that the notecase.xpm is
broken and ought to get fixed, too. Check this out:

"[ 	c #8C928C",
"\\	c #8C9274",
"] 	c #848A6C",

As you can see here in the colour table, the backslash escaped string has the
same length than the non-escaped strings before and after it. The pixel values
they want here are: "[ ", "\ " and "] ", i.e. two characters per pixel. Instead,
the string with \\ expands to just '\', which is one character per pixel,
missing a space after the backslash and before the tab. I'm not surprised that
ordinary XPM parsers fail to handle such weird pixel values in addition to the
\\ specialty.

Note You need to log in before you can comment on or make changes to this bug.