This is a spin-off from bug #111152. See the discussion on printing there.

Continued from the previous bug... > Hey - we could port libart to postscript. Any FORTH programmers out there? ;-) Fair point. Although presumably PS already has *most* of the primitives we need, so the reductio isn't quite as absurdum as it sounds. I do agree that it's not necessarily what we actually want to *do*, though :) > Maybe we could even go for some 'capped resolution' scheme, where we make the > max image size a user preference and adjust the resolution accordingly. This > scheme would ensure that in those cases where the SVG image is small, we get > the best possible resolution. (I'm beginning to develop mpt's reflexive negative response when somebody says "add a preference", as I see more and more bugs where that's advocated as a solution to something...) I think that instead of capping the resolution based on the image size, it would be better to cap it based on the size of the eventual print job that would result, and use some kind of introspection on the printer to determine that. Presumably ghostscript, for example, could handle an almost arbitrarily large print job if printing to a non-postscript printer, and rasterize it in chunks. Does PDF support alpha? I wonder if we could print to PDF and then use some kind of open source PDF printing software (which I think is something that exists) - ie throw the problem at someone else to solve :) Just throwing ideas out there...

Fixing Platform/OS - AFAIK this issue/discussion is crossplatform for now...

>> Hey - we could port libart to postscript. Any FORTH programmers out there? ;- ) >Fair point. Although presumably PS already has *most* of the primitives we > need, so the reductio isn't quite as absurdum as it sounds. I do agree that > it's not necessarily what we actually want to *do*, though :) Sorry if this came across a bit sarcastic. I have no doubt that adding alpha->stipple is feasible, it is just that I think that it wouldn't solve any of our problems. Printing to PS isn't the problem; printing to anything is. In most instances our final destination isn't a postscript capable device. This fact coupled with the realization that postscript isn't really a good language to describe svg, makes me wonder why we are arguing about PS in the first place. Surely neither do we want to special-case the SVG code for PS, nor make nsIRenderingContext a postscript interpreter. In the long term, let's rather make nsIRenderingContext an API tailored to SVG. > I think that instead of capping the resolution based on the image size, it > would be better to cap it based on the size of the eventual print job that > would result, and use some kind of introspection on the printer to determine > that. Presumably ghostscript, for example, could handle an almost arbitrarily > large print job if printing to a non-postscript printer, and rasterize it in > chunks. Well, that sounds even better. Now we just need to find a volunteer. Hint, hint ;-)

[postscript isn't really a good language to describe svg] Only in terms of transparency. Otherwise, PS is an excellent language to describe SVG. PS supports all of the SVG primitives. Why not implement at least an interim solution where SVG prints to PS using vectors, ignoring transparency entirely? [Does PDF support alpha?] PDF 1.4 does support all kinds of alpha transparency. But currently we don't have a gfx layer to PDF (I don't think), so that's somewhat beside the point. [neither do we want to special-case the SVG code for PS, nor make nsIRenderingContext a postscript interpreter. In the long term, let's rather make nsIRenderingContext an API tailored to SVG.] Rather, the SVG code is currently special-cased for bitmaps, and really needs to be abstracted. Libart should be attached to the cross-platform GFX layer, accessible through nsIRenderingContext. For example, we don't need to use libart at all on OSX aqua, because it has native support for transparency, and if one were to extend gfx for PDF, the same would apply.

[postscript isn't really a good language to describe svg] Only in terms of transparency. Otherwise, PS is an excellent language to describe SVG. PS supports all of the SVG primitives. Why not implement at least an interim solution where SVG prints to PS using vectors, ignoring transparency entirely? [Does PDF support alpha?] PDF 1.4 does support all kinds of alpha transparency. But currently we don't have a gfx layer to PDF (I don't think), so that's somewhat beside the point. [neither do we want to special-case the SVG code for PS, nor make nsIRenderingContext a postscript interpreter. In the long term, let's rather make nsIRenderingContext an API tailored to SVG.] Rather, the SVG code is currently special-cased for bitmaps, and really needs to be abstracted. Libart should be attached to the cross-platform GFX layer, accessible through nsIRenderingContext. For example, we don't need to use libart at all on OSX aqua, because it has native support for transparency, and if one were to extend gfx for PDF, the same would apply.

As far as I am concerned this bug is now fixed on branch SVG_20020806_BRANCH, but as Roland pointed out on bug#182533, issues with large print-outs remain. The rendering backend is now pluggable and supports native and cross-platform renderers. The two renderers implemented so far are a libart-based one and a gdi+ based one. Libart prints by composing to an in-memory bitmap, which will break in extreme cases, like printing at full resolution to an DIN-A1 page. I don't think there's much that can be done about that, except maybe printing in small banded chunks. If anyone wants to look at that maybe we should open another more specific bug on that. In the gdi+ backend we render to whatever surface gfx gives us, but I suppose behind the scenes pretty much the same as in Libart happens. If there are ways to improve that, I again suggest opening a specific bug on that. Finally, with the backend now pluggable, we could look at implementing a postscript rendering backend. Again, if there are any takers, I suggest opening a specific bug on that. If you want to have a look at the interfaces that need to be implemented by an SVG renderer, they are located in layout/svg/renderer/public/ on branch SVG_20020806_BRANCH.

Bug 182533 has landed, so marking this bug fixed as per comment #6

Mozilla1.8b1 cairo-0.3.0 on Linux crash. Open http://www.croczilla.com/svg/samples/butterfly/butterfly.svg and print.