[cairo] Problems with cairo_get_line_width and "new" semantics

[Carl Worth]

On Tue, 16 May 2006 14:42:08 -0700, Bill Spitzak wrote:
> 
> Better proposal for dashes to make pens only be a matrix:
> 

Thanks for bringing up dashes since I hadn't tested this.

The dash-allotment code was previously parceling out dashes by
transforming device-space segments to user space (at the time of the
stroke) computing the next dash length in that space, and then
transforming that back to device space.

So when I made the changes for the line-width-scale branch I changed
this to use the pen matrix rather than the CTM.

But know you've got me thinking about whether that's the right matrix
to use.

I checked the documentation for cairo_set_dash and what we say there
is that the numbers represent user-space lengths. So, in 1.0 this was
user space at the time of the call to cairo_stroke. In my
line-width-scale branch it is user space at the time of a call to
cairo_set_line_width (and something else in the case of cairo_set_pen
though I won't bother with that one since I think it does not have the
semantics that have been discussed most recently).

So the trend lately has been to make graphics-state operations lock
the CTM at the time of the operation. So we could do dash dispensing
in the user space that was active at the time of cairo_set_dash.

It turns out the patch to do this was pretty easy. I did it on top of
my current line-width-scale branch and the patch can be seen here:

http://gitweb.cairographics.org/?p=users-cworth-cairo;a=commitdiff;h=82124df976639de6b9153f53b2f1564746c1d851

That adds a test case demonstrating the ability to independently
transform the path, the pen, and the dash allotment, which seems like
rather pleasant flexibility. The results of the image backend can be
seen here:

http://cairographics.org/~cworth/images/dash-scale-image-argb32-out.png

However, none of the current PS, PDF, and SVG backends can handle this
test case. In every case where the dashing and the pen are transformed
differently, the dashing is alloted as if subject to the pen's
transformation:

http://cairographics.org/~cworth/images/dash-scale-svg-argb32-out.png

So we're definitely straying beyond the capabilities of those models
with this. But we could also easily detect when the dash_matrix and
the pen_matrix do not match and do this manually. We could do
image-based fallbacks right away, or even nasty filled, tessellated
trapezoids. Down the road, the proper fallback for this would be a
single filled path for all the dashed elements of the stroke.

So, what do people think? Is it worth throwing in this extra
capability? Or am I going to far? Does anyone even care about
transformed dashing at this level of detail?

-Carl

> cairo_set_dashscale(,n) stores this number, and multiplies the current 
> dash pattern by the ratio between this and the previous one (? if this 
> is what back-compatability requires).

PS. I couldn't mask sense of what dashscale would do, nor why it would
be needed exactly.
-------------- 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/20060519/c2e76008/attachment-0001.pgp