From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Andy Moreton Newsgroups: gmane.emacs.bugs Subject: bug#44065: 28.0.50; SVG image not shown completely Date: Sun, 25 Oct 2020 17:12:24 +0000 Message-ID: <86wnzew7pj.fsf@gmail.com> References: <83ft67mth5.fsf@gnu.org> <20201021190346.GA47992@breton.holly.idiocy.org> <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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5751"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1.50 (windows-nt) To: 44065@debbugs.gnu.org Cancel-Lock: sha1:01XtSfK3s8mdxjN/HzHQMgsjiIM= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Oct 25 18:13:27 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 1kWjaB-0001Oo-8W for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 25 Oct 2020 18:13:27 +0100 Original-Received: from localhost ([::1]:53096 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kWjaA-0002NN-Az for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 25 Oct 2020 13:13:26 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37632) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kWjZm-0002Kw-Rd for bug-gnu-emacs@gnu.org; Sun, 25 Oct 2020 13:13:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54236) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kWjZm-0007CS-I4 for bug-gnu-emacs@gnu.org; Sun, 25 Oct 2020 13:13:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kWjZm-0007XC-Dq for bug-gnu-emacs@gnu.org; Sun, 25 Oct 2020 13:13:02 -0400 X-Loop: help-debbugs@gnu.org In-Reply-To: <87pn5ga0wt.fsf@gmail.com> Resent-From: Andy Moreton Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 25 Oct 2020 17:13:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 44065 X-GNU-PR-Package: emacs X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.160364595728910 (code B ref -1); Sun, 25 Oct 2020 17:13:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 25 Oct 2020 17:12:37 +0000 Original-Received: from localhost ([127.0.0.1]:37540 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kWjZN-0007WE-6m for submit@debbugs.gnu.org; Sun, 25 Oct 2020 13:12:37 -0400 Original-Received: from lists.gnu.org ([209.51.188.17]:40856) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kWjZL-0007W7-WD for submit@debbugs.gnu.org; Sun, 25 Oct 2020 13:12:36 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37500) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kWjZL-0001xa-QO for bug-gnu-emacs@gnu.org; Sun, 25 Oct 2020 13:12:35 -0400 Original-Received: from static.214.254.202.116.clients.your-server.de ([116.202.254.214]:44710 helo=ciao.gmane.io) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kWjZK-00078h-CE for bug-gnu-emacs@gnu.org; Sun, 25 Oct 2020 13:12:35 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1kWjZH-0000Su-Il for bug-gnu-emacs@gnu.org; Sun, 25 Oct 2020 18:12:31 +0100 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=geb-bug-gnu-emacs@m.gmane-mx.org; helo=ciao.gmane.io X-detected-operating-system: by eggs.gnu.org: First seen = 2020/10/25 13:12:31 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: 5 X-Spam_score: 0.5 X-Spam_bar: / X-Spam_report: (0.5 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action 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:191521 Archived-At: 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. > 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 ? Both rsvg_handle_get_geometry_for_layer and rsvg_handle_get_intrinsic_dimensions are documented as not taking clipping regions into account. 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. > 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. > As I see it the main problem here is that librsvg is designed to work > either with Cairo or in a very specific way and we're not doing > either. I'm not convinced, as the experiments above show there is something else going on that we are missing. AndyM