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

From: [email-masked] (GNU bug Tracking System)
Date: Tue, 10 Dec 2019 20:57:02 +0000

Your bug report

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

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
26133: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=26133
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#26133: [PATCH] Fix XBM files on NS (bug#26133)
From: Alan Third <[email-masked]>
To: Devon Sean McCullough <[email-masked]>
Cc: [email-masked]
Date: Tue, 10 Dec 2019 20:56:27 +0000
List-Id: <debbugs-submit.debbugs.gnu.org>

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

Subject: 25.1; XBM images broken - worked in 24.3
From: "Devon Sean McCullough" <[email-masked]>
To: [email-masked]
Date: Thu, 16 Mar 2017 14:39:06 -0500
List-Id: <debbugs-submit.debbugs.gnu.org>

; 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.