From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Third Newsgroups: gmane.emacs.bugs Subject: bug#44065: 28.0.50; SVG image not shown completely Date: Sun, 25 Oct 2020 23:12:05 +0000 Message-ID: <20201025231205.GH59267@breton.holly.idiocy.org> References: <873626ij0n.fsf@gnus.org> <837drimnjq.fsf@gnu.org> <20201022191122.GA59267@breton.holly.idiocy.org> <86h7qkwvcg.fsf@gmail.com> <83a6wchzg8.fsf@gnu.org> <20201024170124.GD59267@breton.holly.idiocy.org> <838sbvh7xo.fsf@gnu.org> <867drexzho.fsf@gmail.com> <20201025162531.GF59267@breton.holly.idiocy.org> <86wnzew7pj.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29035"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 44065@debbugs.gnu.org To: Andy Moreton Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Oct 26 00:13:11 2020 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 1kWpCJ-0007Rx-4p for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 26 Oct 2020 00:13:11 +0100 Original-Received: from localhost ([::1]:52214 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kWpCI-0003aH-5t for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 25 Oct 2020 19:13:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49412) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kWpCA-0003a8-2U for bug-gnu-emacs@gnu.org; Sun, 25 Oct 2020 19:13:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54606) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kWpC9-00013J-Ot for bug-gnu-emacs@gnu.org; Sun, 25 Oct 2020 19:13:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kWpC9-0001fy-Kd for bug-gnu-emacs@gnu.org; Sun, 25 Oct 2020 19:13:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Third Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 25 Oct 2020 23:13:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 44065 X-GNU-PR-Package: emacs Original-Received: via spool by 44065-submit@debbugs.gnu.org id=B44065.16036675396387 (code B ref 44065); Sun, 25 Oct 2020 23:13:01 +0000 Original-Received: (at 44065) by debbugs.gnu.org; 25 Oct 2020 23:12:19 +0000 Original-Received: from localhost ([127.0.0.1]:37919 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kWpBS-0001ex-Mo for submit@debbugs.gnu.org; Sun, 25 Oct 2020 19:12:19 -0400 Original-Received: from mailout-l3b-97.contactoffice.com ([212.3.242.97]:59342) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kWpBQ-0001ej-Kf for 44065@debbugs.gnu.org; Sun, 25 Oct 2020 19:12:17 -0400 Original-Received: from smtpauth2.co-bxl (smtpauth2.co-bxl [10.2.0.24]) by mailout-l3b-97.contactoffice.com (Postfix) with ESMTP id 28298C1C; Mon, 26 Oct 2020 00:12:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1603667530; s=20200222-6h9o; d=idiocy.org; i=alan@idiocy.org; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:Content-Type:In-Reply-To; l=4464; bh=WNoPqSNaBzc+3nbOgwCBaXzbYFqofI7sSK9HehHdQoI=; b=j5X6Rur6hoi6e2cKgXKq5n0Bxpam8iEUj4h41p93Si1cLM25zd5L9akYLpZfjIM5 ytt1iCH6AMr/RzbsgT89QHC6PSBTNa9N/Y8QO3twzeta0rfFrWLnFA43Mlsc7UBGtCO Ww+phv1zwOIZUTZbAHbL8cb4Jd7K5wWR87pxSa6PVPFZTlQjHc5yO1jK17F1NrzsZ2f K8ykXk54WEIoG0hnjRjuiBmLONiDp7/FLUb0I+o9OT45fL8ksvuGXmJbUtE360s3+JB KwNrc1gG/1w0FLRNW5xSXWDdLF+mSYO3phLqmXckdewTchC/ym0Cuj2l8r4fUjk37pp O07fhs9XBQ== Original-Received: by smtp.mailfence.com with ESMTPA ; Mon, 26 Oct 2020 00:12:06 +0100 (CET) Original-Received: by breton.holly.idiocy.org (Postfix, from userid 501) id C7C3C20263EBE2; Sun, 25 Oct 2020 23:12:05 +0000 (GMT) Mail-Followup-To: Alan Third , Andy Moreton , 44065@debbugs.gnu.org Content-Disposition: inline In-Reply-To: <86wnzew7pj.fsf@gmail.com> X-ContactOffice-Account: com:241649512 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" Xref: news.gmane.io gmane.emacs.bugs:191543 Archived-At: On Sun, Oct 25, 2020 at 05:12:24PM +0000, Andy Moreton wrote: > On Sun 25 Oct 2020, Alan Third wrote: > > > On Sun, Oct 25, 2020 at 12:26:59PM +0000, Andy Moreton wrote: > >> Perhaps this can be fixed by reverting to the original code with > >> addition of a call to rsvg_handle_set_dpi or rsvg_handle_set_dpi_x_y > >> before calling rsvg_handle_get_dimensions. > > > > No, it makes no difference to set the dpi. As far as I can tell > > setting the dpi doesn't even change the image dimensions which seems a > > little odd. > > I tried this on Windows using MSYS2 64bit (mingw64) and librsvg 2.48.8. > If I revert the original patch in this bug and add a call to: > rsvg_handle_set_dpi(rsvg_handle, 96.0); > > immediately before the call to rsvg_handle_get_dimensions, then: > - bug44206 image 222.svg is rendered correctly > - bug44065 image 1.svg is still clipped on the bottom and right edges. > > Both of these images render correctly in emacs 27.1.50 built from the > emacs-27 branch, using the same librsvg headers and runtime library. As Eli has already pointed out, the master branch is wrapping the SVG inside another SVG so we can set various parameters, such as the width and height of the final image. Emacs 27 doesn't do that. > > The problem isn't that rsvg_handle_get_dimensions is wrong, it's that > > we're wrapping the original SVG in another SVG and in order to get it > > to display correctly we need to know the exact details of the original > > SVG. rsvg_handle_get_dimensions does not return enough of the > > information we need. > > What information is missing specifically ? I believe that rsvg_handle_get_dimensions returns a width and height value that may not count the entirety of the whitespace on the left and top of the image. So we set up a viewBox with an x coord of 0 and the width returned by rsvg_handle_get_dimensions, and that is not then wide enough to cover the entire image, as we had no way to know to add the 3 pixels or so of whitespace on the left. > Both rsvg_handle_get_geometry_for_layer and > rsvg_handle_get_intrinsic_dimensions are documented as not taking > clipping regions into account. rsvg_handle_get_intrinsic_dimensions is documented as returning the dimensions defined in the top level of the SVG if they exist, so if they don't cover all the clipping regions (or, in fact, anything at all) then that's not really our problem as the person who created the image set those dimensions specifically. > That means if these functions report a non-zero size of an unclipped > image, that may still fail to load as it could exceed the limit set by > `max-image-size' and cause check_image_size to report a failure, even if > the clipped image would fit within the limit set by the user. Anything could exceed the maximum size, the problem we ran into with the latest bug report was it returning a zero sized rectangle. > > The librsvg documentation specifically tries to warn us off from > > querying for dimensions and suggest if we REALLY want to do that we > > should be doing it through Cairo. > > Please show where it says that: I have not found such an admonition in > the docs. https://developer.gnome.org/rsvg/stable/RsvgHandle.html: The preferred way to render an already-loaded RsvgHandle is to use rsvg_handle_render_cairo(). Please see its documentation for details. Alternatively, you can use rsvg_handle_get_pixbuf() to directly obtain a GdkPixbuf with the rendered image. This is simple, but it does not let you control the size at which the SVG will be rendered. It will just be rendered at the size which rsvg_handle_get_dimensions() would return, which depends on the dimensions that librsvg is able to compute from the SVG data. Also plenty of notices like this: rsvg_pixbuf_from_file_at_zoom is deprecated and should not be used in newly-written code. Set up a cairo matrix and use rsvg_handle_new_from_file() + rsvg_handle_render_cairo() instead. and while this page doesn't explicitly deny us the ability to request dimensions, it does make it clear they don't think we should be doing that: https://developer.gnome.org/rsvg/stable/recommendations-assets.html Maybe I'm reading too much into what these pages say, but I haven't yet found any simple way to do what we want to do other than using Cairo or using deprecated functions (if they still work). -- Alan Third