From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 30 16:43:15 2017 Received: (at submit) by debbugs.gnu.org; 30 Jan 2017 21:43:15 +0000 Received: from localhost ([127.0.0.1]:51419 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cYJjG-0007Jt-MC for submit@debbugs.gnu.org; Mon, 30 Jan 2017 16:43:14 -0500 Received: from eggs.gnu.org ([208.118.235.92]:48852) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cYJjF-0007JS-Ir for submit@debbugs.gnu.org; Mon, 30 Jan 2017 16:43:14 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cYJj4-0000fW-Ty for submit@debbugs.gnu.org; Mon, 30 Jan 2017 16:43:08 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:60774) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cYJj4-0000fS-Qz for submit@debbugs.gnu.org; Mon, 30 Jan 2017 16:43:02 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39822) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cYJj3-0000P0-1L for bug-gnu-emacs@gnu.org; Mon, 30 Jan 2017 16:43:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cYJiz-0000eq-RZ for bug-gnu-emacs@gnu.org; Mon, 30 Jan 2017 16:43:01 -0500 Received: from hermes.netfonds.no ([80.91.224.195]:35836) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cYJiz-0000cd-I2 for bug-gnu-emacs@gnu.org; Mon, 30 Jan 2017 16:42:57 -0500 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 1cYJim-00067p-Nq for bug-gnu-emacs@gnu.org; Mon, 30 Jan 2017 22:42:46 +0100 From: Lars Ingebrigtsen To: bug-gnu-emacs@gnu.org Subject: 26.0.50; :width/:max-width and vice versa in images Date: Mon, 30 Jan 2017 22:42:44 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) 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. Currently :width wins in this situation, but I think that's probably just a coincidence. (I mean, I implemented this, and I can't remember considering that case...) 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. So I thought ":width 400 :max-height 500" should do the trick, but apparently compute_image_size just ignores :max-height in this case. 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.) I'll implement this sometimes soon unless somebody objects or I think of a reason why not... In GNU Emacs 26.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.14.5) of 2017-01-30 built on stories Repository revision: ab96c8509736a7ed622916ad2749ff356e520d02 Windowing system distributor 'The X.Org Foundation', version 11.0.11604000 System Description: Debian GNU/Linux 8.6 (jessie) Recent messages: Mark saved where search started Grep finished (matches found) Mark saved where search started Annotating... Redisplaying annotation...done (Spanned from 4337.9 to 29.9 days old) Annotating... done Mark set Annotating... Redisplaying annotation...done (Spanned from 4337.9 to 29.9 days old) Annotating... done Configured features: XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 Important settings: value of $LC_ALL: C value of $LANG: en_US.UTF-8 locale-coding-system: nil Major mode: Texinfo Minor modes in effect: shell-dirtrack-mode: t diff-auto-refine-mode: t global-whitespace-mode: t tooltip-mode: t global-eldoc-mode: t electric-indent-mode: t mouse-wheel-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 auto-fill-function: do-auto-fill Load-path shadows: /home/larsi/src/cddb.el/expect hides /home/larsi/lisp/expect /home/larsi/src/cddb.el/captitle hides /home/larsi/lisp/captitle /home/larsi/src/clock.el/clock hides /home/larsi/lisp/clock ~/pgnus/contrib/vcard hides /home/larsi/lisp/vcard /home/larsi/src/pvr.el/pvr hides /home/larsi/lisp/pvr ~/lisp/zenirc-2.112/src/zenirc-example hides /home/larsi/lisp/zenirc-example ~/pgnus/contrib/compface hides /home/larsi/src/emacs/trunk/lisp/image/compface Features: (shadow ecomplete emacsbug sendmail log-view pcvs-util vc-annotate vc vc-dispatcher texinfo shell pcomplete thingatpt grep compile comint ring misearch multi-isearch cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs vc-git diff-mode map pp flow-fill eww copyright vc-cvs gnus-html help-fns radix-tree url-queue url-cache sort gnus-cite smiley ansi-color shr-color color mm-archive gnus-async gnus-dup qp gnus-ml gmane spam-gmane dns mm-url disp-table gnus-fun gnus-mdrtn gnus-topic pop3 nndoc nnmbox utf-7 nnml nnfolder network-stream starttls nnir spam-report spam spam-stat gnus-uu yenc gnus-delay gnus-draft gnus-agent gnus-srvr gnus-score score-mode nnvirtual nntp gnus-cache gnus-msg gnus-art mm-uu mml2015 mm-view mml-smime smime dig gnus-sum nndraft nnmh gnus-group gnus-undo gnus-start gnus-cloud nnimap utf7 netrc nnoo parse-time gnus-spec gnus-win nnmail gnus-int gnus-range mail-source message format-spec rfc822 mml mml-sec epa epg mailabbrev gmm-utils mailheader gnus nnheader gnus-util rmail rmail-loaddefs mail-utils whitespace movie mkv shr svg imdb dom pvr debug debbugs-gnu easy-mmode derived debbugs soap-client mm-decode mm-bodies mm-encode url-http tls gnutls url-auth mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr url-gw nsm puny url url-proxy url-privacy url-expand url-methods url-history url-cookie url-domsuf url-util mailcap warnings rng-xsd rng-dt rng-util xsd-regexp xml ido flyspell ispell benchmark w3m browse-url doc-view subr-x dired dired-loaddefs image-mode timezone w3m-hist w3m-fb w3m-ems wid-edit w3m-ccl ccl w3m-favicon w3m-image w3m-proc w3m-util add-log mail-extr jka-compr cl finder-inf package epg-config url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs password-cache url-vars seq byte-opt gv bytecomp byte-compile cl-extra help-mode easymenu cconv cl-loaddefs pcase cl-lib time-date mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core term/tty-colors frame 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 case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer 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 dbusbind inotify dynamic-setting system-font-setting font-render-setting move-toolbar gtk x-toolkit x multi-tty make-network-process emacs) Memory information: ((conses 16 822387 78630) (symbols 48 173923 1) (miscs 40 177 574) (strings 32 241877 19050) (string-bytes 1 13817599) (vectors 16 38683) (vector-slots 8 954704 24999) (floats 8 6994 296) (intervals 56 22928 15416) (buffers 976 50) (heap 1024 113146 198091)) -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 31 10:57:21 2017 Received: (at 25583) by debbugs.gnu.org; 31 Jan 2017 15:57:21 +0000 Received: from localhost ([127.0.0.1]:52389 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cYao4-0006gn-Up for submit@debbugs.gnu.org; Tue, 31 Jan 2017 10:57:21 -0500 Received: from eggs.gnu.org ([208.118.235.92]:48772) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cYao3-0006ga-4a for 25583@debbugs.gnu.org; Tue, 31 Jan 2017 10:57:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cYant-00036v-6V for 25583@debbugs.gnu.org; Tue, 31 Jan 2017 10:57:14 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:49139) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cYant-00036q-4I; Tue, 31 Jan 2017 10:57:09 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4917 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cYanr-00045t-UF; Tue, 31 Jan 2017 10:57:08 -0500 Date: Tue, 31 Jan 2017 17:56:44 +0200 Message-Id: <83efzjw7cz.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-reply-to: (message from Lars Ingebrigtsen on Mon, 30 Jan 2017 22:42:44 +0100) Subject: Re: bug#25583: 26.0.50; :width/:max-width and vice versa in images References: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 25583 Cc: 25583@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: Lars Ingebrigtsen > Date: Mon, 30 Jan 2017 22:42:44 +0100 > > 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: ‘:width WIDTH, :height HEIGHT’ The ‘:width’ and ‘:height’ keywords 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. ‘:max-width MAX-WIDTH, :max-height MAX-HEIGHT’ The ‘:max-width’ and ‘:max-height’ keywords are used for scaling if the size of the image of the image exceeds these values. If ‘:width’ is set it will have precedence over ‘max-width’, and if ‘:height’ is set it will have precedence over ‘max-height’, but you can otherwise mix these keywords as you wish. ‘:max-width’ and ‘:max-height’ will always preserve the aspect ratio. So I think the behavior that should be expected is well documented. > 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. > > So I thought ":width 400 :max-height 500" should do the trick, but > apparently compute_image_size just ignores :max-height in this case. > > 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. 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. From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 31 11:02:32 2017 Received: (at 25583) by debbugs.gnu.org; 31 Jan 2017 16:02:32 +0000 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 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 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 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#25583: 26.0.50; :width/:max-width and vice versa in images References: <83efzjw7cz.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAKlBMVEWB/v4AAOAAAOMIMfsL e/wFBvo88/0HrP0AAO0IFvsBAN0LUfoAAOgAAP9eAcMbAAABpklEQVQ4jX3SMWuDQBQH8Df1Q5Qu 3ULJdukQHBWkZHaQInQIly8guSFTAgWHZgo3HCFDnIpkM5Dh6JBNAp2CoIPfpXfR04sxfYN4/rh7 /6dCJKsfJEFTc/kI5CX5TAutsnkFYZAzxuiQMsqYp8FueY45H3EzNkeDH7FFwdMyd1zHocylrtxR fD2WkHjFdWUlhEnRhpcLBMsbON2Do4RtcguLCwTt50VxgX47k8wrodcBIi9EidMBzxK6dhwj2AZd MI/gdu4yFoQdaWUs2N2M9y9kp3twhKiGVIuXzSH6VQvGGkgXDeQIsWJTd2+OWhlChg2EFaSIc4TQ poZvdZLBRcWqT1DDmVuWALUlg55qIUAQeq1OBvUO1/sSaLWuwbBsX7Svh1GQ723iu3EzIqgx1gKQ Dl51807IzDA1UKHsKZntzU0HYDzej2gDVQ82wBhPfR7TFhjGVMjkQKzhNQx8LIsQK/Z0cA53wLUJ /gDAY2KZeqqcCgCAhwnxTU+DtLAa2Ohz5Pb0Atj233RwnEM3MHbAJRA/1mHF7RqqjwvyZ09RXAJg X8EfRu0wFrq2O7cAAAAASUVORK5CYII= Date: Tue, 31 Jan 2017 17:02:16 +0100 In-Reply-To: <83efzjw7cz.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 31 Jan 2017 17:56:44 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 25583 Cc: 25583@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) 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 From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 14 20:45:59 2017 Received: (at control) by debbugs.gnu.org; 15 Jul 2017 00:46:00 +0000 Received: from localhost ([127.0.0.1]:39416 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dWBDb-0007FQ-Oy for submit@debbugs.gnu.org; Fri, 14 Jul 2017 20:45:59 -0400 Received: from hermes.netfonds.no ([80.91.224.195]:46212) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dWBDZ-0007FG-No for control@debbugs.gnu.org; Fri, 14 Jul 2017 20:45:58 -0400 Received: from cm-84.209.243.26.getinternet.no ([84.209.243.26] helo=mouse) by hermes.netfonds.no with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dWBDS-0001tp-St for control@debbugs.gnu.org; Sat, 15 Jul 2017 02:45:52 +0200 Date: Sat, 15 Jul 2017 02:45:50 +0200 Message-Id: <87d192h6ip.fsf@mouse> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #25583 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) tags 25583 fixed close 25583 From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 14 20:48:21 2017 Received: (at 25583) by debbugs.gnu.org; 15 Jul 2017 00:48:21 +0000 Received: from localhost ([127.0.0.1]:39422 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dWBFq-0007Je-3e for submit@debbugs.gnu.org; Fri, 14 Jul 2017 20:48:21 -0400 Received: from hermes.netfonds.no ([80.91.224.195]:46229) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dWBFl-0007JR-Fd for 25583@debbugs.gnu.org; Fri, 14 Jul 2017 20:48:17 -0400 Received: from cm-84.209.243.26.getinternet.no ([84.209.243.26] helo=mouse) by hermes.netfonds.no with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dWBFg-0006TG-P6 for 25583@debbugs.gnu.org; Sat, 15 Jul 2017 02:48:12 +0200 From: Lars Ingebrigtsen To: 25583@debbugs.gnu.org Subject: Re: bug#25583: 26.0.50; :width/:max-width and vice versa in images References: <83efzjw7cz.fsf@gnu.org> Date: Sat, 15 Jul 2017 02:48:08 +0200 In-Reply-To: (Lars Ingebrigtsen's message of "Tue, 31 Jan 2017 17:02:16 +0100") Message-ID: <878tjqh6ev.fsf@mouse> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 25583 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Lars Ingebrigtsen writes: > And then this is done, and :max-height is ignored. I've now implemented this, and in doing so, simplified compute_image_size quite a bit. :-/ I'm glad I had written all those image sizing tests in advance, otherwise I would be tempted to say there must be something wrong somewhere, because the new code is less... er... convoluted. I think. But it even seems to work in practice, which is something of a miracle. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Tue Aug 19 12:50:27 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sat, 12 Aug 2017 11:24:05 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator