GNU bug report logs - #26133
25.1; XBM images broken - worked in 24.3

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 26133 in the body.
You can then email your comments to 26133 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Devon Sean McCullough" <Emacs-Hacker2016 <at> jovi.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.1; XBM images broken - worked in 24.3
Date: Thu, 16 Mar 2017 14:39:06 -0500

[Message part 1 (text/plain, inline)]

; Please find attached screen shots of this Emacs 24.3 vs. Emacs 25.1 bug:
(progn (insert-image (create-image "/* Example at
https://en.Wikipedia.org/wiki/X_BitMap */
#define test_width 16
#define test_height 7
static char test_bits[] = { 0x13, 0x00, 0x15, 0x00, 0x93, 0xcd, 0x55,
0xa5, 0x93, 0xc5, 0x00, 0x80,0x00, 0x60 };"
				   (quote xbm) t))
       (insert emacs-version))
; MacOS 10.11.6 Emacs 24.3 displays a proper [Blarg] glyph.
; MacOS 10.11.6 Emacs 25.1 displays a scrambled [alBgra] glyph with the
"a" split in two, i.e., [Blarg] glyph with each octet LSB-MSB reversed.

It seems in XBM image bool-vector data

    (A) octets are sometimes little-endian and sometimes big-endian
    (B) rows are sometimes padded to octet boundaries and sometimes not

It would be helpful to standardize -- or at least document -- such
per-version per-platform differences
as XBM is the only programmatically accessible graphical element natively
supported in vanilla Emacs!

		Peace
			--Devon

P.S. Here's an example of the opposite problem:
bash$ curl -L -O http://csail.mit.edu/~devon/emacs/bitmap.el    # this
workaround works in 25.1 but is scrambled in 24.3
bash$ Emacs -Q -eval '(setq debug-on-error t)' -l cl -l bitmap.el -f blarg
-eval '(insert emacs-version)'    # 24.3
bash$ /Applications/Emacs.app/Contents/MacOS/Emacs -Q -eval '(setq
debug-on-error t)' -l cl -l bitmap.el -f blarg -eval '(insert
emacs-version)'    # 25.1

P.P.S. If you're looking at the XBM image code, the XBM parser should hack
c++ comments.
(insert-image (create-image "// Example at
https://en.Wikipedia.org/wiki/X_BitMap
#define test_width 16
#define test_height 7
static char test_bits[] = { 0x13, 0x00, 0x15, 0x00, 0x93, 0xcd, 0x55,
0xa5, 0x93, 0xc5, 0x00, 0x80,0x00, 0x60 };"
			    (quote xbm) t))
; Emacs 24.3 and 25.1 both display a blank space with the expected display
property but no bitmap.
; Perhaps more annoying feature than bug.

[XBM Emacs-24.3 Screen Shot 2017-03-16 at 1.06.27 PM.png (image/png, attachment)]

[XBM Emacs-25.1 Screen Shot 2017-03-16 at 1.08.17 PM.png (image/png, attachment)]

Message #8 received at 26133 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: "Devon Sean McCullough" <Emacs-Hacker2016 <at> jovi.net>
Cc: 26133 <at> debbugs.gnu.org
Subject: Re: bug#26133: 25.1; XBM images broken - worked in 24.3
Date: Fri, 26 Jul 2019 13:47:00 +0200

"Devon Sean McCullough" <Emacs-Hacker2016 <at> jovi.net> writes:

> ; Please find attached screen shots of this Emacs 24.3 vs. Emacs 25.1 bug:
> (progn (insert-image (create-image "/* Example at
> https://en.Wikipedia.org/wiki/X_BitMap */
> #define test_width 16
> #define test_height 7
> static char test_bits[] = { 0x13, 0x00, 0x15, 0x00, 0x93, 0xcd, 0x55,
> 0xa5, 0x93, 0xc5, 0x00, 0x80,0x00, 0x60 };"
> 				   (quote xbm) t))
>        (insert emacs-version))
> ; MacOS 10.11.6 Emacs 24.3 displays a proper [Blarg] glyph.
> ; MacOS 10.11.6 Emacs 25.1 displays a scrambled [alBgra] glyph with the
> "a" split in two, i.e., [Blarg] glyph with each octet LSB-MSB reversed.
>
> It seems in XBM image bool-vector data
>
>     (A) octets are sometimes little-endian and sometimes big-endian
>     (B) rows are sometimes padded to octet boundaries and sometimes not
>
> It would be helpful to standardize -- or at least document -- such
> per-version per-platform differences
> as XBM is the only programmatically accessible graphical element natively
> supported in vanilla Emacs!

I'm unable to reproduce this bug with Emacs 27 on GNU/Linux -- are you
still seeing this problem?  The image code has gotten a lot of work in
the years after you reported this problem...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #11 received at 26133 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Devon Sean McCullough <Emacs-Hacker2016 <at> jovi.net>, 26133 <at> debbugs.gnu.org
Subject: Re: bug#26133: 25.1; XBM images broken - worked in 24.3
Date: Sat, 27 Jul 2019 11:19:25 +0100

On Fri, Jul 26, 2019 at 01:47:00PM +0200, Lars Ingebrigtsen wrote:
> "Devon Sean McCullough" <Emacs-Hacker2016 <at> jovi.net> writes:
> 
> > ; Please find attached screen shots of this Emacs 24.3 vs. Emacs 25.1 bug:
> > (progn (insert-image (create-image "/* Example at
> > https://en.Wikipedia.org/wiki/X_BitMap */
> > #define test_width 16
> > #define test_height 7
> > static char test_bits[] = { 0x13, 0x00, 0x15, 0x00, 0x93, 0xcd, 0x55,
> > 0xa5, 0x93, 0xc5, 0x00, 0x80,0x00, 0x60 };"
> > 				   (quote xbm) t))
> >        (insert emacs-version))
> > ; MacOS 10.11.6 Emacs 24.3 displays a proper [Blarg] glyph.
> > ; MacOS 10.11.6 Emacs 25.1 displays a scrambled [alBgra] glyph with the
> > "a" split in two, i.e., [Blarg] glyph with each octet LSB-MSB reversed.
> >
> > It seems in XBM image bool-vector data
> >
> >     (A) octets are sometimes little-endian and sometimes big-endian
> >     (B) rows are sometimes padded to octet boundaries and sometimes not
> >
> > It would be helpful to standardize -- or at least document -- such
> > per-version per-platform differences
> > as XBM is the only programmatically accessible graphical element natively
> > supported in vanilla Emacs!
> 
> I'm unable to reproduce this bug with Emacs 27 on GNU/Linux -- are you
> still seeing this problem?  The image code has gotten a lot of work in
> the years after you reported this problem...

I can reproduce it on the NS port. I can reverse the way it draws the
pixels, but that then reverses the fringe bitmaps too, so I’m not sure
what the difference is here.

-- 
Alan Third

Message #14 received at 26133 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Devon Sean McCullough <Emacs-Hacker2016 <at> jovi.net>, 26133 <at> debbugs.gnu.org
Subject: Re: bug#26133: 25.1; XBM images broken - worked in 24.3
Date: Fri, 6 Dec 2019 12:56:05 +0000

On Sat, Jul 27, 2019 at 11:19:25AM +0100, Alan Third wrote:
> On Fri, Jul 26, 2019 at 01:47:00PM +0200, Lars Ingebrigtsen wrote:
> > "Devon Sean McCullough" <Emacs-Hacker2016 <at> jovi.net> writes:
> > 
> > > ; Please find attached screen shots of this Emacs 24.3 vs. Emacs 25.1 bug:
> > > (progn (insert-image (create-image "/* Example at
> > > https://en.Wikipedia.org/wiki/X_BitMap */
> > > #define test_width 16
> > > #define test_height 7
> > > static char test_bits[] = { 0x13, 0x00, 0x15, 0x00, 0x93, 0xcd, 0x55,
> > > 0xa5, 0x93, 0xc5, 0x00, 0x80,0x00, 0x60 };"
> > > 				   (quote xbm) t))
> > >        (insert emacs-version))
> > > ; MacOS 10.11.6 Emacs 24.3 displays a proper [Blarg] glyph.
> > > ; MacOS 10.11.6 Emacs 25.1 displays a scrambled [alBgra] glyph with the
> > > "a" split in two, i.e., [Blarg] glyph with each octet LSB-MSB reversed.
> > >
> > > It seems in XBM image bool-vector data
> > >
> > >     (A) octets are sometimes little-endian and sometimes big-endian
> > >     (B) rows are sometimes padded to octet boundaries and sometimes not
> > >
> > > It would be helpful to standardize -- or at least document -- such
> > > per-version per-platform differences
> > > as XBM is the only programmatically accessible graphical element natively
> > > supported in vanilla Emacs!
> > 
> > I'm unable to reproduce this bug with Emacs 27 on GNU/Linux -- are you
> > still seeing this problem?  The image code has gotten a lot of work in
> > the years after you reported this problem...
> 
> I can reproduce it on the NS port. I can reverse the way it draws the
> pixels, but that then reverses the fringe bitmaps too, so I’m not sure
> what the difference is here.

So, on NS we’re using the same mechanism to load XBM files and the
fringe bitmaps, but despite using similar data formats they appear to
have swapped bit orders.

-initFromXBM:width:height:fg:bg: actually handles our fringe bitmaps
and not XBM files. I suppose the right thing to do here is create a
new method for loading fringe bitmaps.

From https://github.com/syntelos/xbm/blob/master/README.txt

    Within the XBM pixel block (byte) the order of pixels (bits) is
    inverted from raster order.  The most significant or left bit is
    the right pixel.
    
But looking at the definitions in fringe.c I can see they’re defined
in reverse. For example:

/* Bar cursor bitmap.  A vertical bar; max 13 pixels high.  */
/*
  xx......
  xx......
  xx......
  xx......
  xx......
  xx......
  xx......
  xx......
  xx......
  xx......
  xx......
  xx......
  xx......
*/
static unsigned short vertical_bar_bits[] = {
   0xc0, 0xc0, 0xc0, 0xc0, 0xc0, 0xc0, 0xc0, 0xc0, 0xc0, 0xc0, 0xc0, 0xc0, 0xc0};

-- 
Alan Third

Message #17 received at 26133 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Devon Sean McCullough <Emacs-Hacker2016 <at> jovi.net>
Cc: 26133 <at> debbugs.gnu.org
Subject: [PATCH] Fix XBM files on NS (bug#26133)
Date: Fri, 6 Dec 2019 17:01:56 +0000

Reinstate some of the functionality removed in commit
67a878f78f879ce534232408c34dd11f42dd802b.

* src/nsimage.m (ns_image_from_XBM): Use new reverseBytes argument.
([EmacsImage initFromXBM:width:height:fg:bg:reverseBytes:]): Add
ability to reverse the contents of each byte for use with XBMs, while
still working with fringe bitmaps.
* src/nsterm.h
([EmacsImage initFromXBM:width:height:fg:bg:reverseBytes:]): Modified
function definition.
* src/nsterm.m (ns_draw_fringe_bitmap): Use new reverseBytes argument.
---
 src/nsimage.m | 17 +++++++++++++----
 src/nsterm.h  |  3 ++-
 src/nsterm.m  |  3 ++-
 3 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/src/nsimage.m b/src/nsimage.m
index e1408c77f5..25d3b2299c 100644
--- a/src/nsimage.m
+++ b/src/nsimage.m
@@ -52,7 +52,7 @@ Updated by Christian Limpach (chris <at> nice.ch)
   NSTRACE ("ns_image_from_XBM");
   return [[EmacsImage alloc] initFromXBM: (unsigned char *) bits
                                    width: width height: height
-                                      fg: fg bg: bg];
+                                      fg: fg bg: bg reverseBytes: YES];
 }
 
 void *
@@ -228,7 +228,8 @@ - (void)dealloc
 /* Create image from monochrome bitmap. If both FG and BG are 0
    (black), set the background to white and make it transparent.  */
 - (instancetype)initFromXBM: (unsigned char *)bits width: (int)w height: (int)h
-           fg: (unsigned long)fg bg: (unsigned long)bg
+                         fg: (unsigned long)fg bg: (unsigned long)bg
+               reverseBytes: (BOOL)reverse
 {
   unsigned char *planes[5];
   unsigned char bg_alpha = 0xff;
@@ -252,6 +253,8 @@ - (instancetype)initFromXBM: (unsigned char *)bits width: (int)w height: (int)h
 
   {
     /* Pull bits out to set the (bytewise) alpha mask.  */
+    unsigned char swt[16] = {0, 8, 4, 12, 2, 10, 6, 14,
+                             1, 9, 5, 13, 3, 11, 7, 15};
     int i, j, k;
     unsigned char *s = bits;
     unsigned char *rr = planes[0];
@@ -266,11 +269,18 @@ - (instancetype)initFromXBM: (unsigned char *)bits width: (int)w height: (int)h
     unsigned char bgb = bg & 0xff;
     unsigned char c;
 
-    int idx = 0;
     for (j = 0; j < h; ++j)
       for (i = 0; i < w; )
         {
           c = *s++;
+
+          /* XBM files have the bits in reverse order within each byte
+             as compared to our fringe bitmaps.  This function deals
+             with both so has to be able to handle the bytes in either
+             order.  */
+          if (reverse)
+            c = swt[c >> 4] | (swt[c & 0xf] << 4);
+
           for (k = 0; i < w && k < 8; ++k, ++i)
             {
               if (c & 0x80)
@@ -287,7 +297,6 @@ - (instancetype)initFromXBM: (unsigned char *)bits width: (int)w height: (int)h
                   *bb++ = bgb;
                   *alpha++ = bg_alpha;
                 }
-              idx++;
               c <<= 1;
             }
         }
diff --git a/src/nsterm.h b/src/nsterm.h
index 9773eb3e66..3803009afa 100644
--- a/src/nsterm.h
+++ b/src/nsterm.h
@@ -639,7 +639,8 @@ #define NSTRACE_UNSILENCE()
 + (instancetype)allocInitFromFile: (Lisp_Object)file;
 - (void)dealloc;
 - (instancetype)initFromXBM: (unsigned char *)bits width: (int)w height: (int)h
-                  fg: (unsigned long)fg bg: (unsigned long)bg;
+                         fg: (unsigned long)fg bg: (unsigned long)bg
+               reverseBytes: (BOOL)reverse;
 - (instancetype)setXBMColor: (NSColor *)color;
 - (instancetype)initForXPMWithDepth: (int)depth width: (int)width height: (int)height;
 - (void)setPixmapData;
diff --git a/src/nsterm.m b/src/nsterm.m
index 71234ac783..369b1173d8 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -3106,7 +3106,8 @@ so some key presses (TAB) are swallowed by the system.  */
                 cbits[i] = bits[i];
               img = [[EmacsImage alloc] initFromXBM: cbits width: 8
                                              height: full_height
-                                                 fg: 0 bg: 0];
+                                                 fg: 0 bg: 0
+                                       reverseBytes: NO];
               bimgs[p->which - 1] = img;
               xfree (cbits);
             }
-- 
2.21.0


-- 
Alan Third

Message #22 received at 26133-done <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Devon Sean McCullough <Emacs-Hacker2016 <at> jovi.net>
Cc: 26133-done <at> debbugs.gnu.org
Subject: Re: bug#26133: [PATCH] Fix XBM files on NS (bug#26133)
Date: Tue, 10 Dec 2019 20:56:27 +0000

On Fri, Dec 06, 2019 at 05:01:56PM +0000, Alan Third wrote:
> Reinstate some of the functionality removed in commit
> 67a878f78f879ce534232408c34dd11f42dd802b.
> 
> * src/nsimage.m (ns_image_from_XBM): Use new reverseBytes argument.
> ([EmacsImage initFromXBM:width:height:fg:bg:reverseBytes:]): Add
> ability to reverse the contents of each byte for use with XBMs, while
> still working with fringe bitmaps.
> * src/nsterm.h
> ([EmacsImage initFromXBM:width:height:fg:bg:reverseBytes:]): Modified
> function definition.
> * src/nsterm.m (ns_draw_fringe_bitmap): Use new reverseBytes argument.

I’ve pushed this to master.
-- 
Alan Third

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.