From: Alan Third <alan@idiocy.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: [PATCH v2] Add native image scaling (bug#33587)
Date: Fri, 4 Jan 2019 19:09:14 +0000 [thread overview]
Message-ID: <20190104190914.GA61852@breton.holly.idiocy.org> (raw)
In-Reply-To: <837efk335e.fsf@gnu.org>
On Fri, Jan 04, 2019 at 04:31:41PM +0200, Eli Zaretskii wrote:
> > Date: Wed, 2 Jan 2019 21:12:41 +0000
> > From: Alan Third <alan@idiocy.org>
> > Cc: emacs-devel@gnu.org
> >
> > I think this is the final version.
>
> Thanks. A few minor gotchas.
I regret touching this now. ;)
Do these look OK?
modified doc/lispref/display.texi
@@ -5120,33 +5120,35 @@ Image Descriptors
@item :max-width @var{max-width}, :max-height @var{max-height}
The @code{:max-width} and @code{:max-height} keywords are used for
-scaling if the size of the image of the image exceeds these values.
-If @code{:width} is set it will have precedence over @code{max-width},
-and if @code{:height} is set it will have precedence over
+scaling if the size of the image exceeds these values. If
+@code{:width} is set, it will have precedence over @code{max-width},
+and if @code{:height} is set, it will have precedence over
@code{max-height}, but you can otherwise mix these keywords as you
-wish. @code{:max-width} and @code{:max-height} will always preserve
-the aspect ratio.
-
-If both @code{:width} and @code{:max-height} has been set (but
-@code{:height} has not been set), then @code{:max-height} will have
-precedence. The same is the case for the opposite combination: The
-``max'' keyword has precedence. That is, if you have a 200x100 image
-and specify that @code{:width} should be 400 and @code{:max-height}
-should be 150, you'll end up with an image that is 300x150: Preserving
-the aspect ratio and not exceeding the ``max'' setting. This
-combination of parameters is a useful way of saying ``display this
-image as large as possible, but no larger than the available display
-area''.
+wish.
+
+If both @code{:max-width} and @code{:height} are specified, but
+@code{:width} is not, preserving the aspect ratio might require that
+width exceeds @code{:max-width}. If this happens, scaling will use a
+smaller value for the height so as to preserve the aspect ratio while
+not exceeding @code{:max-width}. Similarly when both
+@code{:max-height} and @code{:width} are specified, but @code{:height}
+is not. For example, if you have a 200x100 image and specify that
+@code{:width} should be 400 and @code{:max-height} should be 150,
+you'll end up with an image that is 300x150: Preserving the aspect
+ratio and not exceeding the ``max'' setting. This combination of
+parameters is a useful way of saying ``display this image as large as
+possible, but no larger than the available display area''.
@item :scale @var{scale}
This should be a number, where values higher than 1 means to increase
-the size, and lower means to decrease the size. For instance, a value
-of 0.25 will make the image a quarter size of what it originally was.
-If the scaling makes the image larger than specified by
-@code{:max-width} or @code{:max-height}, the resulting size will not
-exceed those two values. If both @code{:scale} and
-@code{:height}/@code{:width} are specified, the height/width will be
-adjusted by the specified scaling factor.
+the size, and lower means to decrease the size, by multiplying both
+the width and height. For instance, a value of 0.25 will make the
+image a quarter size of what it originally was. If the scaling makes
+the image larger than specified by @code{:max-width} or
+@code{:max-height}, the resulting size will not exceed those two
+values. If both @code{:scale} and @code{:height}/@code{:width} are
+specified, the height/width will be adjusted by the specified scaling
+factor.
@item :index @var{frame}
@xref{Multi-Frame Images}.
> > +@code{:height} has not been set), then @code{:max-height} will have
> > +precedence. The same is the case for the opposite combination: The
> > +``max'' keyword has precedence.
>
> This confused me until I've read the example. having read the
> example, I suggest to describe this differently:
>
> If both @code{:max-width} and @code{:height} are specified, but
> @code{:width} is not, preserving the aspect ratio might require that
> width exceeds @code{:max-width}. If this happens, scaling will use a
> smaller value for the height so as to preserve the aspect ratio while
> not exceeding @code{:max-width}. Similarly when both
> @code{:max-height} and @code{:width} are specified, but @code{:height}
> is not.
I’ve put that in. FWIW I don’t understand why this behaviour was
chosen, it seems to me that max-width and max-height should be exactly
that, the max width and height. I don’t understand why they can be
over‐ridden.
Too late to do anything about it now, I suppose.
> > +@defun image-scaling-p &optional frame
> > +This function returns @code{t} if @var{frame} supports image scaling.
> > +@var{frame} @code{nil} or omitted means to use the selected frame
> > +(@pxref{Input Focus}).
> > +
> > +If image scaling is not supported, @code{:width}, @code{:height},
> > +@code{:scale}, @code{:max-width} and @code{:max-height} will only be
> > +usable through ImageMagick, if available (@pxref{ImageMagick Images}).
> > +@end defun
>
> Shouldn't image-scaling-p return non-nil if ImageMagick is available?
> I think that would allow a simpler Lisp code.
The difficulty is in knowing whether you need to set :type to
ImageMagick or not.
What we really don’t want to do is just return t for both native and
ImageMagick, as you then have no way of deciding to go with native
over ImageMagick, because you can’t tell the difference between
native‐and‐ImageMagick, or just ImageMagick.
I did think that I could return t if native is available, and if it’s
not, but ImageMagick is, return 'imagemagick.
Or perhaps return a list of scaling capable backends
'(native imagemagick)
There are other ways of detecting ImageMagick, but no other way of
detecting native scaling, other than just trying it I suppose.
(Another option would be to automatically fall‐back to ImageMagick if
required, but given that we’re doing this because people are concerned
about ImageMagick’s security record, I doubt making it’s use automatic
would appeal.)
--
Alan Third
next prev parent reply other threads:[~2019-01-04 19:09 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-02 1:33 Linking to ImageMagick by default Glenn Morris
2018-12-02 18:15 ` Paul Eggert
2018-12-05 13:30 ` Lars Ingebrigtsen
2018-12-05 15:28 ` Stefan Monnier
2018-12-06 11:06 ` Lars Ingebrigtsen
2018-12-05 17:24 ` Glenn Morris
2018-12-05 17:27 ` Lars Ingebrigtsen
2018-12-05 18:27 ` Daniel Pittman
2018-12-05 18:38 ` Lars Ingebrigtsen
2018-12-05 19:31 ` joakim
2018-12-05 22:39 ` Alan Third
2018-12-08 18:38 ` Alan Third
2018-12-08 21:24 ` Paul Eggert
2018-12-10 22:09 ` Alan Third
2018-12-19 16:03 ` Alan Third
2018-12-19 16:36 ` Eli Zaretskii
2018-12-19 16:45 ` Joseph Garvin
2018-12-27 15:06 ` Alan Third
2018-12-27 13:11 ` Alan Third
2018-12-27 16:05 ` Eli Zaretskii
2018-12-27 20:37 ` Juri Linkov
2018-12-28 8:12 ` Eli Zaretskii
2018-12-28 21:21 ` Alan Third
2018-12-29 6:56 ` Eli Zaretskii
2018-12-29 21:31 ` Juri Linkov
2018-12-30 12:47 ` Alan Third
2019-01-01 21:47 ` [PATCH] Add native image scaling Alan Third
2019-01-02 16:11 ` Eli Zaretskii
2019-01-02 21:12 ` [PATCH v2] Add native image scaling (bug#33587) Alan Third
2019-01-04 14:31 ` Eli Zaretskii
2019-01-04 19:09 ` Alan Third [this message]
2019-01-04 20:21 ` Eli Zaretskii
2019-01-04 22:45 ` Alan Third
2019-01-10 19:42 ` Alan Third
2019-01-10 19:50 ` Eli Zaretskii
2019-01-10 23:40 ` Paul Eggert
2019-01-06 16:26 ` Eli Zaretskii
2019-01-05 21:30 ` Track mouse drags over an image (was: Add native image scaling) Roland Winkler
2019-01-08 18:20 ` Track mouse drags over an image Stefan Monnier
2019-01-11 4:55 ` Roland Winkler
2019-01-11 16:23 ` Stefan Monnier
2018-12-09 11:34 ` Linking to ImageMagick by default Elias Mårtenson
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=20190104190914.GA61852@breton.holly.idiocy.org \
--to=alan@idiocy.org \
--cc=eliz@gnu.org \
--cc=emacs-devel@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).