bug#44065: 28.0.50; SVG image not shown completely

[Alan Third]

On Sat, Oct 17, 2020 at 06:27:30PM -0500, styang@fastmail.com wrote:
> Emacs stopped showing SVG files completely (i.e. it is shown
> cropped), with 8f42b94fe43 the offending commit. This commit intends
> to resolve bug#40845.
> 
> Please find the SVG file (1.svg) I use and the render image (1.png)
> in attachment. Notice the cropped part at the bottom and on the
> right side. The SVG file can be correctly viewed by Emacs 27, and
> other photo viewers like eog or gThumb. The file attached embeds an
> SVG element inside another, which seems to be discouraged by
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40845#68. However,
> according to Mozilla MDN
> (https://developer.mozilla.org/en-US/docs/Web/SVG/Element/svg),
> 
> > The svg element is a container that defines a new coordinate
> > system and viewport. It is used as the outermost element of SVG
> > documents, but it can also be used to embed an SVG fragment inside
> > an SVG or HTML document.

I think you've misunderstood my message in that bug thread. Emacs
can't blindly embed SVG files within other SVGs because we can't
guarantee the files will only contain the <svg>...</svg> section.
There may be other bits, specifically XML doctype declarations, that
cannot be inserted inside an SVG.

It appears that by adding the wrapper SVG we change the scale of
the image even though we're not asking to. I can't see what we're
doing wrong.

I tried switching from using rsvg_handle_get_dimensions since it uses
a deprecated struct, although the function itself isn't deprecated
(shades of Apple's APIs). However rsvg_handle_get_geometry_for_layer
just plain doesn't return anything for at least one of my test SVG
files and still seems to produce the wrong values for the viewport
dimensions.

It's getting late. I suppose I'll come back to this tomorrow.

-- 
Alan Third