I have svg created in inkscape here.
The document size is in mm. For the 2 text fields, the font size is given like this:
style="...;font-size:31.420084px;..."
So it is given in px. Now I want the size of the font related to the document size.
But how should I convert the font-size in px to mm? I would need something like dpi, but the document does not specify anything.
In your case, your viewBox matches your document dimensions:
width="164.28572mm"
height="78.10714mm"
viewBox="0 0 164.28572 78.10714"
that means all unit less values are in mm. Just specify your font-size without units (or in your case when you use css just keep your document untouched and use px).
The confusing part is, that px in svg are always user units and not device pixels, for that reason, your font-size is already given in mm... so font-size:31.420084px in your document is equal to font-size:31.420084mm in a viewBox less document (where user units equal to device pixels)
<svg viewBox="0 0 100 20" width="100mm" height="20mm">
<text x="0" y="12" font-size="12px">12px</text>
</svg>
<svg >
<text x="0" y="12mm" font-size="12mm">12mm</text>
</svg>
Thats where it gets confusing. In the next example "1mm" is equal to 3.6 user units, but because 1 user unit equals 1mm in the real world, one svg mm equals 3.6 real mm ...
<svg viewBox="0 0 50 50" width="50mm" height="50mm">
<text x="0" y="5" font-size="1mm">font-size: 1mm</text>
<text x="0" y="10" font-size="3.6">font-size: 3.6</text>
</svg>
Units in SVG are a bit wired, but well defined...
The SVGLength Interface has a Method convertToSpecifiedUnits.
you can use that to convert between different units in SVG.
var l = svg.createSVGLength()
l.newValueSpecifiedUnits(SVGLength.SVG_LENGTHTYPE_PX, 12)
l.convertToSpecifiedUnits(SVGLength.SVG_LENGTHTYPE_MM)
out1.innerHTML = l.valueAsString
svg {
width: 0;
height: 0
}
<svg id="svg">
</svg>
12px = <span id="out1"></span>
The standard DPI used in an SVG document is the standard DPI that is specified by the CSS standard. That is 96dpi, or 96 standard CSS pixels per inch.
There are 25.4 mm per inch. So to convert px to mm, the formula will be:
mm = 25.4 * (px / 96)
So if we plug your original 31.420084px into that formula, the result is 8.31mm.
Note that CSS doesn't take into account the real word DPI of the device that you are rendering to. It uses that fixed approximation of 96pixels per inch. So you can't rely on the fact that an element with size 96px or 25.4mm will actually be that size on screen, or when printed.
Related
I am creating an SVG using the svg crate. To properly place a border around a <text> element, I calculate the length of the text beforehand using the rusttype crate.
However, my browser (Safari) seems to render the text with a different length.
The simplified version of my SVG is here:
<svg viewBox="0 0 210 297" xmlns="http://www.w3.org/2000/svg">
<g>
<path d="M105,20 L304,20 L304,77 L105,77 z" fill="none" stroke="black" stroke-width="1"/>
<text font-family="Arial" font-size="12" x="110" y="57">My extremely very, very, very, long Goal</text>
</g>
</svg>
I do calculate the length as found suggested here:
pub fn text_bounding_box(font: &Font, text: &str, size: f32) -> (u32, u32) {
let scale = rusttype::Scale::uniform(size);
let width = font
.layout(text, scale, rusttype::point(0.0, 0.0))
.last()
.map(|g| g.pixel_bounding_box().unwrap().max.x)
.unwrap_or(0);
let v_metrics = font.v_metrics(scale);
let height = (v_metrics.ascent - v_metrics.descent).ceil() + v_metrics.line_gap;
(width as u32, height as u32)
}
I ensured that the used font is Arial in both cases (when I calculate it, and for the SVG). At least, that's what I think.
My calculation yields a length of 189px. When inspecting the SVG with Safari, I see a width of ~213.14px.
Any suggestions are welcome.
I found a workaround to place a textLength attribute in the SVG, but I would at least like to understand the discrepancy. Thanks in advance.
Edit:
Rendered SVG without textLength attribute:
Rendered SVG with calculated textLength attribute:
There are several possible reasons for the discrepancies between measing text in two different libraries/engines.
Kerning differences
Ligature handling differences
On-screen font renderers often adjust glyph position to better align with screen pixels. Especially for small font sizes.
There are other potential font-specific features and variations that may be affecting rendering
Most likely is probably #3. Try setting font size to something big (eg. 100) to see if this is the case. You could also try experimenting with the CSS text-rendering property.
I am trying to draw this SVG path.
I could achieve it using SVG Line and Curve properties for a fixed height and width using fixed coordinates.
But, I need to draw this responsively which means, the width of the path, space between the lines, the distance between each point, and the curves at the sides should be responsive.
It contains levels indicated by numbers as shown in the image, and the length of the path should be determined by the number of levels given.
While trying to draw this responsively, I was stuck at
Getting the start and end-point of the Lines
Getting control points for the curves
Responsive adjustment of the distance between each point and space between the curves
Determining the length of the path based on the number of levels given
I am trying to do these using percentages based on the parent div's width by some mathematical calculations. But, it seems it breaks some or other cases due to its complexity.
There are some other things to do along with these, but this is the top-level version of what needs to be done.
Is there any direct method or formula or calculation for achieving this?
(or)
Is there any other approach to draw this?
(or)
Are there any tutorials for learning to draw these types of SVG paths?
After creating the path you need to calculate the position of the numbers and circles on the path. For this you need to know the length of the path calculated with the getTotalLength() method. Next you need a loop to calculate the position of the numbers on the path. For this I've used the getPointAtLength()
method. On each of this pointd you create a new circle (use) element and a new text element.
Please read the comments in the code.
//constants used to create a new element in svg
const SVG_NS = "http://www.w3.org/2000/svg";
const SVG_XLINK = "http://www.w3.org/1999/xlink";
//the total length of the path
let length= thePath.getTotalLength();
//the number of points on the path
let n = 15;
let step = length/n;
for(let i= 1; i<=n; i++){
//creates a new point on the path at a given length
let point = thePath.getPointAtLength(i*step);
//create a new use element (or a circle) and set the center of the circle on the calculated point
let use = document.createElementNS(SVG_NS, 'use');
use.setAttributeNS(SVG_XLINK, 'xlink:href', '#gc');
use.setAttribute("x", point.x);
use.setAttribute("y", point.y);
//create a new text element on the same point. Thr text content is the i number
let text = document.createElementNS(SVG_NS, 'text');
text.setAttribute("x", point.x);
text.setAttribute("y", point.y);
text.textContent = i;
//append the 2 new created elements to the svg
svg.appendChild(use);
svg.appendChild(text);
}
svg {
border: solid;
}
text {
fill: black;
font-size: 4px;
text-anchor: middle;
dominant-baseline: middle;
}
<svg viewBox="0 0 100 80" id="svg">
<defs>
<g id="gc">
<circle fill="silver" r="3" />
</g>
</defs>
<path id="thePath" fill="none" stroke="black" d="M10,10H70A10,10 0 0 1 70,30H20A10,10 0 0 0 20,50H70A10,10 0 0 1 70,70H20" />
</svg>
Please observe that since the svg element has a viewBox attribute and no with it takes all the available width making it responsive.
I am learning svg from its official documents, there is such line. I don't get it, if it already has a width and height attribute, what is the point to specify it again in viewBox="0 0 1500 1000" ?
It is says, "One px unit is defined to be equal to one user unit. Thus, a length of "5px" is the same as a length of "5"" in the official docs, thus this viewBox is a 1500px wide and 1000 height view, which exceeds 300px and 200px. So why does it define the width and height value in the first place?
<svg width="300px" height="200px" version="1.1"
viewBox="0 0 1500 1000" preserveAspectRatio="none"
xmlns="http://www.w3.org/2000/svg">
The width and height are how big the <svg> is. The viewBox controls how its contents are displayed so the viewBox="0 0 1500 1000" will scale down the contents of <svg> element by a factor of 5 (1500 / 300 = 5 and 1000 / 200 = 5) and the contents will be 1/5 the size they would be without the viewBox but the <svg>
Imagine you have an elastic surface and cut it into 4 equal pieces. If you throw 3 pieces away you've got a surface that's 1/4 the size of the original surface. If you now stretch the surface and make it the same size as the original surface then everything on the surface will be twice the size. That's how viewBox and width/height are related.
By default
<svg width="300" height="200">
the "ruler" of svg grid is in pixel (all shapes in that svg is measured in pixel)
But you want to use your own units you can use viewBox attr for that:
<svg width="300" height="200" viewBox="0 0 1500 1000">
That means:
horizontal axis: 1500 (your width unit) = 300px => 1 (your width unit) = 300/1500px = 1/5px
vertical axis: 1000 (your height unit) = 200px => 1 (your height unit) = 200/1000px = 1/5px
Now all shapes in the svg will scale:
their widths scale to 1/5px (1/5 < 1 => scale down) comparing to the origin.
their heights also scale to 1/5px (1/5 < 1 => scale down) comparing to the origin
If you don't specify a viewbox, all unitless numbers in an element are assumed to be pixels. (and SVG assumes 90 dpi or pixels per inch for conversion from units like cm to pixels.)
A viewbox lets you make unitless numbers in elements mean "user units" and specifies how those units are mapped to the size. For simplicity, consider just the x coordinates, that is, a ruler. Your viewbox says that your ruler will have 1500 units to match the 200 pixel size width of the svg.
A line element from 0 to 1500 (unitless, i.e. user units) would stretch 200 pixels as drawn, that is, across the width of the svg drawing.
(And since SVG is scalable without loss of resolution, pixels really don't mean much in the real world, when a user zooms in or out.)
Its a coordinate transformation, of sorts.
I suggest you learn from a book like "SVG Essentials", about $10 used, from which I loosely quote this answer.
MAIN:
The viewBox attribute is closely related to the term viewport in SVG
ABBREVIATION:
viewBox - VB
viewport - VP
viewport coordinate system - VCS
local coordinate system - LCS
SYNTAX:
<svg x = "VP_min_X" y = "VP_min_Y" width = "VP_width" height = "VP_height"
viewBox = "VB_min_X VB_min_Y VB_width VB_height">
DEFAULT VALUES:
units = px
viewport width = 300
viewport width = 150
viewBox = viewport
CODE WITH DEFAULT VALUES
<svg>
CODE WITH THE SAME RESULT:
<svg x = "0" y = "0" width = "300" height = "150" viewBox = "0 0 300 150">
VIEWPORT SETTINGS:
THE ORIGIN POINT of the viewport coordinate system (VCS):
VP_min_X
VP_min_Y
in the case of the outermost viewport, these values do not matter
and in any case will be equal to 0, they are usually omitted:
<svg width = "100" height = "150">
CODE WITH THE SAME RESULT: (for the most external viewport):
<svg x = "10" y = 20 "width ="100 "height ="150">
NESTED VIEWPORT:
In a nested viewport (VP_min_X, VP_min_Y) define the indent from the origin point of VCS:
<svg width="100%" height="100%"> <!-- external viewport = full browser size -->
<svg x="50" y="100" width="200" height="300" viewBox="0 0 100 100">
</svg>
</svg>
in this case indent of the nested viewport:
50px along the X axis and 100px along the Y axis from the origin point of the external VCS.
THE DIMENSIONS of the rectangular area (viewport) in which SVG grafics will be drawn are determined:
VP_width
VP_height
VIEWBOX SETTINGS:
THE ORIGIN POINT of the local coordinate system (LCS):
Vb_min_X
Vb_min_y
THE SIZE of the visible part of the SVG image:
Vb_width
Vb_height
RENDERING:
When constructing the final SVG image, the coordinate systems are transformed by COMBINING:
Points of origin of coordinate systems:
VCS (VP_min_X, VP_min_Y)
LCS (VB_min_X, VB_min_Y)
End points of the visible image area:
VCS (VP_width, VP_height)
LCS (VB_width, VB_height)
CAPABILITIES:
As a result, it becomes possible to control:
location of the viewport in the browser window [using the nested viewport and changing (VP_min_X, VP_min_Y)]
viewport sizes (VP_width, VP_height)
panning the visible part of the image [using viewBox and changing (VB_min_X, VB_min_Y)]
scaling the visible part of the image [using viewBox and changing (VB_width, VB_height)]
VISUALIZATION:
2 minutes on YouTube to understand the principles described above:
video viewBox in SVG
DOCUMENTATION:
W3C 2019 SVG 2 specification
Here is some practical information that I find useful to understand (and particularly to work with) SVG viewPort and viewBox.
SVG uses the terms viewPort and viewBox. The viewBox is inside the viewPort. Think of the viewBox as the image itself – because you can zoom it, slide it left/right/up/down – all within the viewPort. The viewPort (the SVG tag itself) is like a container that the SVG image is inside. You can size this also, and move it around left/right/up/down. And the SVG tag is within an HTML container (div, p, aside, h3, etc). So you can see why people find viewPort / viewBox to be a bit confusing. Just think of viewBox as the image itself.
The width/height attributes on the SVG tag provide the size of the viewPort. This is the width/height of the container in which the SVG image is displayed. (You can also have x="" and y="" attributes, just as you have in the viewBox attribute.)
So, on the SVG itself, you specify width /height and starting x offset / starting y offset – these are called the viewPort (aka ViewPort Coord System)
In the viewBox attribute, you specify "x y width height" – these are called the viewBox (aka Local Coord System LCS)
<svg x="0" y="0" width="500" height="300"
viewBox="start_x start_y width height" >
...path fill d etc...
</svg>
Important Concept #1: the width/height of the viewPort (the ones that are on the SVG tag itself, as width="" and height="") specify the size of the container in which the SVG image will be displayed. Usually, or if omitted, this is the exact size as (or a tiny bit larger than) the SVG image itself.
Super-Important Concept #2: the width/height of the viewBox is directly related to the width/height of the viewPort. If the viewPort is 300 x 500, then as the viewBox W / H numbers get LARGER than 300 x 500, the image itself grows smaller within the viewPort (zooms out). But as the viewBox w/h gets smaller than 300 x 500, the image itself grows LARGER within the viewPort. This growth is to the right and down, so if you need to slide the zoomed-in image around in the now-too-small viewPort, that is when you use the X / Y values of the viewBox.
viewBox x/y – slides the SVG right/down inside the viewPort
viewBox width/height – as increase larger than the SVG tag's width/height, it zooms the image OUT inside the viewPort. The SVG shrinks right/down within the viewport. Decrease number below the SVG width/height attribs: the image will GROW in the viewport until portions of the image to the right/bottom may be cut off by the rightSide/Bottom of the viewPort. *(i.e. when the width/height numbers in the viewBox attribute are less than the width/height attributes on the SVG, the image ZOOMS IN within the viewPort. When larger, the image zooms OUT (shrinks) with the viewPort.
viewPort x/y == slides the viewport itself right/down within its HTML container
viewPort width/height – resizes the entire viewPort larger, possibly overflowing the HTML container (div / p / etc). Basically, makes the viewPort larger by growing it right/down.
Notes:
a. If you do not include the ViewBox attribute on the SVG, then the size of the viewBox equals the size of the viewPort (takes 100% of the viewPort)
b. If the viewBox begins 0,0 and has same width/height as the SVG width/height (i.e. the viewPort), nothing will change. Equivalent to not having a viewbox attribute at all.
c. If you have a viewPort the size of a deck of cards, but the SVG image is the size of a cereal box, then increasing the viewBox "x y …" numbers will move the cereal box image up/left in the viewPort, showing a different part of the cereal box's image. This would be useful with sprites
d. (Usually (always!) the SVG element is also inside an HTML container - a div, p, section, li, whatever. We didn't discuss this, but remember it. If your image is being cut off, then either the viewBox is larger than the viewPort -OR- the HTML container element (div, etc) is smaller than the viewPort)
Here are two (excellent!) short videos, referred to us by the author of this answer within this same thread:
2min video demo
5min video demo (same guy, much better)
Here's a non-technical way of illustrating the relationship between width, height and the viewBox:
If you had any old image on your computer with the dimensions 1500 x 1000, and you pinched the corner of the image and resized it to 300 x 200, the image would shrink, or scale down (assuming scaling is enabled). The opposite is also true.
A good rule of thumb is to always look at the viewBox width and height first, and compare it to the SVG's width and height (or the parent's width and height if they are not declared in the SVG). That way you can tell whether the SVG image will scale up (grow), or down (shrink).
<svg width="300px" height="200px" viewBox="0 0 1500 1000">
The above is telling the browser that you have an SVG that's 1500 x 1000 but you want it to "pinch the corners" and shrink it down to 300 x 200.
viewbox is a ratio
In my humble experience, I've always considered <svg>’s viewbox values as a required image ratio to apply to the width and height values. While defining the laters just I do with any <img> in the DOM, either inline HTML properties or via CSS, viewbox property only applies to the SVG file.
I'm looking for the best way (the faster, the cleaner...) to move a group of SVG elements. I have three ways in mind :
do a loop on all elements and, for each of us, change the x and y attributes
group all elements in a svg element and change its x and y attributes
group all elemnts in a g element and apply the method described here : https://stackoverflow.com/a/14036803/2019761
Do you have an idea please ?
You can move svg groups or elements with javascript
// translate svg element
function translate( _element , _x , _y )
{
var transform = _element.transform.baseVal.getItem(0);
var mat = transform.matrix;
mat = mat.translate( _x, _y );
transform.setMatrix( mat );
}
see it in action:
http://www.janvas.com/illustrators_designers_developers/projects/janvas2D_web/examples_EN.php?exampleName=ufo_animation_EN
I think that the better way is to move a group of elements.
If you look the example you can see that the ufo are translated
and the inner motor rotate inside of it.
(all moved elements are groups)
<g xmlns="http://www.w3.org/2000/svg" transform="matrix(1 0 0 1 -12.5067 69.4101)" id="ufo">
<g transform="matrix(1 0 0 1 0 -2.842170943040401e-14)">
<path transform="matrix(1 0 0 1 21.6 2.8)" width="92.34371368613222" height="91.4899957511011" stroke-width="0.83" stroke-miterlimit="3" stroke="none" fill="url(#_1_)" d="M46.1,0 C71.67,0 92… "/>
</g>
<g transform="matrix(0.5 0.86 -0.86 0.5 74.6 24.1)" id="motor">
<path transform="matrix(1 0 0 1 9.7 -2.2)" width="13.11" height="13.5849" stroke-width="0.88" stroke-miterlimit="3" stroke="none" fill="url(#_4_)" d="M6.55,2.8… "/>
</g>
</g>
Interacting with DOM methods involves JS <-> native code overhead. Browser implementers have been working hard to reduce this overhead, but it's never going to be free. If you're doing a lot of it, such as setting x and y on a lot of elements, you may start to see a significant performance impact. In this case setting positional properties just once on an <svg> or <g> container will likely help.
A more significant source of overhead is likely to be the work to repaint for the changes you make. If these changes are for a transform change, and if the transform's value changes multiple times in a short space of time, then most implementations will paint the content of the transformed SVG element into a cached offscreen surface and composite that surface instead of repainting each time. Recompositing can be a lot faster than repainting if the contents of the element are expensive to paint (say it contains a lot of children, or expensive filter effects), so if you're animating the transform of a <g> then you could well see much better performance.
I am learning svg from its official documents, there is such line. I don't get it, if it already has a width and height attribute, what is the point to specify it again in viewBox="0 0 1500 1000" ?
It is says, "One px unit is defined to be equal to one user unit. Thus, a length of "5px" is the same as a length of "5"" in the official docs, thus this viewBox is a 1500px wide and 1000 height view, which exceeds 300px and 200px. So why does it define the width and height value in the first place?
<svg width="300px" height="200px" version="1.1"
viewBox="0 0 1500 1000" preserveAspectRatio="none"
xmlns="http://www.w3.org/2000/svg">
The width and height are how big the <svg> is. The viewBox controls how its contents are displayed so the viewBox="0 0 1500 1000" will scale down the contents of <svg> element by a factor of 5 (1500 / 300 = 5 and 1000 / 200 = 5) and the contents will be 1/5 the size they would be without the viewBox but the <svg>
Imagine you have an elastic surface and cut it into 4 equal pieces. If you throw 3 pieces away you've got a surface that's 1/4 the size of the original surface. If you now stretch the surface and make it the same size as the original surface then everything on the surface will be twice the size. That's how viewBox and width/height are related.
By default
<svg width="300" height="200">
the "ruler" of svg grid is in pixel (all shapes in that svg is measured in pixel)
But you want to use your own units you can use viewBox attr for that:
<svg width="300" height="200" viewBox="0 0 1500 1000">
That means:
horizontal axis: 1500 (your width unit) = 300px => 1 (your width unit) = 300/1500px = 1/5px
vertical axis: 1000 (your height unit) = 200px => 1 (your height unit) = 200/1000px = 1/5px
Now all shapes in the svg will scale:
their widths scale to 1/5px (1/5 < 1 => scale down) comparing to the origin.
their heights also scale to 1/5px (1/5 < 1 => scale down) comparing to the origin
If you don't specify a viewbox, all unitless numbers in an element are assumed to be pixels. (and SVG assumes 90 dpi or pixels per inch for conversion from units like cm to pixels.)
A viewbox lets you make unitless numbers in elements mean "user units" and specifies how those units are mapped to the size. For simplicity, consider just the x coordinates, that is, a ruler. Your viewbox says that your ruler will have 1500 units to match the 200 pixel size width of the svg.
A line element from 0 to 1500 (unitless, i.e. user units) would stretch 200 pixels as drawn, that is, across the width of the svg drawing.
(And since SVG is scalable without loss of resolution, pixels really don't mean much in the real world, when a user zooms in or out.)
Its a coordinate transformation, of sorts.
I suggest you learn from a book like "SVG Essentials", about $10 used, from which I loosely quote this answer.
MAIN:
The viewBox attribute is closely related to the term viewport in SVG
ABBREVIATION:
viewBox - VB
viewport - VP
viewport coordinate system - VCS
local coordinate system - LCS
SYNTAX:
<svg x = "VP_min_X" y = "VP_min_Y" width = "VP_width" height = "VP_height"
viewBox = "VB_min_X VB_min_Y VB_width VB_height">
DEFAULT VALUES:
units = px
viewport width = 300
viewport width = 150
viewBox = viewport
CODE WITH DEFAULT VALUES
<svg>
CODE WITH THE SAME RESULT:
<svg x = "0" y = "0" width = "300" height = "150" viewBox = "0 0 300 150">
VIEWPORT SETTINGS:
THE ORIGIN POINT of the viewport coordinate system (VCS):
VP_min_X
VP_min_Y
in the case of the outermost viewport, these values do not matter
and in any case will be equal to 0, they are usually omitted:
<svg width = "100" height = "150">
CODE WITH THE SAME RESULT: (for the most external viewport):
<svg x = "10" y = 20 "width ="100 "height ="150">
NESTED VIEWPORT:
In a nested viewport (VP_min_X, VP_min_Y) define the indent from the origin point of VCS:
<svg width="100%" height="100%"> <!-- external viewport = full browser size -->
<svg x="50" y="100" width="200" height="300" viewBox="0 0 100 100">
</svg>
</svg>
in this case indent of the nested viewport:
50px along the X axis and 100px along the Y axis from the origin point of the external VCS.
THE DIMENSIONS of the rectangular area (viewport) in which SVG grafics will be drawn are determined:
VP_width
VP_height
VIEWBOX SETTINGS:
THE ORIGIN POINT of the local coordinate system (LCS):
Vb_min_X
Vb_min_y
THE SIZE of the visible part of the SVG image:
Vb_width
Vb_height
RENDERING:
When constructing the final SVG image, the coordinate systems are transformed by COMBINING:
Points of origin of coordinate systems:
VCS (VP_min_X, VP_min_Y)
LCS (VB_min_X, VB_min_Y)
End points of the visible image area:
VCS (VP_width, VP_height)
LCS (VB_width, VB_height)
CAPABILITIES:
As a result, it becomes possible to control:
location of the viewport in the browser window [using the nested viewport and changing (VP_min_X, VP_min_Y)]
viewport sizes (VP_width, VP_height)
panning the visible part of the image [using viewBox and changing (VB_min_X, VB_min_Y)]
scaling the visible part of the image [using viewBox and changing (VB_width, VB_height)]
VISUALIZATION:
2 minutes on YouTube to understand the principles described above:
video viewBox in SVG
DOCUMENTATION:
W3C 2019 SVG 2 specification
Here is some practical information that I find useful to understand (and particularly to work with) SVG viewPort and viewBox.
SVG uses the terms viewPort and viewBox. The viewBox is inside the viewPort. Think of the viewBox as the image itself – because you can zoom it, slide it left/right/up/down – all within the viewPort. The viewPort (the SVG tag itself) is like a container that the SVG image is inside. You can size this also, and move it around left/right/up/down. And the SVG tag is within an HTML container (div, p, aside, h3, etc). So you can see why people find viewPort / viewBox to be a bit confusing. Just think of viewBox as the image itself.
The width/height attributes on the SVG tag provide the size of the viewPort. This is the width/height of the container in which the SVG image is displayed. (You can also have x="" and y="" attributes, just as you have in the viewBox attribute.)
So, on the SVG itself, you specify width /height and starting x offset / starting y offset – these are called the viewPort (aka ViewPort Coord System)
In the viewBox attribute, you specify "x y width height" – these are called the viewBox (aka Local Coord System LCS)
<svg x="0" y="0" width="500" height="300"
viewBox="start_x start_y width height" >
...path fill d etc...
</svg>
Important Concept #1: the width/height of the viewPort (the ones that are on the SVG tag itself, as width="" and height="") specify the size of the container in which the SVG image will be displayed. Usually, or if omitted, this is the exact size as (or a tiny bit larger than) the SVG image itself.
Super-Important Concept #2: the width/height of the viewBox is directly related to the width/height of the viewPort. If the viewPort is 300 x 500, then as the viewBox W / H numbers get LARGER than 300 x 500, the image itself grows smaller within the viewPort (zooms out). But as the viewBox w/h gets smaller than 300 x 500, the image itself grows LARGER within the viewPort. This growth is to the right and down, so if you need to slide the zoomed-in image around in the now-too-small viewPort, that is when you use the X / Y values of the viewBox.
viewBox x/y – slides the SVG right/down inside the viewPort
viewBox width/height – as increase larger than the SVG tag's width/height, it zooms the image OUT inside the viewPort. The SVG shrinks right/down within the viewport. Decrease number below the SVG width/height attribs: the image will GROW in the viewport until portions of the image to the right/bottom may be cut off by the rightSide/Bottom of the viewPort. *(i.e. when the width/height numbers in the viewBox attribute are less than the width/height attributes on the SVG, the image ZOOMS IN within the viewPort. When larger, the image zooms OUT (shrinks) with the viewPort.
viewPort x/y == slides the viewport itself right/down within its HTML container
viewPort width/height – resizes the entire viewPort larger, possibly overflowing the HTML container (div / p / etc). Basically, makes the viewPort larger by growing it right/down.
Notes:
a. If you do not include the ViewBox attribute on the SVG, then the size of the viewBox equals the size of the viewPort (takes 100% of the viewPort)
b. If the viewBox begins 0,0 and has same width/height as the SVG width/height (i.e. the viewPort), nothing will change. Equivalent to not having a viewbox attribute at all.
c. If you have a viewPort the size of a deck of cards, but the SVG image is the size of a cereal box, then increasing the viewBox "x y …" numbers will move the cereal box image up/left in the viewPort, showing a different part of the cereal box's image. This would be useful with sprites
d. (Usually (always!) the SVG element is also inside an HTML container - a div, p, section, li, whatever. We didn't discuss this, but remember it. If your image is being cut off, then either the viewBox is larger than the viewPort -OR- the HTML container element (div, etc) is smaller than the viewPort)
Here are two (excellent!) short videos, referred to us by the author of this answer within this same thread:
2min video demo
5min video demo (same guy, much better)
Here's a non-technical way of illustrating the relationship between width, height and the viewBox:
If you had any old image on your computer with the dimensions 1500 x 1000, and you pinched the corner of the image and resized it to 300 x 200, the image would shrink, or scale down (assuming scaling is enabled). The opposite is also true.
A good rule of thumb is to always look at the viewBox width and height first, and compare it to the SVG's width and height (or the parent's width and height if they are not declared in the SVG). That way you can tell whether the SVG image will scale up (grow), or down (shrink).
<svg width="300px" height="200px" viewBox="0 0 1500 1000">
The above is telling the browser that you have an SVG that's 1500 x 1000 but you want it to "pinch the corners" and shrink it down to 300 x 200.
viewbox is a ratio
In my humble experience, I've always considered <svg>’s viewbox values as a required image ratio to apply to the width and height values. While defining the laters just I do with any <img> in the DOM, either inline HTML properties or via CSS, viewbox property only applies to the SVG file.