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

[GNU bug Tracking System]

Your message dated Tue, 10 Dec 2019 20:56:27 +0000
with message-id <address@hidden>
and subject line Re: bug#26133: [PATCH] Fix XBM files on NS (bug#26133)
has caused the debbugs.gnu.org bug report #26133,
regarding 25.1; XBM images broken - worked in 24.3
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden.)


-- 
26133: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=26133
GNU Bug Tracking System
Contact address@hidden with problems

--- Begin Message --- Subject: 25.1; XBM images broken - worked in 24.3 Date: Thu, 16 Mar 2017 14:39:06 -0500 User-agent: SquirrelMail/1.5.2 [SVN]

; 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
Description: PNG image

XBM Emacs-25.1 Screen Shot 2017-03-16 at 1.08.17 PM.png
Description: PNG image

--- End Message ---

> --- Begin Message ---
>
>
>
> 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
>
>
> --- End Message ---