Closed Bug 85803 Opened 23 years ago Closed 18 years ago

SVG should print as vector graphics...

Categories

(Core :: SVG, enhancement)

Product:
Core
Component:
SVG
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Future

People

(Reporter: roland.mainz, Unassigned)

Details

(Keywords: helpwanted) 

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
Keywords: helpwanted
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
general@svg.bugs. 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
Closed: 18 years ago
Resolution: --- → FIXED
Flags: in-testsuite-
You need to log in before you can comment on or make changes to this bug.