bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#44065: 28.0.50; SVG image not shown completely


From: Alan Third
Subject: bug#44065: 28.0.50; SVG image not shown completely
Date: Sun, 25 Oct 2020 16:25:31 +0000

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 via email to

[Prev in Thread] Current Thread [Next in Thread]