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

[Carl Worth]

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).

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?

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20060502/2944dc06/attachment.pgp