Thread: SVG developments

Originally Posted by Alain57

Of course, it is preferable to respect the dimensions provided by the various original files .......

Of course, 100 is closer to 60 for reducing and reading by the program, and if the files are close to the original sizes, then the program will spend less time resizing the image. The question is different, I suspect that the time to reduce the picture is almost negligible. Therefore, I think the canvas size is not important, but the file size is important.

Originally Posted by Andrey Form

Of course, 100 is closer to 60 for reducing and reading by the program, and if the files are close to the original sizes, then the program will spend less time resizing the image. The question is different, I suspect that the time to reduce the picture is almost negligible.

I'm a bit confused over this discussion. Isn't SVG the acronym of "Scalable Vector Graphic"? This by design has no "resolution". As the name suggests, it contains vectors not pixels and it is scalable by definition. It may have a scaling factor as a hint how big it is meant to be when rendered to the physical world. This is usually some sort of "mm" not "pixel". Coordinate points are floating-pont, not integer. It is a matter of moving the decimal point when an image is defined as 100x100 or 1x1. The graphic is essentially the same with no loss of "resolution".

How these vectors are translated into pixels is determined by the rendering software that has knowledge about the physical resolution of the output device - in case the dimensions of "mm" should be matched at all.

If rendered on a laser printer, it might turn out as 1200 DPI or more giving a lot more pixels (and sharpness) per mm dimension than the same image rendered on an old TFT screen of 640x480 pixels.

Any software rendering VECTOR graphics into a pre defined layout space should chose to fit the image coordinates within the available space, so that no coordinate falls outside = proportional. Scaling = multiplying each coordinate with a fixed value to match image "dimension" to the actual screen space on the device. Failing to fit any SVG into a defined "icon space", I would consider as software bug.

Depending on the programmer this can be done just once and then cache the pixel map suitable for the current display, or it may be rendered on the fly, if the processor is capable enough. That's the idea of creating an SVG. You do the work just once in all detail and leave it to the rendering engine to make best use of it. Low resolution devices certainly will miss details over high resolution ones, so a good design does not depend on tiny details like tiny text that might get scaled down to just unreadable mud.

What might make a difference is how many decimals are in the file for each vector coordinate as it does affect file size and load time. With four significant digits, any "icon" should render perfectly sharp on any current or future PND display in any size.

Said that, it IS possible that an SVG can contain rasterized content, like a photo, which cannot otherwise be expressed with good results by vectors, polygons and filled shapes. But this not how SVG is thought to be used.