Bug 156058
Summary: | imlib2 doesn't like "\\" in XPMs | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Ignacio Vazquez-Abrams <ivazqueznet> |
Component: | imlib2 | Assignee: | Dams <anvil> |
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 3 | ||
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2005-05-09 19:31:32 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Ignacio Vazquez-Abrams
2005-04-27 06:55:10 UTC
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". 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. |