[cairo] [PATCH] PS/PDF improve efficiency of text output
vladimirv at gmail.com
Mon Sep 25 09:57:56 PDT 2006
On 9/25/06, Mathieu Lacage <Mathieu.Lacage at sophia.inria.fr> wrote:
> On Sun, 2006-09-24 at 21:21 -0700, Vladimir Vukicevic wrote:
> > There can potentially be a ton of these options; I'd suggest a generic
> > cairo_surface_set_float_param or _set_int_param or _set_string_param
> > (or some better way of representing this)... I know Carl isn't a big
> > fan of such generic functions, but I think that this is more
> > preferable to having an explosion of API methods, whether in the
> > global namespace or in the surface namespace.
> What you are proposing is an explosion of parameter types. It would
> merely move the checking of whether or not a parameter is allowed for a
> given surface type to runtime checks rather than compile-time checks. If
> I had to choose, compile-time checks always win.
It absolutely does, that's the whole point. I don't really want to
create a dozen different API methods for tweaking various parameters
to the quartz surface, for example. Some of those parameters could
also easily be ignored if they're not supported, e.g. the set function
could return NOT_SUPPORTED or whatever to inform the caller of that.
Compile-time checking is nice, but come on, we're using C here. We've
already lost. There's little reason that compile time checking is
necessary for most of these minor parameters.
More information about the cairo