GNU bug report logs - #39735
27.0.60; bugs about XBM images

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 39735 in the body.
You can then email your comments to 39735 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: ynyaaa <at> gmail.com
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.60; bugs about XBM images
Date: Sat, 22 Feb 2020 23:09:28 +0900

(1)XBM image with :file property can not be scaled with :width or :height.

   (let ((f (locate-file "gnus/preview.xbm" image-load-path)))
     (image-size (create-image f 'xbm nil :width 128)))
   error-> Invalid image specification

(2)XBM image with :data property has no way to scale with different
   aspect ratio.

   :width and :height image properties are interpreted as adittional
   properties on :data property.

(3)XBM :data string can not be used as raw bit pattern
   if it looks like contents of XBM file,

   (let ((data "\
   #define b_width 1
   #define b_height 1
   static char b[] = {0x01}
   "))
     (image-size
      (create-image data 'xbm t :width 8 :height (length data))))
   error-> Invalid image specification


In GNU Emacs 27.0.60 (build 1, x86_64-w64-mingw32)
 of 2019-12-29 built on CIRROCUMULUS
Repository revision: 21c3020fcec0a32122d2680a391864a75393031b
Repository branch: emacs-27
Windowing system distributor 'Microsoft Corp.', version 10.0.18363
System Description: Microsoft Windows 10 Pro (v10.0.1909.18363.657)

Recent messages:

Configured using:
 'configure --without-dbus --host=x86_64-w64-mingw32
 --without-compress-install -C 'CFLAGS=-O2 -static -g3''

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY W32NOTIFY ACL GNUTLS LIBXML2
HARFBUZZ ZLIB TOOLKIT_SCROLL_BARS MODULES THREADS PDUMPER LCMS2 GMP

Important settings:
  value of $LANG: JPN
  locale-coding-system: cp932

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
format-spec rfc822 mml mml-sec password-cache epa derived epg epg-config
gnus-util rmail rmail-loaddefs text-property-search time-date subr-x seq
byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils term/bobcat help-fns
radix-tree cl-print debug backtrace help-mode easymenu find-func
cl-loaddefs cl-lib japan-util tooltip eldoc electric uniquify ediff-hook
vc-hooks lisp-float-type mwheel dos-w32 ls-lisp disp-table term/w32-win
w32-win w32-vars term/common-win tool-bar dnd fontset image regexp-opt
fringe tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads w32notify w32 lcms2 multi-tty make-network-process
emacs)

Memory information:
((conses 16 54885 8078)
 (symbols 48 6473 1)
 (strings 32 18401 2028)
 (string-bytes 1 572553)
 (vectors 16 12203)
 (vector-slots 8 221466 10946)
 (floats 8 23 64)
 (intervals 56 388 0)
 (buffers 1000 13))

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: ynyaaa <at> gmail.com
Cc: 39735 <at> debbugs.gnu.org, eliz <at> gnu.org
Subject: Re: bug#39735: 27.0.60; bugs about XBM images
Date: Sun, 02 Aug 2020 10:38:53 +0200

ynyaaa <at> gmail.com writes:

> (1)XBM image with :file property can not be scaled with :width or :height.
>
>    (let ((f (locate-file "gnus/preview.xbm" image-load-path)))
>      (image-size (create-image f 'xbm nil :width 128)))
>    error-> Invalid image specification
>
> (2)XBM image with :data property has no way to scale with different
>    aspect ratio.
>
>    :width and :height image properties are interpreted as adittional
>    properties on :data property.

I think these are probably somewhat connected: :width and :height have a
special meaning for some XBM images:

   If the specification is for a bitmap loaded from memory it must
   contain `:width WIDTH', `:height HEIGHT', and `:data DATA', where
   WIDTH and HEIGHT are integers > 0.  DATA may be:

So the Emacs XBM functions uses :width and :height so specify the
dimensions of the data, not how big the image is going to turn out to be
displayed.  It's unfortunate that we're using the same properties for
two different things.

I'm not sure how to fix that.  XBM images aren't used much, I would
imagine...

Eli, would it make sense to do a backwards-incompatible change here and
rename the XBM parameters to :xbm-width and :xbm-height?

> (3)XBM :data string can not be used as raw bit pattern
>    if it looks like contents of XBM file,
>
>    (let ((data "\
>    #define b_width 1
>    #define b_height 1
>    static char b[] = {0x01}
>    "))
>      (image-size
>       (create-image data 'xbm t :width 8 :height (length data))))
>    error-> Invalid image specification

This is more of the same: It's the overloading of :width/:height, which
means that we don't allow those parameters for data like that:

  DATA may be:

   1. a string large enough to hold the bitmap data, i.e. it must
   have a size >= (WIDTH + 7) / 8 * HEIGHT

   2. a bool-vector of size >= WIDTH * HEIGHT

   3. a vector of strings or bool-vectors, one for each line of the
   bitmap.

   4. a string containing an in-memory XBM file.  WIDTH and HEIGHT
   may not be specified in this case because they are defined in the
   XBM file.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 39735 <at> debbugs.gnu.org, ynyaaa <at> gmail.com
Subject: Re: bug#39735: 27.0.60; bugs about XBM images
Date: Sun, 02 Aug 2020 17:19:21 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: 39735 <at> debbugs.gnu.org, eliz <at> gnu.org
> Date: Sun, 02 Aug 2020 10:38:53 +0200
> 
> Eli, would it make sense to do a backwards-incompatible change here and
> rename the XBM parameters to :xbm-width and :xbm-height?

Given the relative unimportance of XBM, that doesn't sound like a good
idea.

Can't we instead add new parameters, so that the change is
backwards-compatible?

Thanks.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39735 <at> debbugs.gnu.org, ynyaaa <at> gmail.com
Subject: Re: bug#39735: 27.0.60; bugs about XBM images
Date: Sun, 02 Aug 2020 16:36:03 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Eli, would it make sense to do a backwards-incompatible change here and
>> rename the XBM parameters to :xbm-width and :xbm-height?
>
> Given the relative unimportance of XBM, that doesn't sound like a good
> idea.
>
> Can't we instead add new parameters, so that the change is
> backwards-compatible?

Do you mean adding :display-width and :display-height to the XBM
handlers (that would work like :width/:height in all the other image
handlers)?  I guess that would work, but it's rather awkward -- the code
that calls `create-image' would then have to check whether the image is
XBM or not to know what parameters to use...

Since XBM is so obscure, we could just document that XBM just doesn't
support scaling, and that it's an error to give those parameters (unless
you really mean XBM dimensions).  But again, that also means that
somebody that writes a loop of `create-images' must be careful to not
call it on XBM images...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 39735 <at> debbugs.gnu.org, ynyaaa <at> gmail.com
Subject: Re: bug#39735: 27.0.60; bugs about XBM images
Date: Sun, 02 Aug 2020 19:26:12 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: ynyaaa <at> gmail.com,  39735 <at> debbugs.gnu.org
> Date: Sun, 02 Aug 2020 16:36:03 +0200
> 
> Since XBM is so obscure, we could just document that XBM just doesn't
> support scaling, and that it's an error to give those parameters (unless
> you really mean XBM dimensions).

That'd be fine with me, yes.

> But again, that also means that somebody that writes a loop of
> `create-images' must be careful to not call it on XBM images...

Yes, but given its obscurity, maybe this is not so bad?

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39735 <at> debbugs.gnu.org, ynyaaa <at> gmail.com
Subject: Re: bug#39735: 27.0.60; bugs about XBM images
Date: Sun, 02 Aug 2020 19:04:27 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Since XBM is so obscure, we could just document that XBM just doesn't
>> support scaling, and that it's an error to give those parameters (unless
>> you really mean XBM dimensions).
>
> That'd be fine with me, yes.

I've now done this, and I'm closing this bug report.

>> But again, that also means that somebody that writes a loop of
>> `create-images' must be careful to not call it on XBM images...
>
> Yes, but given its obscurity, maybe this is not so bad?

Yeah, I think the likelihood of finding XBM images in the wild is pretty
minuscule.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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