bug#26133: 25.1; XBM images broken - worked in 24.3

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

bug#26133: 25.1; XBM images broken - worked in 24.3

Devon Sean McCullough-9
; 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 (106K) Download Attachment
XBM Emacs-25.1 Screen Shot 2017-03-16 at 1.08.17 PM.png (102K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

bug#26133: 25.1; XBM images broken - worked in 24.3

Lars Ingebrigtsen
"Devon Sean McCullough" <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

bug#26133: 25.1; XBM images broken - worked in 24.3

Alan Third
On Fri, Jul 26, 2019 at 01:47:00PM +0200, Lars Ingebrigtsen wrote:

> "Devon Sean McCullough" <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

bug#26133: 25.1; XBM images broken - worked in 24.3

Alan Third
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" <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

bug#26133: [PATCH] Fix XBM files on NS (bug#26133)

Alan Third
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 ([hidden email])
   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



Reply | Threaded
Open this post in threaded view
|

bug#26133: [PATCH] Fix XBM files on NS (bug#26133)

Alan Third
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