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: Andy Moreton
Subject: bug#44065: 28.0.50; SVG image not shown completely
Date: Sun, 25 Oct 2020 17:12:24 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1.50 (windows-nt)

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






reply via email to

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