[cairo] Call for unresolved issues (and planning for 1.4)
spitzak at d2.com
Sun Jan 21 12:48:58 PST 2007
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
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.
More information about the cairo