[cairo] Call for unresolved issues (and planning for 1.4)

[Bill Spitzak]

Any chance of looking into the change so that stroke width, font, dash, 
etc are all fixed in device space at the moment they are set, and not 
effected by further transforms? I forgot what you called this but it 
certainly was discussed before.

Currently I am unable to use Cairo's transforms (except for translation) 
due to this, and I suspect this is true of any program attempting to do 
line drawings. Also it is inconsistent with how clipping and source 
patterns are done.

Just a dump of ideas that came up in the previous mailing list about this:

All data is stored in device space. All data sent (like glyphs 
positions) are in ctm space and are immediatly translated to device 
space. Setting things when the ctm is degenerate is legal.

All "queries" would be translated by the inverse of the ctm. Thus the 
output would  be reusable as input and produce the same results, if you 
ignore rounding errors. Queries when the ctm is degenerate would be an 
error?

The pen would have to have 4 numbers defining an affine transform so 
that the query could really return the current state. Dashes should be 
defined in this pen space, however a "dash multiplier" would be set 
independently and used to emulate the current line width and dash api. 
Stroke must work if the ctm is degenerate, this is probably easy. Also 
it looks like degenerate pens (which are lines) should work, this seems 
to require special code.

Pango would be greatly helped by a "set_font_ctm(x,y)" function, which 
would replace the ctm with the current font ctm plus a translation so 
the origin is at the point x,y translated by the current ctm. This could 
be done without a new api but any alternative would fail if the ctm or 
font ctm are degenerate.

Carl Worth wrote:

> I'd be interested in hearing what people would definitely like to see
> still happen before 1.4.0.