unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Third <alan@idiocy.org>
To: Andy Moreton <andrewjmoreton@gmail.com>
Cc: 44065@debbugs.gnu.org
Subject: bug#44065: 28.0.50; SVG image not shown completely
Date: Sun, 25 Oct 2020 16:25:31 +0000	[thread overview]
Message-ID: <20201025162531.GF59267@breton.holly.idiocy.org> (raw)
In-Reply-To: <867drexzho.fsf@gmail.com>

On Sun, Oct 25, 2020 at 12:26:59PM +0000, Andy Moreton wrote:
> A new report in bug#44206 shows that this patch caused other problems.
> 
> The docs for rsvg_handle_get_geometry_for_layer show it does not report
> minimum sizes, as it ignores clipping regions. Thus for an SVG file
> which contains a small clipping region applied to a larger image, the
> reported sizes are incorrect.
> 
> Also, rsvg_handle_get_geometry_for_layer returns a gboolean, which the
> docs do not describe, but other API functions return TRUE for success
> and FALSE for failure. This should be checked.
> 
> Running under gdb with the image from bug#44206 shows that the bounds
> reported by rsvg_handle_get_geometry_for_layer are zero (so the
> functions may have failed and returned FALSE).
> 
> The original report here showed that rsvg_handle_get_dimensions did not
> alwyas return the correct results. It is documented to require a prior
> call to rsvg_handle_set_dpi to give correct results, but that is not
> called in image.c.
> 
> 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.

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.

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.

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 basically at the stage of saying we cannot have lossless,
arbitrarily resized SVGs using librsvg, but we can probably use the
stylesheet function added in 2.46 to set the background and foreground
colours.

As far as I can see there are no other real alternatives to librsvg
either, but I haven't investigated in detail.

-- 
Alan Third





  reply	other threads:[~2020-10-25 16:25 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-17 23:27 bug#44065: 28.0.50; SVG image not shown completely styang
2020-10-18 15:17 ` Eli Zaretskii
2020-10-18 16:02   ` Sheng Yang
2020-10-18 16:13     ` Eli Zaretskii
2020-10-18 16:24       ` Lars Ingebrigtsen
2020-10-18 17:03         ` Eli Zaretskii
2020-10-18 17:42           ` Stephen Berman
2020-10-18 17:48             ` Eli Zaretskii
2020-10-18 18:00               ` Stephen Berman
2020-10-18 18:03                 ` Eli Zaretskii
2020-10-19  8:43                   ` Lars Ingebrigtsen
2020-10-19  9:10                     ` Stephen Berman
2020-10-19 20:43                       ` Alan Third
2020-10-19 22:34                         ` Sheng Yang
2020-10-20 12:31                           ` Alan Third
2020-10-20 17:15                             ` Sheng Yang
2020-10-20 19:54                               ` Alan Third
2020-10-21 10:54                                 ` Lars Ingebrigtsen
2020-10-21 15:58                                   ` Corwin Brust
2020-10-21 16:31                                 ` Eli Zaretskii
2020-10-21 17:28                                   ` Sheng Yang
2020-10-21 19:03                                   ` Alan Third
2020-10-22 11:42                                     ` Lars Ingebrigtsen
2020-10-22 12:51                                       ` Eli Zaretskii
2020-10-22 19:11                                         ` Alan Third
2020-10-19 14:51                     ` Eli Zaretskii
2020-10-18 19:18                 ` Sheng Yang
2020-10-18 23:13 ` Alan Third
2020-10-23 20:17 ` Andy Moreton
2020-10-24  7:09   ` Eli Zaretskii
2020-10-24 17:01     ` Alan Third
2020-10-24 17:04       ` Eli Zaretskii
2020-10-24 10:43 ` Andy Moreton
2020-10-25 12:26 ` Andy Moreton
2020-10-25 16:25   ` Alan Third [this message]
2020-10-25 17:12 ` Andy Moreton
2020-10-25 17:27   ` Eli Zaretskii
2020-10-25 23:12   ` Alan Third

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201025162531.GF59267@breton.holly.idiocy.org \
    --to=alan@idiocy.org \
    --cc=44065@debbugs.gnu.org \
    --cc=andrewjmoreton@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).