[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