[cairo] Coordinates

[Jonathan S. Chambers]

	As Carl said, the solution is not a simple transform. If I had
the solution, I'd tell you. Making a single line look how you want is
easy; anything beyond that and the effort required starts to become
exponential.

	Have I given up? No. Do I believe an elegant, one line solution
exists? No. 

- Jonathan

-----Original Message-----
From: cairo-bounces at cairographics.org
[mailto:cairo-bounces at cairographics.org] On Behalf Of Carl Worth
Sent: Thursday, December 01, 2005 1:03 PM
To: Mirza
Cc: cairo at cairographics.org
Subject: Re: [cairo] Coordinates

On Thu, 01 Dec 2005 16:06:17 +0100, Mirza wrote:
> Would it make sense to create "compatibility option" for how
coordinates 
> are interpreted? Most of legacy graphic code I saw assumes that
integer 
> coordinates, like (0, 0) are placed in the middle of the pixel, not 
> between pixels. Such global setting (non-default) would make life
easier 
> for people switching to Cairo from something else IMO.

Are you suggesting something more elaborate than the following?

	cairo_translate (cr, 0.5, 0.5);

If not, then that option exists already. If so, then I think that
although the idea seems tempting, I also think it's ill-advised.
Primarily because there's no simple operation that will "do what you
want" in all cases.

For example, let's assume cairo's default transformation matrix and
also assume that we're dealing only with axis-aligned, rectilinear
geometry specified with integer coordinates. With these assumptions,
the results that will be achieved depend on the operation performed:

fill:					Crisp, pixel-aligned results
stroke (even integer line width):	Crisp, pixel-aligned results
stroke (odd integer line width):	"Fuzzy", non-pixel-aligned

The (0.5, 0.5) translation above would change this to:

fill:					"Fuzzy", non-pixel-aligned
stroke (even integer line width):	"Fuzzy", non-pixel-aligned
stroke (odd integer line width):	Crisp, pixel-aligned results

So, at the very least, this operation would have to be more complex
than a simple translate, even with all of the simplifying assumptions
we made above. So any attempt to implement a "make my graphics look
good" operation is forced to become a very complex operation that will
in turn be hard for the user to predict/control, which is against the
grain of what cairo tries to provide the user.

Anecdotally, I've heard that Java2D attempted to use a different
half-pixel offset for strokes compared to fills, but eventually
abandoned the idea (with a fair amount of pain).

Finally, at the most fundamental level, the question of doing
pixel-aware alignment ("snapping") is global in nature and cannot be
adequately addressed within cairo's path rendering operations which
have access only to local information.

-Carl

PS. Jonathan Chambers might have some useful insight here as he been
working to try to emulate (non-antialiased) GDI operations as
accurately as possible with cairo. I don't know if he has entirely
succeeded with that yet, but if nothing else, I think he can attest
that the problem is more complex than something like a global
half-pixel offset.