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" <Emacs-Hacker2016@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