XBM images sometimes inverted on Windows

XBM images sometimes inverted on Windows

[Neil Roberts]

Hi,

I've noticed that when running Emacs under Windows, if you create an
XBM image where the :data keyword is set to a string containing the
actual bits of the bitmap then the foreground and background colours
are swapped. If you use the same image but set the :data keyword to an
XBM image string then the swapping does not occur. The swapping
doesn't occur either way under X. Is this a bug?

Please eval the following code snippet to demonstrate. Under X, both
smilies look the same, but under Windows the bottom smiley is
white-on-black, and the top smiley is black-on-white.

(defconst smiley-data '(#x00 #x00 #x24 #x00 #x00 #x24 #x18 #x00))

(defun smiley-from-xbm-data ()
  ;; Make an XBM image from the smiley data
  (list 'image :type 'xbm :ascent 100 :data
	(concat "#define smiley_width 8\n"
		"#define smiley_height 8\n"
		"static unsigned char smiley_bits[] = {\n"
		"   "
		(mapconcat (lambda (byte) (format "0x%02x" byte))
			   smiley-data ", ")
		" };")))

(defun smiley-from-xbm-bytes ()
  ;; Make an image using the bytes directly in a string
  (list 'image :type 'xbm :ascent 100 :width 8 :height 8
	:data (apply 'string smiley-data)))

(save-excursion
  (set-buffer (get-buffer-create "*Smiley demo*"))
  (erase-buffer)
  (insert "Smiley created from XBM image: "
	  (propertize ":)" 'display (smiley-from-xbm-data)) "\n"
	  "Smiley created from the actual bytes: "
	  (propertize ":)" 'display (smiley-from-xbm-bytes)) "\n")
  (pop-to-buffer (current-buffer)))

Thanks,
- Neil

Re: XBM images sometimes inverted on Windows

[Jason Rumney]

Neil Roberts wrote:
> Hi,
>
> I've noticed that when running Emacs under Windows, if you create an
> XBM image where the :data keyword is set to a string containing the
> actual bits of the bitmap then the foreground and background colours
> are swapped. 
>   
> (defconst smiley-data '(#x00 #x00 #x24 #x00 #x00 #x24 #x18 #x00))
>
>
> (defun smiley-from-xbm-bytes ()
>   ;; Make an image using the bytes directly in a string
>   (list 'image :type 'xbm :ascent 100 :width 8 :height 8
> 	:data (apply 'string smiley-data)))
>   

Does this result in a valid xbm image? There is no width and height
specified, and the data is not in the textual format that an xbm is
supposed to be in.

Re: XBM images sometimes inverted on Windows

[Neil Roberts]

On Sat, Dec 01, 2007 at 01:36:42PM +0000, Jason Rumney wrote:
> Does this result in a valid xbm image? There is no width and height
> specified, and the data is not in the textual format that an xbm is
> supposed to be in.

You are right it doesn't make a valid XBM image, but according to the
elisp manual this is a perfectly valid way of defining an image. The
width and height are specified in the property list instead:

38.16.2 XBM Images
------------------

...

`:data DATA'
     The value, DATA, specifies the contents of the image.  There are
     three formats you can use for DATA:

   ...

        * A string or a bool-vector containing the bits of the image
          (plus perhaps some extra bits at the end that will not be
          used).  It should contain at least WIDTH * `height' bits.  In
          this case, you must specify `:height' and `:width', both to
          indicate that the string contains just the bits rather than a
          whole XBM file, and to specify the size of the image.

Re: XBM images sometimes inverted on Windows

[Jason Rumney]

Neil Roberts wrote:
> The width and height are specified in the property list instead:
>   

I missed that. It seems the code takes a different path when images are
defined like this, and skips using the XBM_BIT_SHUFFLE macro to shuffle
the bits to suit Windows' expectations for monochrome bitmaps.

Re: XBM images sometimes inverted on Windows

[Jason Rumney]

Neil Roberts wrote:
> Hi,
>
> I've noticed that when running Emacs under Windows, if you create an
> XBM image where the :data keyword is set to a string containing the
> actual bits of the bitmap then the foreground and background colours
> are swapped.

This has been fixed in the Emacs 22 branch.
Thanks for your report.