[cairo] What should the units of size be for an SVG surface?

[Emmanuel Pacaud]

Le mardi 02 mai 2006 à 11:14 -0700, Carl Worth a écrit :
> I guess I haven't ever properly reviewed the SVG surface interface
> closely enough yet, (sorry about that Emmanuel---I am very excited
> about this backend, but I just haven't had much time to play with it
> yet).
> 
> In a recent commit, I happened to notice the following function
> declaration:
> 
> > +cairo_public cairo_surface_t *
> >  cairo_svg_surface_create (const char   *filename,
> >  			  double	width_in_points,
> >  			  double	height_in_points);
> 
> I'm not sure that points are the correct units to use here.
> 
> I think that the driving convention in cairo for determining the units
> of the size in surface_create is the following:
> 
> 	1. Cairo's default transformation matrix transforms one
> 	user-space unit to one device-space unit.
> 
> So, for PS and PDF surfaces, by default we don't do any scaling of the
> coordinates the user provides until the user explicitly modifies the
> CTM, (this is ignoring the transformation we do to correct for the
> difference in origin placement and Y-axis direction between cairo and
> PS/PDF).
> 
> There's another convention for most existing surfaces, but it is
> perhaps weaker or perhaps just a result of the above convention:
> 
> 	2. The units of the surface passed to surface_create are
> 	device-space units.
> 
> So, for raster-based surfaces, (image, xlib, etc.) this is obviously
> integer pixels. And for PostScript and PDF, where an identity
> transform is one user-space unit to one point, we naturally end up
> with units of points for surface_create.
> 
> However, in SVG, an identity matrix does not map one user-space unit
> to one point. Instead one user-space unit maps to one "px" unit,
> (which I believe is defined in CSS2 with the intentionally vague
> notion of "arm's length", etc. to achieve a consistent size in angular
> viewing space).

Not necessarly. It depends on viewBox property. I've just pushed a patch
that at least makes SVG output consistent with current API
documentation, i.e. use point as user space unit. But I'm still open to
suggestions :)

> So I think we want to preserve the notion of an SVG surface's
> device-space units being px units, (that is, follow convention (1)
> above so that by default the SVG output will have an identity
> transformation in it).
> 
> But, of course, SVG also provides for using real-world, physical units
> for the width/height of the outermost <svg> tag, and it's definitely
> desirable to provide users the means of achieving that as well.
> 
> So perhaps we don't actually want to follow convention (2)
> here. Instead, perhaps in svg_surface_create we want to accept two
> double for width/height and then also accept a string value for the
> appropriate units, (and accept any of the units defined in the SVG
> specification)? If we do that, I would argue that we would still not
> want to modify the default CTM depending on the size, but still leave
> it as an identity matrix.
> 
> Any thoughts?

Specifying a unit when creating SVG surface seems trivial to implement.

	Emmanuel.