Jason Dorje Short | 30 Jun 03:37 2005
Picon

redesigning the arguments for svg2png

Current arguments for svg2png:

  -w $WIDTH
  -h $HEIGHT
  -s $SCALE
  -x, --flipx
  -y, --flipy
  input.svg and output.png are taken directly as parameters

This is all explained in `man svg2png`.  The problem is it's incomplete.

----------

For instance if you give -w and -h svg2png makes an image with the given
$WIDTH and $HEIGHT and puts the SVG file inside it with preserved aspect
ratio.  Thus there is no distortion and there is padding.

One thing I need to do is to change the aspect ratio.  I want to give a
width and height and have the SVG "stretch" to take up this whole area.
 Thus the xscale and yscale are different.  Thus there is distortion and
there's no padding.  This is what rsvg, sodipodi, and inkscape
command-line renderers do.

A third thing one would want to do is preserve the aspect ratio but
without any padding.  Thus the $WIDTH and $HEIGHT provide the max
dimensions, just like svg2png does now, but without any padding.  Thus
there is no distortion and there is no padding.  IIRC this is what the
librsvg rsvg_pixbuf_from_file_at_max_size function does (which I've
found very useful in the past).

(Continue reading)

Jason Dorje Short | 9 Jul 05:27 2005
Picon

Re: redesigning the arguments for svg2png

Jason Dorje Short wrote:

> Thus I suggest:
> 
>   --width=$WIDTH (-w)
>   --height=$HEIGHT (-h)
>   --xscale=$X_SCALE (-x)
>   --yscale=$Y_SCALE (-y)
>   --flipx (-X maybe?)
>   --flipy (-Y maybe?)
>   --scale=$SCALE (-s)
>   --dpi=$DPI (-d)
>   --pad [1]
>   --stretch

Here is a complete patch that implements this (except --dpi which isn't
possible).  I also updated the manpage.

Note that --xscale is ignored if --width or --height is given.  I'm not
positive this is the best behavior.  For instance you might want to say
--xscale=0.5 with --height=50 to change the aspect ratio while also
setting the height, but as it is you cannot do this.  You'd instead have
to do --xscale=0.42 and --yscale=0.84 (or whatever) to get the exact
right size and aspect ratio you want.  (Of course this behavior wasn't
possible before either.)

Another thing I changed is that svg2png no longer defaults to using
stdin and stdout; you have to tell it explicitly.  This means if you
just run "svg2png" you'll get the more reasonable behavior of a usage
summary.
(Continue reading)

Carl Worth | 4 Aug 19:58 2005

Re: redesigning the arguments for svg2png

Hi Jason,

I'm sorry I haven't responded to this before now.

On Fri, 08 Jul 2005 23:27:20 -0400, Jason Dorje Short wrote:
> > Thus I suggest:
> > 
> >   --width=$WIDTH (-w)
> >   --height=$HEIGHT (-h)
> >   --xscale=$X_SCALE (-x)
> >   --yscale=$Y_SCALE (-y)
> >   --flipx (-X maybe?)
> >   --flipy (-Y maybe?)
> >   --scale=$SCALE (-s)
> >   --dpi=$DPI (-d)
> >   --pad [1]
> >   --stretch

Those all look really great to me.

> Here is a complete patch that implements this (except --dpi which isn't
> possible).  I also updated the manpage.

Why don't we just set you up with commit access and then you can own
the command-line interface for this program. You seems to have done a
better job of interface design than I have.

And then you could also go commit your DPI fixes for libsvg-cairo and
add the missing --dpi option.

(Continue reading)

Jason Dorje Short | 13 Aug 11:11 2005
Picon

controlling the DPI in libsvg and friends

This next patch adds user control of the DPI to libsvg, libsvg-cairo, 
and svg2png.  DPI must be the same in X and Y dimensions (this wouldn't 
be hard to separate but would complicate the interface more).

* libsvg gets a new function, svg_set_dpi.  This function probably needs 
to be called before parsing the SVG, but I don't see how to check this. 
  Changing the DPI later will probably give bizarre results.  I 
considered making it a part of svg_create but then we'd need to use -1 
for the "default"

   svg_create(&svg, -1);   // default resolution
   svg_create(&svg, 90);   // 90 DPI
   svg_create(&svg, 300);  // 300 DPI

and the API would become incompatible (all users would have to be 
fixed).  One alternative would be a new function svg_create_at_dpi (or 
svg_create_full).

* libsvg-cairo gets a wrapper, svg_cairo_set_dpi.  The same caveats apply.

* svg2png is given a new parameter --dpi.  Note that most SVG files 
(including all created with inkscape AFAICT) will not operate 
exclusively in distance measurements.  Even if you tell inkscape to use 
inches as its default unit everything is still saved in pixels. 
Attached is a simple SVG that is all in inches.  Using --dpi with this 
does work.  This would be useful for rendering into a resolution for 
printing (for instance). The -d option is also compatible with 
inkscape's command-line interface (rsvg does separate X and Y dpi setting).

* xsvg could probably use a similar option, but I haven't looked into that.
(Continue reading)

Carl Worth | 13 Aug 11:31 2005

Re: controlling the DPI in libsvg and friends

On Sat, 13 Aug 2005 05:11:53 -0400, Jason Dorje Short wrote:
> * libsvg gets a new function, svg_set_dpi.  This function probably needs 
> to be called before parsing the SVG, but I don't see how to check this. 

That seems to be a reasonable requirement, and it shouldn't be too
hard to detect a late call if you really cared to.

> * svg2png is given a new parameter --dpi.  Note that most SVG files 
> (including all created with inkscape AFAICT) will not operate 
> exclusively in distance measurements.  Even if you tell inkscape to use 
> inches as its default unit everything is still saved in pixels. 
> Attached is a simple SVG that is all in inches.  Using --dpi with this 
> does work.  This would be useful for rendering into a resolution for 
> printing (for instance). The -d option is also compatible with 
> inkscape's command-line interface (rsvg does separate X and Y dpi
> setting).

I had made the suggestion of making a file that entirely uses absolute
unit identifiers as you have done here. While this particular file
looks just fine, it was pointed out elsewhere in the thread that this
isn't a suitable solution in the general case since the path data
coordinates cannot accept absolute unit identifiers.

A much more compelling solution is to use absolute unit identifiers on
the top-level width and height attributes, add a viewBox attribute to
set the scaling bounds, and then avoid the use of absolute unit
identifiers throughout the file. Thanks to mental for this solution:

http://lists.freedesktop.org/archives/cairo/2005-June/004378.html

(Continue reading)


Gmane