[cairo] Re: API Change[!] proposal: cairo_surface_set_fallback_resolution

[Christian Biesinger]

Carl Worth wrote:
> Here's what I came up with. It should be right, (since it's easier to
> get the right behavior by calling into functions rather than grubby
> around inside the structures).

But is this also right if the surface_to_backend matrix has a scale part?

> Now, with that I'm seeing 11 test failures of the SVG backend. I don't
> think these were there just before this branch, (text in particular is
> getting really scrambled), so that's worth looking at.

OK, I'll try to look at them sometime soon.

> Another thing is that the test suite only calls the various set_dpi
> functions with a single value of 72.0.

Yeah. Maybe the testsuite should just run with 300 DPI or something? But 
I guess that'd change the output, so need new test images, which would 
be unfortunate.

> I think it would be worthwhile
> to write a tiny test that did some some easy-to-see, huge-blockiness
> kind of rendering with various small values of set_dpi to ensure its
> working.

Might be enough to just render to 3 different files and compare them to 
reference images? Then it doesn't necessarily need to be easy to see, 
although that's probably a bonus :)

> 1) These functions are replicated as backend-specific functions across
>    the ps, pdf, and svg backends. Yet the semantics are identical for
>    all three, and we would expect any backend using paginated/analysis
>    surface to want to provide the same kind of control of fallback
>    resolution. In fact the implementation on this branch makes it
>    quite clear that the functionality here belongs in paginated
>    surface, and not in the target backends.

Probably all vector backends would want this, not just those using 
paginated, although the two sets are identical at the moment.

> I propose eliminating all three of these functions:
> 
> 	cairo_pdf_surface_set_dpi
> 	cairo_ps_surface_set_dpi
> 	cairo_svg_surface_set_dpi
> 
> and instead implementing a single new function:
> 
> 	cairo_surface_set_fallback_resolution

That sounds like a great idea to me!

> (which is the naming that the implementation is already starting to
> use anyway).

Yeah, but my branch didn't export that name :-)

> I think we could document this function has applying only to "image
> fallbacks" for "vector backends" and that it would have no effect on
> "raster backends", (and it could even provide a list of example
> backends for each category there).

The documentation should then probably state explicitly for each backend 
whether it's a raster or vector one.

> Finally, if we do that, it would be good to let the
> fallback_resolution naming propagate throughout the implementation,
> replacing "dpi" wherever appropriate.

dpi has the nice feature that it's short, and a known abbreviation. How 
would you call x_dpi? x_fallback_res is kind of long...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4762 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.freedesktop.org/archives/cairo/attachments/20060505/883cd320/smime.bin