Re: resize/zoom ?

On Thu, 3 Dec 2020, Pro Turm wrote:

> 2) is it possible to resize/zoom the mvg (i.e. vector based, and not raster
> based) ?

Normally I would say that the density value (default 72 DPI) would 
influence the size (and I think it still does in some cases), but it 
appears that the -size value (image_info->size) controls the resulting 
size.

So (testing with command line) I see this:

% gm convert golfer.svg info:-
golfer.svg MVG 576x698+0+0 DirectClass 16-bit 0.847u 0m:0.413323s (949.9Ki pixels/s)

% gm convert -size 2000x2000 golfer.svg info:-
golfer.svg MVG 1650x2000+0+0 DirectClass 16-bit 4.131u 0m:0.633493s (5.0Mi pixels/s)

% gm convert -size '2000x2000!' golfer.svg info:-
golfer.svg MVG 2000x2000+0+0 DirectClass 16-bit 4.411u 0m:0.610275s (6.3Mi pixels/s)

At the top of ReadSVGImage() in coders/svg.c there is this comment:

   /*
     If there is a geometry string in image_info->size (e.g., gm convert
     -size "50x50%" in.svg out.png), AllocateImage() sets image->columns
     and image->rows to the width and height values from the size string.
     However, this makes no sense if the size string was something like
     "50x50%" (we'll get columns = rows = 50).  So we set columns and
     rows to 0 here, which is the same as if no size string was supplied
     by the client.  This also results in svg_info.bounds to be set to
     0,0 below (i.e., unknown), so that svg_info.bounds will be set using
     the image size information from either the svg "canvas" width/height
     or from the viewbox.  Later, variable "page" is set from
     svg_info->bounds. Then the geometry string in image_info->size gets
     applied to the (now known) "page" width and height when
     SvgStartElement() calls GetMagickGeometry(), and the intended result
     is obtained.
   */

I do see that density (which becomes image->x_resolution and 
image->y_resolution after being parsed) is used to set the initial 
affine scaling values around line 3885 of svg.c.  These values are set 
before the SVG file is parsed at all.  The SVG file may contain a 
viewbox statement, and its own internal scaling directives.

Using the raster-based resize algorithm such as ZoomImage() would be 
the wrong way to deal with a vector-based format like SVG.  It is much 
better to render directly to the desired size.

Bob
-- 
Bob Friesenhahn
[email protected], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
Public Key,     http://www.simplesystems.org/users/bfriesen/public-key.txt