unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: David Ponce <da_vid@orange.fr>
To: 40978@debbugs.gnu.org
Subject: bug#40978: 28.0.50; create-image and find-image consistency
Date: Thu, 30 Apr 2020 10:53:26 +0200	[thread overview]
Message-ID: <f11cfb02-5275-ec4a-e413-bc926ccb7d3f@orange.fr> (raw)
In-Reply-To: <3a9c34ae-8052-d634-78c3-e83a2f6b6624@orange.fr>

Hello dear Emacs developers,

I am using Emacs latest master, and noticed some inconsistency between the
results of function `create-image' and `find-image'.

Here is an example:

(create-image "[EMACS-DIR]/etc/images/icons/hicolor/scalable/apps/emacs.svg")
==> (image :type svg :file "[EMACS-DIR]/etc/images/icons/hicolor/scalable/apps/emacs.svg" :scale 1.2)

(find-image '((:type svg :file "[EMACS-DIR]/etc/images/icons/hicolor/scalable/apps/emacs.svg")))
==> (image :type svg :file "[EMACS-DIR]/etc/images/icons/hicolor/scalable/apps/emacs.svg")

Contrary to images returned by `create-image', which are automatically scaled
when no :scale property is provided, those returned by `find-image' are not.

I propose the below patch to have `find-image' use `create-image' in order to get
consistent results from both functions. Another advantage of using `create-image' is
that it is no longer necessary to provide the :type property to `find-image'.
The correct type is determined by `create-image' with the proper default scaling.

Here is the result of previous example with patched `find-image':

(find-image '((:file "[EMACS-DIR]/etc/images/icons/hicolor/scalable/apps/emacs.svg")))
==> (image :type svg :file "[EMACS-DIR]/etc/images/icons/hicolor/scalable/apps/emacs.svg" :scale 1.2)

Please eventually consider this enhancement to Emacs, if it makes sense.

Thanks & regards,
David Ponce

diff --git a/installs/emacs/lisp/image.el b/emacs.d/image.el
index 4ea8594..046af95 100644
--- a/installs/emacs/lisp/image.el
+++ b/emacs.d/image.el
@@ -687,13 +687,15 @@ SPECS is a list of image specifications.
   
   Each image specification in SPECS is a property list.  The contents of
   a specification are image type dependent.  All specifications must at
-least contain the properties `:type TYPE' and either `:file FILE' or
-`:data DATA', where TYPE is a symbol specifying the image type,
-e.g. `xbm', FILE is the file to load the image from, and DATA is a
-string containing the actual image data.  The specification whose TYPE
-is supported, and FILE exists, is used to construct the image
-specification to be returned.  Return nil if no specification is
-satisfied.
+least contain the either the property `:file FILE' or `:data DATA',
+where FILE is the file to load the image from, and DATA is a string
+containing the actual image data.  If the property `:type TYPE' is
+omitted or nil, try to determine the image type from its first few
+bytes of image data.  If that doesn’t work, and the property `:file
+FILE' provide a file name, use its file extension as image type. If
+the property `:type TYPE' is provided, it must match the actual type
+determined for FILE or DATA by `create-image'.  Return nil if no
+specification is satisfied.
   
   The image is looked for in `image-load-path'.
   
@@ -703,16 +705,39 @@ Image files should not be larger than specified by `max-image-size'."
         (let* ((spec (car specs))
   	     (type (plist-get spec :type))
   	     (data (plist-get spec :data))
-	     (file (plist-get spec :file))
-	     found)
-	(when (image-type-available-p type)
-	  (cond ((stringp file)
-		 (if (setq found (image-search-load-path file))
-		     (setq image
-			   (cons 'image (plist-put (copy-sequence spec)
-						   :file found)))))
-		((not (null data))
-		 (setq image (cons 'image spec)))))
+	     (file (plist-get spec :file)))
+	(cond
+         ((stringp file)
+	  (when (setq file (image-search-load-path file))
+            ;; At this point, remove the :type and :file properties.
+            ;; `create-image' will set them depending on image file.
+            (setq image (cons 'image (copy-sequence spec)))
+            (setf (image-property image :type) nil)
+            (setf (image-property image :file) nil)
+            (and (setq image (ignore-errors
+                               (apply #'create-image file nil nil
+                                      (cdr image))))
+                 ;; Ensure, if a type has been provided, it is
+                 ;; consistent with the type returned by
+                 ;; `create-image'. If not, return nil.
+                 (not (null type))
+                 (not (eq type (image-property image :type)))
+                 (setq image nil))))
+	  ((not (null data))
+            ;; At this point, remove the :type and :data properties.
+            ;; `create-image' will set them depending on image data.
+           (setq image (cons 'image (copy-sequence spec)))
+           (setf (image-property image :type) nil)
+           (setf (image-property image :data) nil)
+	   (and (setq image (ignore-errors
+                              (apply #'create-image data nil t
+                                     (cdr image))))
+                ;; Ensure, if a type has been provided, it is
+                ;; consistent with the type returned by
+                ;; `create-image'. If not, return nil.
+                (not (null type))
+                (not (eq type (image-property image :type)))
+                (setq image nil))))
   	(setq specs (cdr specs))))
       image))
   

-------- Forwarded Message --------
From: Juri Linkov <juri@linkov.net>
To: David Ponce <da_vid@orange.fr>
Subject: Re: create-image and find-image consistency
Date: Mon, 20 Apr 2020 02:24:14 +0300

> I propose the below patch to have `find-image' use `create-image' in order to get
> consistent results from both functions. Another advantage of using `create-image' is
> that it is no longer necessary to provide the :type property to `find-image'.
> The correct type is determined by `create-image' with the proper default scaling.
>
> Here is the result of previous example with patched `find-image':
>
> (find-image '((:file "[EMACS-DIR]/etc/images/icons/hicolor/scalable/apps/emacs.svg")))
> ==> (image :type svg :file "[EMACS-DIR]/etc/images/icons/hicolor/scalable/apps/emacs.svg" :scale 1.2)
>
> Please eventually consider this enhancement to Emacs, if it makes sense.

I haven't tested it yet, but it makes sense indeed.

-------- Forwarded Message --------
From: Lars Ingebrigtsen <larsi@gnus.org>
To: David Ponce <da_vid@orange.fr>
Cc: emacs-devel@gnu.org
Subject: Re: create-image and find-image consistency
Date: Thu, 30 Apr 2020 07:08:54 +0200

David Ponce <da_vid@orange.fr> writes:

> I am using Emacs latest master, and noticed some inconsistency between the
> results of function `create-image' and `find-image'.
>
> Here is an example:
>
> (create-image "[EMACS-DIR]/etc/images/icons/hicolor/scalable/apps/emacs.svg")
> ==> (image :type svg :file "[EMACS-DIR]/etc/images/icons/hicolor/scalable/apps/emacs.svg" :scale 1.2)
>
> (find-image '((:type svg :file "[EMACS-DIR]/etc/images/icons/hicolor/scalable/apps/emacs.svg")))
> ==> (image :type svg :file "[EMACS-DIR]/etc/images/icons/hicolor/scalable/apps/emacs.svg")
>
> Contrary to images returned by `create-image', which are automatically scaled
> when no :scale property is provided, those returned by `find-image' are not.
>
> I propose the below patch to have `find-image' use `create-image' in
> order to get consistent results from both functions.

I think it conceptually makes sense to have find-image use create-image,
but looking at the code, and where find-image is used, it looks like the
use case it for creating toolbars and the like, where you want to pick
out one of the (built-in) image formats that Emacs supports...

Looking at your patch, you remove the (image-type-available-p type), and
instead rely on create-image not bugging out instead?  That feels like a
less obvious way to do the test (and more breakable; there may be other
reasons create-image fails).

And I'm not 100% sure that we want to auto-scale toolbars and the like.
I'm pretty sure we do, but perhaps somebody else has an opinion here?

Anyway, I think you should file this as a bug report so that the patch
doesn't get lost, because I think you're basically correct that the
find-image behaviour should be changed.

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






       reply	other threads:[~2020-04-30  8:53 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3a9c34ae-8052-d634-78c3-e83a2f6b6624@orange.fr>
2020-04-30  8:53 ` David Ponce [this message]
     [not found] ` <87ees536hl.fsf@gnus.org>
2020-04-30  9:24   ` bug#40978: create-image and find-image consistency David Ponce
2020-04-30 22:05     ` Lars Ingebrigtsen
2022-06-20  9:38       ` bug#40978: bug#47039: 27.1; find-image ignores image-scaling-factor Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f11cfb02-5275-ec4a-e413-bc926ccb7d3f@orange.fr \
    --to=da_vid@orange.fr \
    --cc=40978@debbugs.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).