GNU bug report logs - #28824
26.0.90; display of pbm images broken?

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 28824 in the body.
You can then email your comments to 28824 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Roland Winkler" <winkler <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 26.0.90; display of pbm images broken?
Date: Fri, 13 Oct 2017 21:10:50 -0500

start emacs -Q
evaluate (arg FILE-OR-DATA of create-image should point to a pbm image)

(defun foo ()
  (interactive)
  (insert-image (create-image "~/foo.pbm")))

M-x foo

This displays the image with emacs 25, but not with emacs 26.0.90:
there is just a small bounding box (smaller than the image) where
the image should be displayed.  It is my understanding that pbm
images do not depend on external libraries.  (Anyway, I built emacs
25 on the same machine without problems.)


In GNU Emacs 26.0.90 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.18.9)
 of 2017-10-13 built on regnitz
Windowing system distributor 'The X.Org Foundation', version 11.0.11804000
System Description:	Ubuntu 16.04.3 LTS

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS
NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT
ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 LCMS2

Important settings:
  value of $LC_COLLATE: C
  value of $LANG: en_US.utf8
  value of $XMODIFIERS: 
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  display-time-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Message #8 received at 28824 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Roland Winkler" <winkler <at> gnu.org>
Cc: 28824 <at> debbugs.gnu.org
Subject: Re: bug#28824: 26.0.90; display of pbm images broken?
Date: Sat, 14 Oct 2017 10:01:52 +0300

> Date: Fri, 13 Oct 2017 21:10:50 -0500
> From: "Roland Winkler" <winkler <at> gnu.org>
> 
> start emacs -Q
> evaluate (arg FILE-OR-DATA of create-image should point to a pbm image)
> 
> (defun foo ()
>   (interactive)
>   (insert-image (create-image "~/foo.pbm")))
> 
> M-x foo
> 
> This displays the image with emacs 25, but not with emacs 26.0.90:

Works for me in Emacs 26.0.90 on MS-Windows.  I used PBM images from
etc/images/ in the Emacs tree: does this fail to work for you with
those images as well?

> It is my understanding that pbm images do not depend on external
> libraries.

Yes, no external libraries should be needed.

Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andy Moreton <andrewjmoreton <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#28824: 26.0.90; display of pbm images broken?
Date: Sat, 14 Oct 2017 16:01:20 +0100

On Sat 14 Oct 2017, Eli Zaretskii wrote:

>> Date: Fri, 13 Oct 2017 21:10:50 -0500
>> From: "Roland Winkler" <winkler <at> gnu.org>
>> 
>> start emacs -Q
>> evaluate (arg FILE-OR-DATA of create-image should point to a pbm image)
>> 
>> (defun foo ()
>>   (interactive)
>>   (insert-image (create-image "~/foo.pbm")))
>> 
>> M-x foo
>> 
>> This displays the image with emacs 25, but not with emacs 26.0.90:
>
> Works for me in Emacs 26.0.90 on MS-Windows.  I used PBM images from
> etc/images/ in the Emacs tree: does this fail to work for you with
> those images as well?
>
>> It is my understanding that pbm images do not depend on external
>> libraries.
>
> Yes, no external libraries should be needed.

I see problems with some PBM files from etc/images with emacs 26.0.90 on
Windows. The ones that don't work appear to be those that contain a
Netpbm header, e.g. back-arrow.pbm close.pbm cut.pbm fwd-arrow.pbm
home.pbm

    AndyM

Message #14 received at 28824 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andy Moreton <andrewjmoreton <at> gmail.com>
Cc: 28824 <at> debbugs.gnu.org
Subject: Re: bug#28824: 26.0.90; display of pbm images broken?
Date: Sat, 14 Oct 2017 18:31:02 +0300

> From: Andy Moreton <andrewjmoreton <at> gmail.com>
> Date: Sat, 14 Oct 2017 16:01:20 +0100
> 
> I see problems with some PBM files from etc/images with emacs 26.0.90 on
> Windows. The ones that don't work appear to be those that contain a
> Netpbm header, e.g. back-arrow.pbm close.pbm cut.pbm fwd-arrow.pbm
> home.pbm

I see no problems with those images you mention as problematic.

Could it be a problem specific to 64-bit builds?

Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andy Moreton <andrewjmoreton <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#28824: 26.0.90; display of pbm images broken?
Date: Sat, 14 Oct 2017 19:16:11 +0100

On Sat 14 Oct 2017, Eli Zaretskii wrote:

>> From: Andy Moreton <andrewjmoreton <at> gmail.com>
>> Date: Sat, 14 Oct 2017 16:01:20 +0100
>> 
>> I see problems with some PBM files from etc/images with emacs 26.0.90 on
>> Windows. The ones that don't work appear to be those that contain a
>> Netpbm header, e.g. back-arrow.pbm close.pbm cut.pbm fwd-arrow.pbm
>> home.pbm
>
> I see no problems with those images you mention as problematic.
>
> Could it be a problem specific to 64-bit builds?

I've tried this in a 32bit MinGW build with the same results. It appears
to be a problem with the pbm entry in image-type-header-regexps, as
doing (setq image-type-header-regexps '(("\\`P[1-6]" . pbm))) results in
the problematic images displaying correctly.

    AndyM

Message #20 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andy Moreton <andrewjmoreton <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#28824: 26.0.90; display of pbm images broken?
Date: Sat, 14 Oct 2017 20:03:27 +0100

On Sat 14 Oct 2017, Andy Moreton wrote:

> On Sat 14 Oct 2017, Eli Zaretskii wrote:
>
>>> From: Andy Moreton <andrewjmoreton <at> gmail.com>
>>> Date: Sat, 14 Oct 2017 16:01:20 +0100
>>> 
>>> I see problems with some PBM files from etc/images with emacs 26.0.90 on
>>> Windows. The ones that don't work appear to be those that contain a
>>> Netpbm header, e.g. back-arrow.pbm close.pbm cut.pbm fwd-arrow.pbm
>>> home.pbm
>>
>> I see no problems with those images you mention as problematic.
>>
>> Could it be a problem specific to 64-bit builds?
>
> I've tried this in a 32bit MinGW build with the same results. It appears
> to be a problem with the pbm entry in image-type-header-regexps, as
> doing (setq image-type-header-regexps '(("\\`P[1-6]" . pbm))) results in
> the problematic images displaying correctly.
>
>     AndyM

The file format is described at http://netpbm.sourceforge.net/doc/pbm.html

Further testing with the images from etc/images in emacs 26 shows that
this patch appears to fix the problem:

diff --git a/lisp/image.el b/lisp/image.el
index 1d0776180b..32df508bc8 100644
--- a/lisp/image.el
+++ b/lisp/image.el
@@ -34,8 +34,8 @@ 'image-refresh
 (defconst image-type-header-regexps
   `(("\\`/[\t\n\r ]*\\*.*XPM.\\*/" . xpm)
     ("\\`P[1-6]\\(?:\
-\\(?:\\(?:#[^\r\n]*[\r\n]\\)?[[:space:]]\\)+\
-\\(?:\\(?:#[^\r\n]*[\r\n]\\)?[0-9]\\)+\
+\\(?:\\(?:#[^\r\n]*[\r\n]\\)*[[:space:]]\\)+\
+\\(?:\\(?:#[^\r\n]*[\r\n]\\)*[0-9]\\)+\
 \\)\\{2\\}" . pbm)
     ("\\`GIF8[79]a" . gif)
     ("\\`\x89PNG\r\n\x1a\n" . png)

Message #23 received at 28824 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andy Moreton <andrewjmoreton <at> gmail.com>
Cc: 28824 <at> debbugs.gnu.org
Subject: Re: bug#28824: 26.0.90; display of pbm images broken?
Date: Sat, 14 Oct 2017 22:14:07 +0300

> From: Andy Moreton <andrewjmoreton <at> gmail.com>
> Date: Sat, 14 Oct 2017 19:16:11 +0100
> 
> > I see no problems with those images you mention as problematic.
> >
> > Could it be a problem specific to 64-bit builds?
> 
> I've tried this in a 32bit MinGW build with the same results. It appears
> to be a problem with the pbm entry in image-type-header-regexps, as
> doing (setq image-type-header-regexps '(("\\`P[1-6]" . pbm))) results in
> the problematic images displaying correctly.

Then why does it work here with the unmodified PBM entry?

Message #26 received at 28824 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andy Moreton <andrewjmoreton <at> gmail.com>
Cc: 28824 <at> debbugs.gnu.org
Subject: Re: bug#28824: 26.0.90; display of pbm images broken?
Date: Sat, 14 Oct 2017 22:16:37 +0300

> From: Andy Moreton <andrewjmoreton <at> gmail.com>
> Date: Sat, 14 Oct 2017 20:03:27 +0100
> 
> Further testing with the images from etc/images in emacs 26 shows that
> this patch appears to fix the problem:
> 
> diff --git a/lisp/image.el b/lisp/image.el
> index 1d0776180b..32df508bc8 100644
> --- a/lisp/image.el
> +++ b/lisp/image.el
> @@ -34,8 +34,8 @@ 'image-refresh
>  (defconst image-type-header-regexps
>    `(("\\`/[\t\n\r ]*\\*.*XPM.\\*/" . xpm)
>      ("\\`P[1-6]\\(?:\
> -\\(?:\\(?:#[^\r\n]*[\r\n]\\)?[[:space:]]\\)+\
> -\\(?:\\(?:#[^\r\n]*[\r\n]\\)?[0-9]\\)+\
> +\\(?:\\(?:#[^\r\n]*[\r\n]\\)*[[:space:]]\\)+\
> +\\(?:\\(?:#[^\r\n]*[\r\n]\\)*[0-9]\\)+\
>  \\)\\{2\\}" . pbm)
>      ("\\`GIF8[79]a" . gif)
>      ("\\`\x89PNG\r\n\x1a\n" . png)

Thanks.  However, I'm puzzled by the fact that it works here without
any changes.

Can you step with a debugger through the code in image.c and tell what
exactly fails with the unmodified regexp?

Message #29 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andy Moreton <andrewjmoreton <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#28824: 26.0.90; display of pbm images broken?
Date: Sat, 14 Oct 2017 20:50:28 +0100

On Sat 14 Oct 2017, Eli Zaretskii wrote:

>> From: Andy Moreton <andrewjmoreton <at> gmail.com>
>> Date: Sat, 14 Oct 2017 20:03:27 +0100
>> 
>> Further testing with the images from etc/images in emacs 26 shows that
>> this patch appears to fix the problem:
>> 
>> diff --git a/lisp/image.el b/lisp/image.el
>> index 1d0776180b..32df508bc8 100644
>> --- a/lisp/image.el
>> +++ b/lisp/image.el
>> @@ -34,8 +34,8 @@ 'image-refresh
>>  (defconst image-type-header-regexps
>>    `(("\\`/[\t\n\r ]*\\*.*XPM.\\*/" . xpm)
>>      ("\\`P[1-6]\\(?:\
>> -\\(?:\\(?:#[^\r\n]*[\r\n]\\)?[[:space:]]\\)+\
>> -\\(?:\\(?:#[^\r\n]*[\r\n]\\)?[0-9]\\)+\
>> +\\(?:\\(?:#[^\r\n]*[\r\n]\\)*[[:space:]]\\)+\
>> +\\(?:\\(?:#[^\r\n]*[\r\n]\\)*[0-9]\\)+\
>>  \\)\\{2\\}" . pbm)
>>      ("\\`GIF8[79]a" . gif)
>>      ("\\`\x89PNG\r\n\x1a\n" . png)
>
> Thanks.  However, I'm puzzled by the fact that it works here without
> any changes.

Loading the troublesome images from "emacs -Q" also works in unmodified
emacs 26, so something in my init.el changes the behaviour.

> Can you step with a debugger through the code in image.c and tell what
> exactly fails with the unmodified regexp?

The problem is in image.el, where string-match-p in image-type-from-data
fails to match the regexp.

    AndyM

Message #32 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andy Moreton <andrewjmoreton <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#28824: 26.0.90; display of pbm images broken?
Date: Sat, 14 Oct 2017 21:15:41 +0100

On Sat 14 Oct 2017, Andy Moreton wrote:

> On Sat 14 Oct 2017, Eli Zaretskii wrote:
>> Thanks.  However, I'm puzzled by the fact that it works here without
>> any changes.
>
> Loading the troublesome images from "emacs -Q" also works in unmodified
> emacs 26, so something in my init.el changes the behaviour.

Further testing shows that my init.el has:
    (auto-image-file-mode 1)

Removing that line fixes the problem.

    AndyM

Message #35 received at 28824 <at> debbugs.gnu.org (full text, mbox):

From: "Roland Winkler" <winkler <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 28824 <at> debbugs.gnu.org
Subject: Re: bug#28824: 26.0.90; display of pbm images broken?
Date: Sat, 14 Oct 2017 16:52:22 -0500

[Message part 1 (text/plain, inline)]

On Sat Oct 14 2017 Eli Zaretskii wrote:
> Works for me in Emacs 26.0.90 on MS-Windows.  I used PBM images from
> etc/images/ in the Emacs tree: does this fail to work for you with
> those images as well?

I need to apologize: the bug is not with pbm images, but with ppm
images.  (The tool I use to create them calls them pbm, but it gives
ppm, pgm or pbm files depending on the content of the image.)

Then I realized there seem to be different versions of ppm files.
If I use the imagemagick tool `convert' to convert
etc/images/home.pbm to a ppm file it gives me the attached file
home-1bit.ppm.  This one still displays fine.  But if I export this
file with gimp, it gives me the attached file home-8bit.ppm.  This
file illustrates the bug I am talking about.

The file names refer to the output from the imagemagick tool
`identify':

$ identify home*
home-1bit.ppm PPM 24x24 24x24+0+0 1-bit sRGB 1.84KB 0.000u 0:00.000
home-8bit.ppm PPM 24x24 24x24+0+0 8-bit sRGB 1.78KB 0.000u 0:00.000

PS: Visiting these files display them fine (according to the
modeline, this uses imagemagick).  The problem occurs with
insert-image which appears to process these files differently

[home-1bit.ppm (application/octet-stream, attachment)]

[home-8bit.ppm (application/octet-stream, attachment)]

Message #38 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andy Moreton <andrewjmoreton <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#28824: 26.0.90; display of pbm images broken?
Date: Sun, 15 Oct 2017 18:42:27 +0100

On Sat 14 Oct 2017, Roland Winkler wrote:

> On Sat Oct 14 2017 Eli Zaretskii wrote:
>> Works for me in Emacs 26.0.90 on MS-Windows.  I used PBM images from
>> etc/images/ in the Emacs tree: does this fail to work for you with
>> those images as well?
>
> I need to apologize: the bug is not with pbm images, but with ppm
> images.  (The tool I use to create them calls them pbm, but it gives
> ppm, pgm or pbm files depending on the content of the image.)

No problem - it lead me to find a different bug that also needed fixing.

> $ identify home*
> home-1bit.ppm PPM 24x24 24x24+0+0 1-bit sRGB 1.84KB 0.000u 0:00.000
> home-8bit.ppm PPM 24x24 24x24+0+0 8-bit sRGB 1.78KB 0.000u 0:00.000
>
> PS: Visiting these files display them fine (according to the
> modeline, this uses imagemagick).  The problem occurs with
> insert-image which appears to process these files differently

Thanks for the example files. On Windows with a 64bit MSYS2 build of
emacs 26 I also see the problems loading the home-8bit.ppm file.

After some debugging, it appears that the problem was introduced in:

commit 3c2c50260e19deff2a0a054882eaea4049f25a2f
Author: Paul Eggert <eggert <at> cs.ucla.edu>
Date:   Thu Sep 29 20:09:37 2016 -0700

This changed the raster data from using "unsigned char" to "char" which
cannot be correct, as this is binary data. The trouble occurs when
reading an 0xff byte from the raster data, which gets sign extended to
r, g and b values (of type int) of -1.

The following patch works for me (including the earlier fix):

diff --git a/lisp/image.el b/lisp/image.el
index 1d0776180b..32df508bc8 100644
--- a/lisp/image.el
+++ b/lisp/image.el
@@ -34,8 +34,8 @@ 'image-refresh
 (defconst image-type-header-regexps
   `(("\\`/[\t\n\r ]*\\*.*XPM.\\*/" . xpm)
     ("\\`P[1-6]\\(?:\
-\\(?:\\(?:#[^\r\n]*[\r\n]\\)?[[:space:]]\\)+\
-\\(?:\\(?:#[^\r\n]*[\r\n]\\)?[0-9]\\)+\
+\\(?:\\(?:#[^\r\n]*[\r\n]\\)*[[:space:]]\\)+\
+\\(?:\\(?:#[^\r\n]*[\r\n]\\)*[0-9]\\)+\
 \\)\\{2\\}" . pbm)
     ("\\`GIF8[79]a" . gif)
     ("\\`\x89PNG\r\n\x1a\n" . png)
diff --git a/src/image.c b/src/image.c
index 3dac7086cb..1d81da2663 100644
--- a/src/image.c
+++ b/src/image.c
@@ -5523,23 +5523,23 @@ pbm_load (struct frame *f, struct image *img)
 
 	    if (type == PBM_GRAY && raw_p)
 	      {
-		r = g = b = *p++;
+		r = g = b = *(uint8_t *) p++;
 		if (max_color_idx > 255)
-		  r = g = b = r * 256 + *p++;
+		  r = g = b = r * 256 + *(uint8_t *) p++;
 	      }
 	    else if (type == PBM_GRAY)
 	      r = g = b = pbm_scan_number (&p, end);
 	    else if (raw_p)
 	      {
-		r = *p++;
+		r = *(uint8_t *) p++;
 		if (max_color_idx > 255)
-		  r = r * 256 + *p++;
-		g = *p++;
+		  r = r * 256 + *(uint8_t *) p++;
+		g = *(uint8_t *) p++;
 		if (max_color_idx > 255)
-		  g = g * 256 + *p++;
-		b = *p++;
+		  g = g * 256 + *(uint8_t *) p++;
+		b = *(uint8_t *) p++;
 		if (max_color_idx > 255)
-		  b = b * 256 + *p++;
+		  b = b * 256 + *(uint8_t *) p++;
 	      }
 	    else
 	      {

Eli can decide if reverting the previous "unsigned char" -> "char"
changes is a better fix.

    AndyM

Message #41 received at 28824 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andy Moreton <andrewjmoreton <at> gmail.com>, Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 28824 <at> debbugs.gnu.org
Subject: Re: bug#28824: 26.0.90; display of pbm images broken?
Date: Sun, 15 Oct 2017 21:49:12 +0300

> From: Andy Moreton <andrewjmoreton <at> gmail.com>
> Date: Sun, 15 Oct 2017 18:42:27 +0100
> 
> Eli can decide if reverting the previous "unsigned char" -> "char"
> changes is a better fix.

Looks like going back to unsigned should be cleaner, but I'd like to
hear what Paul thinks.

Message #46 received at 28824-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>, Andy Moreton <andrewjmoreton <at> gmail.com>
Cc: 28824-done <at> debbugs.gnu.org, Roland Winkler <winkler <at> gnu.org>
Subject: Re: bug#28824: 26.0.90; display of pbm images broken?
Date: Mon, 16 Oct 2017 01:30:07 -0700

[Message part 1 (text/plain, inline)]

Eli Zaretskii wrote:
>> From: Andy Moreton <andrewjmoreton <at> gmail.com>
>> Date: Sun, 15 Oct 2017 18:42:27 +0100
>>
>> Eli can decide if reverting the previous "unsigned char" -> "char"
>> changes is a better fix.
> 
> Looks like going back to unsigned should be cleaner, but I'd like to
> hear what Paul thinks.

Andy's fixes look good to me. Going back to unsigned would result in several 
pointer casts that are more dangerous than converting to unsigned. They can be 
further improved by encapsulating this stuff into a function, and I installed 
the attached (the second one is Andy's other fix, which I installed in his name).

I looked for related bugs in image.c (i.e., caused by my earlier patch) and did 
not find any.

[0001-Fix-regression-in-display-of-PPM-images.patch (text/x-patch, attachment)]

[0002-Don-t-reject-PBM-header-whitespace-unnecessarily.patch (text/x-patch, attachment)]

Message #49 received at 28824 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: andrewjmoreton <at> gmail.com, winkler <at> gnu.org, 28824 <at> debbugs.gnu.org
Subject: Re: bug#28824: 26.0.90; display of pbm images broken?
Date: Mon, 16 Oct 2017 18:11:58 +0300

> Cc: 28824-done <at> debbugs.gnu.org, Roland Winkler <winkler <at> gnu.org>
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Mon, 16 Oct 2017 01:30:07 -0700
> 
> > Looks like going back to unsigned should be cleaner, but I'd like to
> > hear what Paul thinks.
> 
> Andy's fixes look good to me. Going back to unsigned would result in several 
> pointer casts that are more dangerous than converting to unsigned. They can be 
> further improved by encapsulating this stuff into a function, and I installed 
> the attached (the second one is Andy's other fix, which I installed in his name).
> 
> I looked for related bugs in image.c (i.e., caused by my earlier patch) and did 
> not find any.

OK, thanks.

Message #52 received at 28824 <at> debbugs.gnu.org (full text, mbox):

From: "Roland Winkler" <winkler <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, andrewjmoreton <at> gmail.com,
 28824 <at> debbugs.gnu.org
Subject: Re: bug#28824: 26.0.90; display of pbm images broken?
Date: Mon, 16 Oct 2017 10:22:38 -0500

On Mon Oct 16 2017 Eli Zaretskii wrote:
> > Cc: 28824-done <at> debbugs.gnu.org, Roland Winkler <winkler <at> gnu.org>
> > From: Paul Eggert <eggert <at> cs.ucla.edu> Date: Mon, 16 Oct 2017
> > 01:30:07 -0700
> > 
> > I looked for related bugs in image.c (i.e., caused by my earlier
> > patch) and did not find any.
> 
> OK, thanks.

Thanks for the quick fix.  Proper handling of these images is so
important for my everyday usage of emacs I'll have to wait for the
next pretest to come out.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.