Detect SVG size by bboxes

[RazrFalcon]

Currently, we skip files which doesn't have width, height or viewBox attribute.

[reknih]

Hey,
I ran across this issue when trying to use usvg to render some SVG glyphs in fonts. Twitter Color Emoji for example has stripped the viewBox from their files in the actual font file (they did not contain width or height attributes in the first place). SVGO also has the tendency to remove viewBoxes and to cause trouble with that..

I'd like to submit a PR allowing to convert most files missing the attributes to Micro SVG, but your input is needed on a few points:

• For SVGs that only use absolute units as lengths in paths etc. we can just assume an infinite user coordinate space and shrink that down using bboxes afterwards, no problems. However, when lengths do use percentage values (and width and height are defined in terms of viewport size), there is no single Micro SVG presentation that preserves the file's rescaling behavior. I thought of two possibilities of dealing with this:
  • Reject files that do not have the width, height attributes defined in absolute terms, do not specify a viewBox and use percentage lengths.
  • Allow the user to specify a fallback size for the viewport in the options struct with respect to which the width and height attributes get resolved. If such a fallback size is specified, usvg does not fail even if there are percentage lengths. Since in some applications, viewport size is not known beforehand, this preference would be optional to set. If it remains unset, the behavior would be the same as in the first possibility.
• Both of these would likely mean that I'd need to add a bool field to the state that indicates that the user space coordinate boundries were not unambigously resolved (alternatively, all such sizes could become Options) and that the convert_children function and its descendants would start to return Options / Results.

Which of the alternatives would you prefer? Are you happy with this proposed design?
Cheers

[RazrFalcon]

Yes, the main problem with this issue is that the SVG spec doesn't explain how it should be handled (afaik).
We can simply fit the viewBox into content bbox, but this would not work for documents with relative lengths.
I agree that the simplest solution is to require a fallback viewBox/viewport size. And a caller would be able to change it to whatever size needed.

We could potentially ignore files with % coordinates, but <svg><rect width="100%" height="100%"/></svg> is a perfectly valid SVG.

Also note that behaviour for filter is also unspecified. So while blur/dropshadow do expand the canvas, should they also expand the viewbox? Same goes for paths with wide stroke.

[reknih]

Yeah, the spec is a bit ambiguous.

We could potentially ignore files with % coordinates, but <svg><rect width="100%" height="100%"/></svg> is a perfectly valid SVG.

This is what the attributes default to anyways so it'd have to be supported in the PR (both of my design proposals would accomodate such a file)

So while blur/dropshadow do expand the canvas, should they also expand the viewbox? Same goes for paths with wide stroke.

I would not make them do that, as long as the canvas grows, we are good AFAIK (but then again, this would make my life easier, so I'm not impartial here).

[RazrFalcon]

Yes, for the initial implementation tight path bbox + fallback size would be enough.