RFE: SVG should be printed via vector drawing commands to archive a better printing quality. Current code generates a bitmap and renders it on the printer device - and when the resulting print job gets scaled-up the bitmap shows scaling artifacts...
Per IRC comment... this is more or less a blocker for SVG stuff. Rendering SVG graphics as one large image via libart breaks print support in a very worse way... we would either get _huge_ (unuseable) print jobs - or print jobs with low quality... ;-(
Roland - The Mozilla nsIRenderingContext interface isn't powerful enough to render svg, so we have to compose to a pixmap using libart and then bitblt that to the Mozilla rendering context. All of that is currently encapsulated in nsSVGRenderingContext, with an interface that is still very much in flux. Once we are happy with our nsISVGRenderingContext interface, we can think about consolidating it with nsIRenderingContext. The vector printing will then fall out automatically on backends (such as ps) that support it. I don't really want to touch nsIRenderingContext until we are sure about the interface we want, though. Until that time it is probably not worth looking at the printing issue. :-( Having said that - why don't you help us on the SVG implementation so that we get there quicker? :-)
> The vector printing will then fall out automatically on > backends (such as ps) that support it One hint: There is more than one print system on Unix. PostScript (gfx/src/ps/) is the default one, Xprint (gfx/src/xprint/) the 2nd one... > Having said that - why don't you help us on the SVG implementation so that we > get there quicker? :-) Sure... it would be nice if I can pull it with the standard tarball... when will SVG be "ready" for that ?
> Sure... it would be nice if I can pull it with the standard tarball... when will > SVG be "ready" for that ? That's what I'd like to know as well ;-)
Alex: Another hint: Print stuff does not know about "hidden" drawing surfaces (which may be used for alpha support etc.). Only PCL5 can do that, PCL3 and PostScript2/3 do not allow that (and nsRenderingContextPS and the Xprint version of nsRenderingContextXlib do not implement that for the same reason).
-> default component owner, and future.
Assignee: dean.jackson → alex.fritze
QA Contact: dean.jackson → bbaetz
Target Milestone: --- → Future
Is there any better milestone than "Future" ? Printing SVG not as vector graphics (e.g. as one large image) makes it impossible to print it - except you have some GB of main memory ...
Well, it doesn't print at all ATM - did you ever file that bug? In theory its possible, but in practice probably not without some extra work. I really really doubt that you need a gig of RAM. We use the device's dpi setting, so if that is correct, then scaling shouldn't be needed Feel free to attach a patch, though
Roland, we haven't implemented even the most basic parts of SVG yet, so let alone printing. If you volunteer to fix it, then reassign to yourself, otherwise, this will probably have to wait until someone else wants to fix it or Alex considers it priority.
It may be usefull to think "now" about the requirements for printer output, otherwise a "later" implementation for printer output may require much more work (or make it impossible because noone wants to do it) ...
Bradley Baetz wrote: > Well, it doesn't print at all ATM - did you ever file that bug? Uhm... didn't I say "file a bug and CC: me ?". Oh well... confusion... :-) Biggest problem is that libart is AFAIK not part of the nightly source tarballs ... is there a bug for that ? > In theory its possible, but in practice probably not without some extra work. > I really really doubt that you need a gig of RAM. > We use the device's dpi setting, so if that is correct, then scaling shouldn't > be needed 1200DPI (color laser printer) at DINA4 in 24bit (RGB packed) ... I don't have a calculator... but I think it will be a large image. AFAIK you get a similar large memory size at 300DPI/DINA0-Oversize (poster) ...
libart is not part of the nightlies because it's lgpl and can't be included w/ our mpl code. if someone wants libart, they will have to acquire it on their own.
Nice... wonderfull... grrr... ;-( Well... what about creating a seperate nightly source tarball from mozilla/other-licenses to work around this problem ?
BTW: I have to correct myself. Xprint supports offscreen drawing surfaces, even for output languages which do not implement this functionality (like PostScript). Mozilla's Xprint module does not implement this feature yet (or better: the hooks are the same dummy hooks as in the PostScript module) - but it can be implemeted... :)
Has anyone considered implementing nsSVGRenderingContext on top of Quartz on OS X? In addition to rendering vector graphics as screen bitmaps, Quartz can emit PDF for printing. However, at the moment Quartz only supports the PDF 1.3 imaging model for printing even though it supports transparency on screen. This means that Quartz can't do all the transparency tricks that Acrobat 5 and Illustrator can when printing.
I found another problem with the current approach "render via libArt and then copy it to the Xserver": The simple problem is: It does not work under some conditions - and even if it would work it would be unuseable slow. Config: Solaris2.8/Xsun/m64 driver, 3456x900 (3*1152x900x8/24bit with Xinerama). SVG does not render if you make the mozilla window as large as the whole screen. The problems seems that the Xserver may run out of resources under some conditions and refuses to return a pixmap... ;-(
Now that the SVG rendering backend is 'pluggable', this could be implemented by writing a PS rendering engine. At the moment the renderer is selected statically in nsSVGOuterSVGFrame::Init() based on configure options. If we had a PS renderer, we could make the selection dynamic, i.e. choose the PS renderer if the prescontext associated with the frametree reveals that we are printing to a PS context. Any takers? There is some documentation of the interfaces that need to be implemented by a rendering engine at http://www.croczilla.com/~alex/doxygen/rendering_backend/html/ The current renderering engines (libart, gdi+, cairo) are checked into layout/svg/renderer/src/.
Mass reassign of SVG bugs that aren't currently being worked on by Alex to email@example.com. If you think someone should be assigned to your bug you can join the #svg channel on mozilla.org's IRC server ( irc://irc.mozilla.org/svg ) where you can try to convince one of the SVG hackers to work on it. We aren't always there, so if you don't get a response straight away please try again later.
Assignee: alex → general
With cairo gfx now the default (and the only supported configuration for SVG), rendering of SVG for printing now goes directly to the cairo context set up for printing, instead of an intermediate image. This means the output will be vectors, at least until cairo's postscript or PDF backend needs to use a fallback.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.