## Recommendations for Applications

## How sizing works in SVG

SVG documents are scalable. The conventional way to position SVG documents, which comes from the web platform, is to consider a viewport in which to place the SVG document — that is, a rectangular region to where the SVG will be scaled and positioned.

SVG renderers are supposed to use the viewport provided by the application, plus the SVG document's `width`, `height`, and `viewBox` attributes, to compute the position and size for the rendered document.

Ideally, the toplevel `<svg>` element of an SVG document will contain `width` and `height` attributes, that indicate the proportions and "natural size" of the document. When those attributes are present, the SVG renderer can unambiguously figure out the natural aspect ratio of the document, and can also suggest a natural size for the document. For example, `<svg width="100px" height="50px">` has a natural size of 100x50 pixels, but it could also be rendered scaled at 200x100 pixels. Since SVGs are scalable, it is not mandatory to actually use its natural size; it can be scaled arbitrarily. Of course, it is up to each application how an SVG document will be scaled: a web browser would want to consider the semantics of embedding images in HTML, which may be different from a GUI toolkit loading SVG assets with hard-coded sizes.

If an SVG document's toplevel `<svg>` element does not have `width` and `height` attributes, then the SVG renderer can try to figure out the document's aspect ratio from the `viewBox` attribute. For example, there is no natural size for `<svg viewBox="0 0 100 50">`, but it has a 2:1 (or 100:50) aspect ratio, so it is twice as wide as it is tall.

If there is no `viewBox` either, then the SVG renderer cannot easily figure out the natural size of the document. It can either set a 1:1 scaling matrix within the application's viewport and render the SVG there, or it can actually try to compute the size of each object in the SVG document to figure out the size. The latter is a moderately expensive operation, and can be avoided by having the SVG document specify `width` and `height` attributes. Try not to have SVG documents that just start with `<svg>` without any of those attributes.

### How librsvg computes document sizes

Librsvg looks for the `width` and `height` attributes in the toplevel `<svg>` element. If they are present, librsvg uses them for the "natural" size of the SVG, and this also defines the aspect ratio. The size has actual units (pixels, centimeters, etc.) depending on the value of the `width` and `height` attributes.

If there are no `width` or `height` attributes in the toplevel `<svg>`, librsvg looks for the `viewBox` attribute. If present, this defines the aspect ratio and a "natural" size in pixels.

In both cases above (with `width`/`height` and/or `viewBox`), librsvg can determine the "natural" size and aspect ratio of an SVG document immediately after loading.

Otherwise, if none of those attributes are present in the toplevel `<svg>` element, librsvg must actually compute the coverage of all the graphical elements in the SVG. This is a moderately expensive operation, and depends on the complexity of the document.