* bug#26133: 25.1; XBM images broken - worked in 24.3
@ 2017-03-16 19:39 Devon Sean McCullough
2019-07-26 11:47 ` Lars Ingebrigtsen
0 siblings, 1 reply; 6+ messages in thread
From: Devon Sean McCullough @ 2017-03-16 19:39 UTC (permalink / raw)
To: 26133
[-- Attachment #1: Type: text/plain, Size: 1973 bytes --]
; 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.
[-- Attachment #2: XBM Emacs-24.3 Screen Shot 2017-03-16 at 1.06.27 PM.png --]
[-- Type: image/png, Size: 79643 bytes --]
[-- Attachment #3: XBM Emacs-25.1 Screen Shot 2017-03-16 at 1.08.17 PM.png --]
[-- Type: image/png, Size: 76634 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#26133: 25.1; XBM images broken - worked in 24.3
2017-03-16 19:39 bug#26133: 25.1; XBM images broken - worked in 24.3 Devon Sean McCullough
@ 2019-07-26 11:47 ` Lars Ingebrigtsen
2019-07-27 10:19 ` Alan Third
0 siblings, 1 reply; 6+ messages in thread
From: Lars Ingebrigtsen @ 2019-07-26 11:47 UTC (permalink / raw)
To: Devon Sean McCullough; +Cc: 26133
"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...
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#26133: 25.1; XBM images broken - worked in 24.3
2019-07-26 11:47 ` Lars Ingebrigtsen
@ 2019-07-27 10:19 ` Alan Third
2019-12-06 12:56 ` Alan Third
0 siblings, 1 reply; 6+ messages in thread
From: Alan Third @ 2019-07-27 10:19 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: Devon Sean McCullough, 26133
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.
--
Alan Third
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#26133: 25.1; XBM images broken - worked in 24.3
2019-07-27 10:19 ` Alan Third
@ 2019-12-06 12:56 ` Alan Third
2019-12-06 17:01 ` bug#26133: [PATCH] Fix XBM files on NS (bug#26133) Alan Third
0 siblings, 1 reply; 6+ messages in thread
From: Alan Third @ 2019-12-06 12:56 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: Devon Sean McCullough, 26133
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#26133: [PATCH] Fix XBM files on NS (bug#26133)
2019-12-06 12:56 ` Alan Third
@ 2019-12-06 17:01 ` Alan Third
2019-12-10 20:56 ` Alan Third
0 siblings, 1 reply; 6+ messages in thread
From: Alan Third @ 2019-12-06 17:01 UTC (permalink / raw)
To: Devon Sean McCullough; +Cc: 26133
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@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
^ permalink raw reply related [flat|nested] 6+ messages in thread
* bug#26133: [PATCH] Fix XBM files on NS (bug#26133)
2019-12-06 17:01 ` bug#26133: [PATCH] Fix XBM files on NS (bug#26133) Alan Third
@ 2019-12-10 20:56 ` Alan Third
0 siblings, 0 replies; 6+ messages in thread
From: Alan Third @ 2019-12-10 20:56 UTC (permalink / raw)
To: Devon Sean McCullough; +Cc: 26133-done
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-12-10 20:56 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-16 19:39 bug#26133: 25.1; XBM images broken - worked in 24.3 Devon Sean McCullough
2019-07-26 11:47 ` Lars Ingebrigtsen
2019-07-27 10:19 ` Alan Third
2019-12-06 12:56 ` Alan Third
2019-12-06 17:01 ` bug#26133: [PATCH] Fix XBM files on NS (bug#26133) Alan Third
2019-12-10 20:56 ` Alan Third
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).