[cairo] [RFC] cairo_path_extents()

[Behdad Esfahbod]

On Mon, 2008-01-21 at 16:24 -0500, Carl Worth wrote:
> 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.

Thanks for tracking down.

> 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).

Ah I see.

> So the semantic question for the API is:
> 
> 	Should cairo_path_extents consider a lone move_to when
> 	computing its extents?

To keep it simple, no.


> 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.

All agreed.  Please document it as such (including the
move_to();rel_line_to(0,0) trick.  And I'm sure you added that to test
suite already :).


> -Carl
-- 
behdad
http://behdad.org/

"Those who would give up Essential Liberty to purchase a little
 Temporary Safety, deserve neither Liberty nor Safety."
        -- Benjamin Franklin, 1759