297977 - print svg crash

Status: RESOLVED FIXED

(Core :: SVG, defect)

Description

[Kalacheva Julia]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050616
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050616

Configure arguments
--prefix=/usr --libdir=/usr/lib --enable-optimize=-O2 --disable-debug
--with-default-mozilla-five-home=/usr/lib/mozilla-1.8b2 --disable-strip-libs
--disable-tests --enable-application=suite --enable-xinerama
--enable-nspr-autoconf --enable-extensions=default,irc --without-mng
--enable-crypto --enable-svg --enable-svg-renderer-cairo --without-system-nspr
--with-system-zlib --with-system-png --with-system-jpeg --disable-profilesharing
--disable-profilelocking --disable-necko-disk-cache
--enable-default-toolkit=gtk2 --disable-freetype2 --enable-xft --enable-pango
--mandir=/usr/share/man 

Reproducible: Always

Steps to Reproduce:
1.Open URL
2.Print


Actual Results:  
crash


mozilla-1.8b1 affected too.
https://bugzilla.mozilla.org/show_bug.cgi?id=133964 is fixed. Regression.

Comment 1

[Kalacheva Julia]

cairo-0.4.0

Comment 2

[tor]

Attachment: printing work in progress

Should work, but when I print, SVG frames suddenly think they need more space
and acquire scrollbars, which I think is throwing off the area it's trying to
render.

Comment 3

[Alexey Gaidukov]

I've tried the patch. Mozilla doesn't crash but prints black square instead of SVG

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I get the big black rectangle too.

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I think the problem is that Postscript sets up its transform to flip Y
coordinates vertically, and also sets the X/Y scale to be 1:1. I'll fix this.

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fix #2

Here's an iteration of tor's patch that works well for me. There were a few
problems in the earlier version: the translation wasn't getting set right
(because Postscript uses flipped vertical coordinates *and* we weren't
accounting for the fact that the cairo surface was just for the dirty rect).
Also the size of the destination rectangle needs to be given in "scaled"
pixels, and we need to be a bit smarter about translating cairo image data to
the platform image data.

To get this to actually work on PS surfaces you need my patch for bug 141656
that makes transparent image printing to Postscript work (for level 3 printers,
anyway).

Comment 7

[Alexey Gaidukov]

The patch works well for me. But I got an compilation error. You declare variable
+  nsRect mDestRectScaledTwips;

but use 

+    nsRect src(0, 0, mRectTwips.width, mRectTwips.height);
+    mMozContext->DrawImage(mContainer, src, mRectTwips);

in the patch. I changed mRectTwips to mDestRectScaledTwips.

Comment 8

[Alexey Gaidukov]

Attachment: SeaMonkey's Windows and Linux images of printed svg

Comment 9

[Alexey Gaidukov]

I found that printed images from Windows and Linux are different. 
https://bugzilla.mozilla.org/attachment.cgi?id=191176
Both are printed from the same version of SeaMonkey. At the top is Windows
version. At bottom linus version. Linux version looks like is scaled.

Source svg is
http://www.croczilla.com/svg/samples/butterfly/butterfly.svg

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b3) Build ID/2005071611 SeaMonkey/1.0a

Comment 10

[tor]

Comment on attachment 191162 [details] [diff] [review]
fix #2

In addition to the compile problem, this still has bug that once you've printed
(or print preview), the svg frame suddenly thinks it needs much more room.

Example page for this:

http://www.w3.org/Graphics/SVG/Test/20030813/htmlframe/full-shapes-polyline-01-
t.html

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Alexey: Sorry about attaching the wrong patch. The size bug you see is probably
because you didn't fix the patch correctly.

Tim: I'm working on that now...

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I think things are breaking because we do a
nsSVGSVGElement::SetParentCoordCtxProvider during printing, to point to the
nsSVGOuterSVGFrame in the print presentation ... and then it never gets set back
to the screen-presentation frame.

Comment 13

[Robert O'Callahan (:roc) (email my personal email if necessary)]

okay ... while I still think that is a problem, it probably isn't the cause of
this bug. I noticed that if you change the EMBED to IFRAME, everything works.

Comment 14

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fix #3

Yeah, there are some problems with printing EMBED elements that contain SVG
(because SVG is the only format for which we handle EMBED content in the
browser). I'll fix those under a separate bug (bug 303023, in fact).

Comment 15

[Alexey Gaidukov]

Now patch copiled without errors and Windows and Linux images have the same
size. But quality of Linux version is poor. Linux image looks like 100dpi image.
Even print to PS file.

Comment 16

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Yes, the Linux version will be low quality ... it's basically just a screen
dump. This won't be fixed in 1.8. It will be fixed in 1.9.

Comment 17

[Alexey Gaidukov]

Is there bug about quality? How can I track it?

Comment 18

[Robert O'Callahan (:roc) (email my personal email if necessary)]

There is no bug about this yet. It's going to happen as part of the general
graphics work that will move all our graphics to cairo. During that process,
we'll integrate the cairo Postscript backend so that rendering SVG (or anything
else) will be converted to appropriate Postscript commands.

Comment 19

[Alexey Gaidukov]

1.9a1 will be with cairo Postscript backend and with svg good quality?

Comment 20

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I don't know if it will be in 1.9a1 since I don't know when these things are
going to happen.

Comment 21

[Robert O'Callahan (:roc) (email my personal email if necessary)]

BTW the bug you were seeing with the frame expanding was because the print
engine was putting the EMBED on its own page (and then forgetting about it, but
that's another story to be fixed in bug 303023).

Comment 22

[tor]

*** Bug 302832 has been marked as a duplicate of this bug. ***

Comment 23

[tor]

*** Bug 150120 has been marked as a duplicate of this bug. ***

Comment 24

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 191290 [details] [diff] [review]
fix #3

Fixes (really "implements") printing of SVG on Linux.

Comment 25

[Robert O'Callahan (:roc) (email my personal email if necessary)]

checked in