Re: resize/zoom ?

>> 1) In case of zoom-in, would this preserve the quality of the image ?
> Wrap SVG in SVG... intelligent pre-processing (e.g. only include the
parts likely to be included in the view)
Sorry, I didn't understand how you mean that. Are you saying
a) I should preprocess the xml-like svg and insert a viewbox there as an
xml-attribute ?
b) I should preprocess the read svg by the SVG ? If, yes, do you have any
example ?


3) http://www.graphicsmagick.org/api/types.html -> tile_info seems to be
never ever used in any svg application?

Am Do., 3. Dez. 2020 um 17:22 Uhr schrieb Bob Friesenhahn <
[email protected]>:

> On Thu, 3 Dec 2020, Pro Turm wrote:
>
> >> 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.
> > 1) In case of zoom-in, would this preserve the quality of the image ?
> > 2) My problem with the density approach on the whole image is that it
> would
> > blow up at some point (the limit of memory e.g.) and inefficiency (cpu
> > time). Suppose I would like to zoom in 20x, would I need to create a
> whole
> > 20x dense image (and why not only part of it)?
>
> That is why you would want to do everything in SVG space.  Wrap SVG in
> SVG.  It would still be wasteful since all of the drawing requests
> would be considered but only the "visible" part would end up being
> rendered (the rest would be clipped).  With any such approach, only so
> much can be done at once so it seems like intelligent pre-processing
> (e.g. only include the parts likely to be included in the view) is
> likely required.
>
> When doing vector rendering, rendering to a different scale does
> produce the normally desired level of refinement.  Things like "blocky
> artifacts" do not appear.
>
> >> I am not aware of a way to easily accomplish this other than to render
> > the whole SVG to a raster image and then crop the portion you want from
> > it.
> > Here arises my problem with the 20x zoom-in.
>
> There are obviously many choices to be made and lots of
> testing/evaluation to do.  Only you know your requirements and the
> possible varations you are facing.  The final result is ultimately
> your own responsibility.  If you are not happy, please let me know
> where I may send your refund. ;-)
>
> If worst comes to worst you might need to turn to commercially
> available solutions costing at least tens of thousands of dollars.
>
> >> Otherwise, you would need to be able to modify the SVG itself so it only
> > renders the desired portion.
> > I would like to have only one SVG on which to operate. Changing it would
> > mean parsing, adding, replacing IO operations. Which is not completely
> > magick... Does no GIS have ever used GM/IM yet? GISs have tiles.
>
> I don't have any personal experience with GIS.  I do know that with
> many systems, there are multiple pre-rendered resolutions and the
> tiles are stored in a compressed raster format.  Tiles could be
> individual files, or from multi-resolution tiled TIFF, or from
> proprietary file formats.  Obviously systems like Google Earth are
> doing better than that.
>
> Since you mention GIS, I assume that you have taken a look at GDAL
> (https://gdal.org/) which is a library for raster and vector
> geospatial data formats.
>
> 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
>
>
> _______________________________________________
> Graphicsmagick-help mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/graphicsmagick-help
>

_______________________________________________
Graphicsmagick-help mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/graphicsmagick-help