[cairo] Re: API Change[!] proposal:
cbiesinger at web.de
Fri May 5 14:22:45 PDT 2006
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
> 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
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:
> and instead implementing a single new function:
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...
Size: 4762 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.freedesktop.org/archives/cairo/attachments/20060505/883cd320/smime.bin
More information about the cairo