From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Lars Ingebrigtsen Newsgroups: gmane.emacs.bugs Subject: bug#25583: 26.0.50; :width/:max-width and vice versa in images Date: Tue, 31 Jan 2017 17:02:16 +0100 Message-ID: References: <83efzjw7cz.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1485879474 13166 195.159.176.226 (31 Jan 2017 16:17:54 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 31 Jan 2017 16:17:54 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Cc: 25583@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jan 31 17:17:49 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cYb7q-000390-Gh for geb-bug-gnu-emacs@m.gmane.org; Tue, 31 Jan 2017 17:17:46 +0100 Original-Received: from localhost ([::1]:39291 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cYb7v-0004gp-PA for geb-bug-gnu-emacs@m.gmane.org; Tue, 31 Jan 2017 11:17:51 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40944) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cYatg-0000AM-6j for bug-gnu-emacs@gnu.org; Tue, 31 Jan 2017 11:03:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cYata-0004rE-FP for bug-gnu-emacs@gnu.org; Tue, 31 Jan 2017 11:03:08 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:54198) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cYata-0004r9-Cl for bug-gnu-emacs@gnu.org; Tue, 31 Jan 2017 11:03:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cYata-0006qR-5y for bug-gnu-emacs@gnu.org; Tue, 31 Jan 2017 11:03:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 31 Jan 2017 16:03:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25583 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 25583-submit@debbugs.gnu.org id=B25583.148587855226249 (code B ref 25583); Tue, 31 Jan 2017 16:03:02 +0000 Original-Received: (at 25583) by debbugs.gnu.org; 31 Jan 2017 16:02:32 +0000 Original-Received: from localhost ([127.0.0.1]:52393 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cYat5-0006pI-IB for submit@debbugs.gnu.org; Tue, 31 Jan 2017 11:02:32 -0500 Original-Received: from hermes.netfonds.no ([80.91.224.195]:38199) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cYat0-0006p3-AO for 25583@debbugs.gnu.org; Tue, 31 Jan 2017 11:02:29 -0500 Original-Received: from cm-84.215.1.64.getinternet.no ([84.215.1.64] helo=stories) by hermes.netfonds.no with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cYasq-0005kv-JG; Tue, 31 Jan 2017 17:02:25 +0100 Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAKlBMVEWB/v4AAOAAAOMIMfsL e/wFBvo88/0HrP0AAO0IFvsBAN0LUfoAAOgAAP9eAcMbAAABpklEQVQ4jX3SMWuDQBQH8Df1Q5Qu 3ULJdukQHBWkZHaQInQIly8guSFTAgWHZgo3HCFDnIpkM5Dh6JBNAp2CoIPfpXfR04sxfYN4/rh7 /6dCJKsfJEFTc/kI5CX5TAutsnkFYZAzxuiQMsqYp8FueY45H3EzNkeDH7FFwdMyd1zHocylrtxR fD2WkHjFdWUlhEnRhpcLBMsbON2Do4RtcguLCwTt50VxgX47k8wrodcBIi9EidMBzxK6dhwj2AZd MI/gdu4yFoQdaWUs2N2M9y9kp3twhKiGVIuXzSH6VQvGGkgXDeQIsWJTd2+OWhlChg2EFaSIc4TQ poZvdZLBRcWqT1DDmVuWALUlg55qIUAQeq1OBvUO1/sSaLWuwbBsX7Svh1GQ723iu3EzIqgx1gKQ Dl51807IzDA1UKHsKZntzU0HYDzej2gDVQ82wBhPfR7TFhjGVMjkQKzhNQx8LIsQK/Z0cA53wLUJ /gDAY2KZeqqcCgCAhwnxTU+DtLAa2Ohz5Pb0Atj233RwnEM3MHbAJRA/1mHF7RqqjwvyZ09RXAJg X8EfRu0wFrq2O7cAAAAASUVORK5CYII= In-Reply-To: <83efzjw7cz.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 31 Jan 2017 17:56:44 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:128833 Archived-At: Eli Zaretskii writes: >> From: Lars Ingebrigtsen >> Date: Mon, 30 Jan 2017 22:42:44 +0100 >>=20 >> As far as I can tell, it isn't documented what should happen if you have >> both :width and :max-height set in image specification, or vice versa. > > I see this in the ELisp manual: > > =E2=80=98:width WIDTH, :height HEIGHT=E2=80=99 > The =E2=80=98:width=E2=80=99 and =E2=80=98:height=E2=80=99 keyword= s are used for scaling the image. > If only one of them is specified, the other one will be calculated > so as to preserve the aspect ratio. If both are specified, aspect > ratio may not be preserved. > > =E2=80=98:max-width MAX-WIDTH, :max-height MAX-HEIGHT=E2=80=99 > The =E2=80=98:max-width=E2=80=99 and =E2=80=98:max-height=E2=80=99= keywords are used for scaling if > the size of the image of the image exceeds these values. If > =E2=80=98:width=E2=80=99 is set it will have precedence over =E2= =80=98max-width=E2=80=99, and if > =E2=80=98:height=E2=80=99 is set it will have precedence over =E2= =80=98max-height=E2=80=99, but you > can otherwise mix these keywords as you wish. =E2=80=98:max-width= =E2=80=99 and > =E2=80=98:max-height=E2=80=99 will always preserve the aspect rati= o. > > So I think the behavior that should be expected is well documented. No, the case where :width and :max-height are both specified is not documented. Only :width and :max-width (and :height and :max-height). >> Here's the use case: I want to display images that are mostly square, >> but can sometimes be rectangular, and I want them to be displayed in max >> width if possible, even if they are smaller than that width originally, >> but not exceeding a certain height. >>=20 >> So I thought ":width 400 :max-height 500" should do the trick, but >> apparently compute_image_size just ignores :max-height in this case. >>=20 >> I think :max-height should "win" here... (That is, the width will end up >> smaller than 400 if making it 400 wide will make height exceed 500.) > > Sorry, I don't understand how :max-height could (or should) affect the > width. The aspect ratio is preserved in all these transforms, so changing (or restricting) the width changes the height and vice versa. > And where do you see in the code that :max-height is ignored > if :width is given? My reading of the code is that that :max-height > is ignored only if :height is given. You end up here: if (desired_height =3D=3D -1) { value =3D image_spec_value (spec, QCmax_height, NULL); if (NATNUMP (value)) { int max_height =3D min (XFASTINT (value), INT_MAX); if (max_height < height) desired_height =3D max_height; } } height is not larger than max_height here, so desired_height is not set. if (desired_width !=3D -1 && desired_height =3D=3D -1) /* w known, calculate h. */ desired_height =3D scale_image_size (desired_width, width, height); And then this is done, and :max-height is ignored. --=20 (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no