Add Tree::intrinsic_dimensions exposing declared root width/height/viewBox

[nicoburns]

Exposes raw/unresolved width/height/viewBox on Tree.

This is necessary to correctly size SVGs within an HTML document (e.g. in Servo/Blitz) in the case that width or height are defined as a percentage. In that case, resvg's existing approach of eagerly resolving sizes doesn't work, as you cannot correctly resolve the sizes until you have a basis to resolve the percentages against (which are only computed as part of layout).

Exposed as a separate method to the existing width() and height() methods as it's a little bit of an advanced use case, and the existing methods make some sense for the simple cases.

[LaurenzV]

Hmm, it feels a bit hacky... Can't you just construct the roxmltree yourself and then get the attributes from the root node yourself?

[nicoburns]

Hmm, it feels a bit hacky... Can't you just construct the roxmltree yourself and then get the attributes from the root node yourself?

I can, but isn't that a lot more hacky? Aside from anything else, I then have to parse every SVG twice.

[RazrFalcon]

Would this even work? All other relative values would be already resolved based on the viewbox. So the one you would store would not mean anything.

The SVG spec is comically large and complex, so I have no idea how exactly it suppose to work. But shouldn't we pass the viewport size/bounds to usvg instead? So it would fit stuff automatically?
Because otherwise you're expected to apply a certain scale transform during SVG rendering and I doubt it would work as you would expect.

[LaurenzV]

Aside from anything else, I then have to parse every SVG twice.

I don't tihnk so, no? Can't you just construct the roxmltree once yourself and then pass it to usvg?

I can, but isn't that a lot more hacky?

Maybe hacky is not the right word. Basically, my point was usvg tries its best to completely abstract away the original SVG file and turn it into its own intermediate representation. Therefore, it would feel a bit "leaky" if we expose parts of the original XML SVG from the tree. But anyway, I don't want to be too nitpicky. 🙂 It was just a thought. But as RazrFalcon mentioned, I'm also not sure if just doing this will work in all cases.

[nicoburns]

Because otherwise you're expected to apply a certain scale transform during SVG rendering and I doubt it would work as you would expect. shouldn't we pass the viewport size/bounds to usvg instead?

Yes, this is the intended use case for this PR: computing the correct scale factor to apply during rendering. That's significantly cheaper than re-parsing the SVG every time the size I want to render it at changes.

Importantly, for SVGs embedded in HTML documents:

• The size/scale at which the SVG is rendered at can depend on resolving the SVG's percentage width/height attributes against the "containing block" in which the SVG is situated.
• The size of that "containing block" can vary frequently (e.g. every frame)
• At least for SVGs with a viewBox, the size is a simple linear scaling because the proportions of the SVG are determined by the viewBox (and in general I think cases where the proportions of an SVG are changed are pretty rare - this would almost never look good).

[LaurenzV]

What about preserveAspectRatio though, for example? Wouldn't you also need this to resolve everything correctly?

If you still want this, I'm happy to approve, so just let me know, but I still think the better approach would still be to just construct the roxmltree up-front, extract whatever attributes you need yourself from the root node and then pass it on to usvg. 😄