[cairo] Adventures in line widths

[Bill Spitzak]

Actually I was suggesting this a long time ago, but perhaps my 
description was not clear. I thought the idea had been considered and 
rejected.

I was more concerned with fonts, but the same idea applies. It would be 
nice to select a pen, font, source image, etc, and then be able to use 
Cairo's transformation matrix to produce scaled, translated, or rotated 
paths, without the font changing size or orientation or the pen changing 
width. Currently I suspect illustrator-style programs are unable to use 
Cairo's transformations except to set up an initial scale between their 
graphics and the output, and they then do all the transformations of 
their objects themselves.

This is also necessary if Cairo is to do 3D transformations. Otherwise 
the only consistent way to do it is to render the pen and font in 3D 
somehow, which is complicated and also probably not a desirable effect 
(and it could be replicated by drawing a 2D surface and projecting 
that). With this a 3D Cairo could be used to draw a wireframe 3D object 
with a fixed (ie illustrator-style) pen, and label all the corners with 
readable text. Attempting to set the pen or font when a 3D transform is 
in effect can either fail, or produce a similar 2D transform by ignoring 
the perspective portion of the matrix.

I would also guess this would be much more efficient. Only the 
device-space result of the current pen and font need to be kept, and 
these only need to be calculated when the pen or font are changed, 
rather than recalculated (or invalidated) each time the transformation 
changes.

Another advantage is that this is the way OpenGL works, and I think 
(though I am not certain) this is also the model used by DirectX and 
GDI+. This means translating such programs to Cairo would be much 
easier, and also that Cairo may be more able to use hardware designed 
for DirectX.

I figured the idea was rejected. The main problem I see is that it is 
incompatable with PostScript, and perhaps with PDF? Also there are 
workarounds, by either using gsave/grestore calls or by doing the 
transforms yourself.

But if you are considering it, I am all for it!

Carl Worth wrote:

> But, the ambiguity is the precise meaning of "user space" in the
> documentation above. Currently, the implementation is using the user
> space at the time of cairo_stroke. I contend that that is a bug and
> that cairo_set_line_width should use the current user space at the
> time of that call.
> 
> Changing this behavior would make cairo_set_line_width consistent with
> things like cairo_set_source that "lock" the current CTM regardless of
> the fact that the source pattern will actually be used by some later
> drawing operation that is operating under a different user space.