From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: David Ponce Newsgroups: gmane.emacs.bugs Subject: bug#64908: 29.1; svg parse failure Date: Fri, 4 Aug 2023 18:23:11 +0200 Message-ID: References: <83o7jnwfd3.fsf@gnu.org> <835y5vw1ay.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5786"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.14.0 Cc: 64908@debbugs.gnu.org To: Eli Zaretskii , Alan Third Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Aug 04 18:24:25 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qRxbF-0001H1-Kg for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 04 Aug 2023 18:24:25 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qRxav-0001ZK-1x; Fri, 04 Aug 2023 12:24:05 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qRxat-0001UD-2I for bug-gnu-emacs@gnu.org; Fri, 04 Aug 2023 12:24:03 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qRxas-0001yn-Qd for bug-gnu-emacs@gnu.org; Fri, 04 Aug 2023 12:24:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qRxas-0004NR-AB for bug-gnu-emacs@gnu.org; Fri, 04 Aug 2023 12:24:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: David Ponce Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 04 Aug 2023 16:24:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64908 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: unreproducible Original-Received: via spool by 64908-submit@debbugs.gnu.org id=B64908.169116620016742 (code B ref 64908); Fri, 04 Aug 2023 16:24:02 +0000 Original-Received: (at 64908) by debbugs.gnu.org; 4 Aug 2023 16:23:20 +0000 Original-Received: from localhost ([127.0.0.1]:54637 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qRxaB-0004Lx-ID for submit@debbugs.gnu.org; Fri, 04 Aug 2023 12:23:20 -0400 Original-Received: from smtp-19.smtpout.orange.fr ([80.12.242.19]:64180 helo=smtp.smtpout.orange.fr) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qRxa8-0004Lk-5S for 64908@debbugs.gnu.org; Fri, 04 Aug 2023 12:23:18 -0400 Original-Received: from [192.168.1.15] ([2.7.71.181]) by smtp.orange.fr with ESMTPA id Rxa4q0gklP8tnRxa4qI4YB; Fri, 04 Aug 2023 18:23:14 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr; s=t20230301; t=1691166194; bh=VAA0vqqVyLbJZIY7FVloY9AnbTO1pmVL7gNMnt/bz1Q=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=L5JL+1unIaqfk9DRjZTYvMYjXDUIyGcdis+DhcjJcKPViDsbXxlbaNqkHgxvMKWbc xJl8cfWngKQW6mQpzCVwVIDPN1BeLdi2WoqtkQZ/kcWQEr64TJ/j4iDXkpaAgfDREU vGUfypo8+H4wQVOOrSWQSe8iWi+5jY8mv67zoeC4tVqeRt1dhhHZxrR+Vtp+9ZWTVv RB3KGqWL8dSCW1ob3PIa+BE4/rAi03CyvDzcJfvMn3v2cv6c98LfJQzIsfK9ho97Hq mwm/NPtZwXAVv53XvvFmI/yWEuffo43VlIm77KqxT1iCFz8QjQmWbPvOnTxXblfzpB XaRPV+xbB9lDA== X-ME-Helo: [192.168.1.15] X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI= X-ME-Date: Fri, 04 Aug 2023 18:23:14 +0200 X-ME-IP: 2.7.71.181 Content-Language: fr, en-US In-Reply-To: <835y5vw1ay.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:266693 Archived-At: On 04/08/2023 12:26, Eli Zaretskii wrote: >> Date: Fri, 4 Aug 2023 09:55:03 +0200 >> Cc: 64908@debbugs.gnu.org >> From: David Ponce >> >> On 04/08/2023 07:23, Eli Zaretskii wrote: >>>> Date: Thu, 3 Aug 2023 21:16:35 +0200 >>>> From: David Ponce >>>> >>>> In case it could help, using emacs from master (see details at end >>>> below), with librsvg2-2.56.0-1.fc38.x86_64 I can insert-image >>>> dir-src-open.svg and dir-public-open.svg in the *scratch-buffer* >>>> without issue (see Screenshot1). >>>> >>>> However, the same failed using librsvg2-2.56.3-1.fc38.x86_64 (see >>>> Screenshot2). >>>> >>>> I did test also with some KDE breeze icons. >>>> >>>> No issue with librsvg2-2.56.0-1.fc38.x86_64. >>>> >>>> With librsvg2-2.56.3-1.fc38.x86_64 some icons works, some not (see an >>>> example in Screenshot3): >>>> >>>> /usr/share/icons/breeze/actions/22/go-next.svg doesn't work: >>>> >> [...] >>>> >>>> /usr/share/icons/breeze/actions/22/go-next.svg works: >>>> >> [...] >>>> >>>> As far as I can see, other applications (Gwenview, Geeqie, Firefox) don't have >>>> problem to display the same images with librsvg2-2.56.3-1.fc38.x86_64 installed. >>> >>> Thanks, this helps. >>> >>> When an image fails to display, do you see any error messages from >>> librsvg? Those are usually emitted to stderr, so perhaps you need to >>> run Emacs in a way that stderr is not discarded, but either shown on >>> the terminal or written to a file. >> >> Hello ELi, >> >> I don't see any message on stderr, but a bunch of messages: >> "Invalid image size (see ‘max-image-size’)" in the *Messages* buffer, >> probably related to the display of an invalid image (empty square) >> in the *scratch* buffer. Also, the result of image-size is not the >> expected image size (22x22 px in example). I attached a screenshot. > > Thanks. I hope this will help an SVG expert to figure out what's > going on with these images. > > Alan, do you have time to look into this, per chance? I investigated further the issue with GDB, with a break in svg_load_image in image.c, trying to display the image "/usr/share/icons/breeze/actions/22/go-next.svg": I think the problem is after the call to rsvg_handle_get_intrinsic_dimensions at line 11354 in image.c. Here is the relevant portion of code: rsvg_handle_get_intrinsic_dimensions (rsvg_handle, &has_width, &iwidth, &has_height, &iheight, &has_viewbox, &viewbox); if (has_width && has_height) { /* Success! We can use these values directly. */ viewbox_width = svg_css_length_to_pixels (iwidth, dpi, img->face_font_size); viewbox_height = svg_css_length_to_pixels (iheight, dpi, img->face_font_size); /* Here one dimension could be zero because in percent unit. So calculate this dimension with the other. */ if (! (0 < viewbox_width) && (iwidth.unit == RSVG_UNIT_PERCENT)) viewbox_width = (viewbox_height * viewbox.width / viewbox.height) * iwidth.length; else if (! (0 < viewbox_height) && (iheight.unit == RSVG_UNIT_PERCENT)) viewbox_height = (viewbox_width * viewbox.height / viewbox.width) * iheight.length; } After the call to rsvg_handle_get_intrinsic_dimensions, the returned values are: (gdb) print has_width $8 = 1 (gdb) print iwidth $9 = {length = 1, unit = RSVG_UNIT_PERCENT} (gdb) print iheight $10 = {length = 1, unit = RSVG_UNIT_PERCENT} (gdb) print viewbox $11 = {x = 0, y = 0, width = 22, height = 22} has_width and has_height are both 1 with iwidth and iheight set to 100%. has_viewbox is also set to 1, and viewport contains the dimensions of the image (22x22 pixels). Then, the code matching "if (has_width && has_height)" is executed, which, in this case, sets both viewbox_width and viewbox_height to 0, which further leads to an image_size_error. Maybe, it is due to a change of specifications since librsvg 2.54.0. Here is what the spec I found at says: ----- Before librsvg 2.54.0, the out_has_width and out_has_height arguments would be set to true or false depending on whether the SVG document actually had width and height attributes, respectively. However, since librsvg 2.54.0, width and height are now geometry properties per the SVG2 specification; they are not plain attributes. SVG2 made it so that the initial value of those properties is auto, which is equivalent to specifing a value of 100%. In this sense, even SVG documents which lack width or height attributes semantically have to make them default to 100%. This is why since librsvg 2.54.0, out_has_width and out_has_heigth are always returned as TRUE, since with SVG2 all documents have a default width and height of 100%. As an example, the following SVG element has a width of 100 pixels and a height of 400 pixels, but no viewBox. This function will return those sizes in out_width and out_height, and set out_has_viewbox to FALSE. Conversely, the following element has a viewBox, but no width or height. This function will set out_has_viewbox to TRUE, and it will also set out_has_width and out_has_height to TRUE but return both length values as 100%. ----- I hope it will help an SVG expert to fix the issue. Thanks