On Mon, 12 Jun 2006 22:38:23 +0100, "Charles Moir" wrote: > > Same works with our fills. You can say 'I understand linear and radial > fills but nothing else' and our filter system rasterises more complex > fills as bitmap fills inside bezier paths. > This sounds very useful indeed. > Carl, when Cairo talks to its PDF and SVG backends do you pass through > transparency and blend mode information. If so this would this would be > very interesting indeed, as it would be a means to producing > un-flattened vector output (whereas our existing EPS and PS printing > solution will rasterise all transparency). That would be very cool > because we'd get not just three filters for the price of one, but it > would be nice clean vector objects with vector grad fills and > transparency. Yes, we do pass transparency through when possible for PDF and SVG. For PDF, we aren't currently supporting native gradient fills, (though we should be---we had some code that was functional for many cases, but we ended up turning it off rather than just characterizing which fills it handles properly). Other than that, any blending with the default OVER compositing operator will be passed through natively to PDF. For SVG, we're already doing better than that. We're supporting all of cairo's gradients. And if the user is targeting SVG 1.2, then we spit out native SVG for all of cairo's Porter/Duff compositing operators. For SVG 1.1, we do like we do in PDF and use image fallbacks for any compositing operator other than OVER. So we've got a similar system of capabilities and fallbacks compared to Xara. Ours is still all in-library and the capabilities are open-coded rather than encapsulated in chunks of XML. Oh, and there's a tiny bit of code missing for doing the minimal-region stuff when image-based fallbacks are necessary. Right now, cairo will always emit full-page images as soon as any fallbacks are needed on a page. Obviously, we'll be fixing that before too long. -Carl
Attachment:
pgpx9N4z5bMXF.pgp
Description: PGP signature