[cairo] [RFC] cairo_path_extents()

[Carl Worth]

On Mon, 21 Jan 2008 12:25:31 -0800, Carl Worth wrote:
> I was just about to push what I've got, but I noticed that the
> get-path-extents test is failing. I assume it's working for you? Or
> was there perhaps just a typo in entering some of the expected values?
>
> I'll look closer now, but here's what I'm getting:
>
> Testing get-path-extents with image target (dev offset 0)
> Error: Text; path extents (0.000000, 0.000000) x (288.000000,
> 13.000000) should equal (0.000000, 0.000000) x (286.000000, 13.000000)

OK, this one is interesting.

It's not a typo, since the new testing doesn't add any literal
values---it's simply checking to ensure that cairo_path_extents
returns the same values as cairo_text_extents.

The difference comes about because cairo_text_path is adding a
trailing move_to to the path in order to account for the advance,
(this is the toy layout that can be done with multiple calls to
cairo_show_text in series, for example).

So the semantic question for the API is:

	Should cairo_path_extents consider a lone move_to when
	computing its extents?

And I'm not entirely sure about that. If we answer yet, it seems to
put us in the tricky spot of having to answer whether a sequence of
cairo_move_to calls will store each MOVE_TO in the path or
not. Previously, no cairo calls would care whether or not these were
condensed into one, (except for cairo_copy_path of course, where the
user can explicitly see whether the condensing is happening).

I'm inclined to think that the lone move_to should not count. But I'm
not quite sure how to justify that. Any argument based on lack of
"ink" from a bare move_to doesn't hold much weight since the whole
point of cairo_path_extents as distinct from cairo_fill_extents is
that the former doesn't care about "ink".

There is the alternate definition of cairo_path_extents, (which
incidentally I had just added to the documentation), which is that
cairo_path_extents is equivalent to cairo_stroke_extents as the line
width approaches (but never reaches) zero. With that definition, then
a degenerate move_to;line_to pair to the same point should be
considered for cairo_path_extents but a bare move_to should not be.

Shall we just go with that? Anyone have an argument why we shouldn't?

With this definition, if someone has a use case where they really
*want* individual points to be considered for cairo_path_extents, then
they can do cairo_move_to;cairo_line_to in the same way that people do
that for drawing non-zero-sized "dots" with cairo_stroke.

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20080121/1464c35c/attachment.pgp