133964 - Need to implement SVG printing

Status: RESOLVED FIXED

(Core :: SVG, defect)

Description

[Alex Fritze]

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

Comment 1

[Stuart Ballard]

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...

Comment 2

[Roland Mainz]

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

Comment 3

[Alex Fritze]

>> 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 ;-)

Comment 4

[Benjamin Smedberg]

[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.

Comment 5

[Benjamin Smedberg]

[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.

Comment 6

[Alex Fritze]

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.

Comment 7

[Alex Fritze]

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

Comment 8

[Kalacheva Julia]

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