[cairo] [API] Accept NULL for cairo_(pdf|ps|svg)_surface_create

Behdad Esfahbod behdad at behdad.org
Thu Oct 16 09:29:40 PDT 2008


Dominic Lachowicz wrote:
> Hi Chris,
> 
> On Wed, Oct 15, 2008 at 5:56 PM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
>> On IRC, Behdad bemoaned the lack of support in the current API for
>> cairo_pdf_surface_create(NULL, 0, 0). The use case here is querying the
>> target backend for its font options and for measuring the extents of
>> operations, prior to creating the real surface.
> 
> Can't one achieve Behdad's semantic using the create_for_stream()
> variant with a no-op write func, without needing any changes to cairo?
> Creating a valid surface for a NULL filename seems wrong to me.

You actually have a good point except for the "without needing any changes to
cairo" part.  We do need a change to cairo, as currently both a NULL file name
and a NULL stream write function crash cairo.  So we need to fix them.  The
question here is whether to fix by CAIRO_STATUS_NULL_POINTER or by silently do
what user asked.

I kinda agree that a NULL filename is a bit messy, but I also think having to
declare a nop function just to pass to create_for_stream() is also messy.  So
I like being able to pass NULL to create_for_stream().  And if we allow that,
it would be more consistent to allow a NULL filename too.

One may suggest that we are being inconsistent about accepting or rejecting
NULL input.  The rule I've been following is: a NULL cairo_*_t pointer always
is an error.  Any other NULL pointer may be allowed.  That's why for example
we allow NULL text in cairo_show_text() while technically NULL is not valid
text.  In general, it happens to be mostly well-defined how to deal with NULL
pointers of non-cairo types, so I like allowing them.

Cheers,

behdad

> Best,
> Dom
> 


More information about the cairo mailing list