unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#40978: 28.0.50; create-image and find-image consistency
       [not found] <3a9c34ae-8052-d634-78c3-e83a2f6b6624@orange.fr>
@ 2020-04-30  8:53 ` David Ponce
       [not found] ` <87ees536hl.fsf@gnus.org>
  1 sibling, 0 replies; 4+ messages in thread
From: David Ponce @ 2020-04-30  8:53 UTC (permalink / raw)
  To: 40978

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






^ permalink raw reply related	[flat|nested] 4+ messages in thread

* bug#40978: create-image and find-image consistency
       [not found] ` <87ees536hl.fsf@gnus.org>
@ 2020-04-30  9:24   ` David Ponce
  2020-04-30 22:05     ` Lars Ingebrigtsen
  0 siblings, 1 reply; 4+ messages in thread
From: David Ponce @ 2020-04-30  9:24 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: emacs-devel, 40978

On 30/04/2020 07:08, Lars Ingebrigtsen wrote:
> 
> 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.
> 

Hi Lars,

I created bug report #40978 as suggested.

My idea was to better separate the role of find-image from
create-image:

- create-image to actually make a new image based on given specs, and
   maybe some common options and device capabilities (for example, auto
   scaling based on screen resolution).
   
- find-image to lookup for an image in the file system or in raw data,
   but delegating to create-image the actual creation of the image.

Currently find-image & create-image can return a different image from
the same spec, which is not consistent. My patch proposes to fix such
potential inconsistencies.
When you don't need auto-scaling for example, you can pass :scale 1.0
to find-image, like you would have done with create-image :-)
IMHO, auto-scaling is particularly useful with graphics elements like
tool bars, tab bars, and widgets ;-)

Thanks for taking into account this proposal!





^ permalink raw reply	[flat|nested] 4+ messages in thread

* bug#40978: create-image and find-image consistency
  2020-04-30  9:24   ` bug#40978: " 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
  0 siblings, 1 reply; 4+ messages in thread
From: Lars Ingebrigtsen @ 2020-04-30 22:05 UTC (permalink / raw)
  To: David Ponce; +Cc: 40978

David Ponce <da_vid@orange.fr> writes:

> My idea was to better separate the role of find-image from
> create-image:
>
> - create-image to actually make a new image based on given specs, and
>   maybe some common options and device capabilities (for example, auto
>   scaling based on screen resolution).
>   - find-image to lookup for an image in the file system or in raw
>    data,
>   but delegating to create-image the actual creation of the image.

Yes, I think that's a good idea.

> IMHO, auto-scaling is particularly useful with graphics elements like
> tool bars, tab bars, and widgets ;-)

Yeah, that's true.  I think.

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





^ permalink raw reply	[flat|nested] 4+ messages in thread

* bug#40978: bug#47039: 27.1; find-image ignores image-scaling-factor
  2020-04-30 22:05     ` Lars Ingebrigtsen
@ 2022-06-20  9:38       ` Lars Ingebrigtsen
  0 siblings, 0 replies; 4+ messages in thread
From: Lars Ingebrigtsen @ 2022-06-20  9:38 UTC (permalink / raw)
  To: David Ponce; +Cc: 47039, 40978

Lars Ingebrigtsen <larsi@gnus.org> writes:

>> IMHO, auto-scaling is particularly useful with graphics elements like
>> tool bars, tab bars, and widgets ;-)
>
> Yeah, that's true.  I think.

I was finally reminded that I should try David's patch after looking at
a --with-x-toolkit=lucid build where all the toolbar icons were
minuscule on this 4K 14" laptop screen.

And it does indeed fix these issues, as well as the tiny "Gnu" logo in
the Gnus Group mode line, etc.

So I've now pushed it to Emacs 29.

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





^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2022-06-20  9:38 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <3a9c34ae-8052-d634-78c3-e83a2f6b6624@orange.fr>
2020-04-30  8:53 ` bug#40978: 28.0.50; create-image and find-image consistency David Ponce
     [not found] ` <87ees536hl.fsf@gnus.org>
2020-04-30  9:24   ` bug#40978: " 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

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).