196745 - The background image is not printed out

Status: RESOLVED FIXED

(Core :: Printing: Output, defect)

Description

[Helder Mendes]

User-Agent:       Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0; T312461)
Build Identifier: Mozilla/5.0 OpenVMS en-US; rv:1.2.1  Gecko/20030306 SWB/V1.2.1

All background testpoints are failing to print the background image (a leaf)

Reproducible: Always

Steps to Reproduce:
1.Click on the first one 
http://mozilla.org/quality/browser/standards/xml/background_url_repeat_y.xml
2.
3.

Actual Results:  
The backgroung image is displayed on your screen but is not printed.

Expected Results:  
It should be printed.

I tested on both, Red Hat Mozilla and Openvms

Comment 1

[Boris Zbarsky [:bzbarsky]]

Confirmed; print preview works, but PS printing does not (don't have XPrint to
test).

Comment 2

[Gerard Saraber]

Also Confirmed in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030318

Comment 3

[tor]

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

Comment 4

[Bernd]

works with win95 fb 0.7

Comment 5

[mathieu]

Well it works on win98 with FB 0.7 but not linux redhat 9.2 with the same
navigator whereas the preview works almost prefectly

Comment 6

[Boris Zbarsky [:bzbarsky]]

Background painting uses DrawTile().  nsRenderingContextImpl::DrawTile calls
GetDrawingSurface() and then passes that to the image's DrawTile() method.

The Postscript rendering context returns null for the drawing surface, so
nsRenderingContextImpl::DrawTile bails.

In this case that's "good", since nsImageGTK::DrawTile assumes it's getting a
GTK drawing surface....

Comment 7

[Ganesh]

I see that xprint also does the same thing (returning null).
http://lxr.mozilla.org/seamonkey/source/gfx/src/xprint/nsRenderingContextXp.cpp#139

I believe we need to implment these functions such that the GetDrawingSurface
doesn't return just "null" (like nsRenderingContextGTK::GetDrawingSurface ) ?

Comment 8

[Boris Zbarsky [:bzbarsky]]

ccing some painting and GTK people:

Basic problems:

1)  Painting of images is handled by the image class
2)  We need to be able to paint images using multiple printing back ends,
    RENDER, etc.
3)  There is no way to know what sort of rendering/device context and what sort
    of drawing surface we're looking at, right now.

I don't really see a way to fix these issues without some rethinking of how gfx
is pieced together, in terms of apis and overall design.  It works fine for
Windows and Mac where there is only one type of drawing setup, but for Linux we
need more flexibility.  :(

Comment 9

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

Can we have an nsImagePS, an extra function on image objects that extracts the
pixels in some device neutral format, and a way to create a new image object for
a given device context using those pixels? Then at frame construction time we
could check that the image object is for the right device context and if not,
recreate it for the right context.

Comment 10

[Boris Zbarsky [:bzbarsky]]

That might work, but we have all sorts of places in layout that handle images
(trees, bullets, <xul:image>, backgrounds, <html:img>, at least).  Would they
all need code to do this?

Comment 11

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

OK, so do the check in the image drawing code. If the rendering context is not
the right type, call back to it to construct a temporary image object, passing
it the device-neutral pixels, and forward the call to the temporary image. That
would be slow but it should only happen for non-screen rendering targets.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Yeah, that would work.  Still needs some hooks to get the type, but not as bad
as I was afraid it would be.  ;)

Comment 13

[Ganesh]

I am not very much familiar with this part of code. I was actually debugging it
to find out what is going on. I noticed that the normal <img SRC= "someimage" >
tag works fine. The image is drawn through nsRenderingContextPS::DrawImage(..). 

whereas in the case of background image printing,  the function
nsRenderingContext::DrawImage(..) never gets hit may be because we got the
drawingsurface for PS object as null. 

Also nsRenderingContextPS::GetDrawingSurface 
is used only for the background image priting and not for the normal images?. I
believe if I have implment ROC's suggestion I will do it in the place where we
get  drawingsurface as null. 

Comment 14

[Kenneth Herron]

Postscript doesn't use the nsIImage image-drawing functions to print foreground
images. It overrides the drawing functions in nsRenderingContextImpl instead.
Wouldn't it be simplest to print background images the same way?

Comment 15

[Roland Mainz]

(In reply to comment #7)
> I see that xprint also does the same thing (returning null).
>
http://lxr.mozilla.org/seamonkey/source/gfx/src/xprint/nsRenderingContextXp.cpp#139
> 
> I believe we need to implment these functions such that the GetDrawingSurface
> doesn't return just "null" (like nsRenderingContextGTK::GetDrawingSurface ) ?

Xprint didn't implement this because the code was designed along what the
PostScript module did. If someone thinks it's usefull to change that then I can
do that (but the PS module can't work like that - it has no concept of offscreen
drawing surfaces for a printer device... such a functionality is unique to
Xprint and GDI).

Comment 16

[Roland Mainz]

(In reply to comment #9)
> Can we have an nsImagePS, an extra function on image objects that extracts the
> pixels in some device neutral format, and a way to create a new image object for
> a given device context using those pixels? Then at frame construction time we
> could check that the image object is for the right device context and if not,
> recreate it for the right context.

That would be the clean solution. IMHO the idea of creating
devicecontext-specific objects via the component manager was a BAD design decision.

Remember I fixed this for the rendering context things via replacing the
component manager via the nsIDeviceContext::CreateRenderingContext() /
nsIDeviceContext::CreateRenderingContextInstance() methods (that eliminated some
topcrashers those days, too... :)

I think the same thing should be done with the nsIImage stuff - those objects
should be only "createable" using a method like nsIDeviceContext::CreateImage()
/ nsIDeviceContext::CreateImageInstance() and then the callers should use that
code instead (we would need a new nsIMagePS class, Xprint can reuse nsImageXlib).

Comment 17

[Roland Mainz]

(In reply to comment #14)
> Postscript doesn't use the nsIImage image-drawing functions to print foreground
> images. It overrides the drawing functions in nsRenderingContextImpl instead.
> Wouldn't it be simplest to print background images the same way?

... that would only wallpaper over those the problem.
IMHO the print device context implementations should have their own nsIImage
subclasses, created via the method I have described above.
That's a far more cleaner solution and would allow some additional stuff like
image caching (e.g. the image (represented by nsImageXp/nsImagePS) gets only
send _once_ to the printer instead of each time when it occurs on a page. That
may save lots of bytes in a print job...).

Comment 18

[ZF.Dang]

Attachment: the first attempt

This patch enables mozilla in linux to print background. It works for me, but
it still has some problems. 
1.In some cases, printing output is different with displaying one. I know it is
problem of scaling. But I don't know how to solve it. A testing page will be
posted later.
2.It uses nsPostscriptObj::draw_image to draw images for background. So in the
final ps file there may be many copies of background image. I think we should
optimizie nsPostscriptObj::draw_image method to minish size of ps file.

Comment 19

[ZF.Dang]

Attachment: This is a testing page.

the above patch has problems to print this page.

Comment 20

[ZF.Dang]

some comments on the patch.

nsRenderingContextImpl uses following way to DrawImage or DrawTile:
1.Get drawing surface.
2.Pass drawing surface to image
3.Image implements DrawImage or DrawTile to do the real job.

But to ps module, things are different. There is no nsImagePS, and there is 
no nsDrawingSurfacePS; DrawImage is overrided in nsRenderingContextPS. 
So I think DrawTile should be the same.

Comment 21

[ZF.Dang]

Attachment: Modified patch

Format codes and remove some debug lines.

Comment 22

[ZF.Dang]

Comment on attachment 154337 [details] [diff] [review]
Modified patch

Requesting r/sr

Comment 23

[Pete Zha]

Comment on attachment 154337 [details] [diff] [review]
Modified patch

r=pete

Comment 24

[Pete Zha]

Comment on attachment 154337 [details] [diff] [review]
Modified patch

roc,
Please review this simple patch. Thanks!

Comment 25

[tor]

While this generates the right result on the page, the postscript files it
generates are pretty massive.  Can we dump the image data into the file just
once and reuse it for all the tiles without running into problems with
small memory postscript interpreters?

Comment 26

[ZF.Dang]

(In reply to comment #25)
> While this generates the right result on the page, the postscript files it
> generates are pretty massive.  Can we dump the image data into the file just
> once and reuse it for all the tiles without running into problems with
> small memory postscript interpreters?
> 
I have noticed this problem before. Now I find a solution by using
ReusableStreamDecode filter. But this feature is only available in PS language
level 3. Is it proper to use this feature in mozilla for I remember mozilla
outputs level 2 ps file ?

Comment 27

[ZF.Dang]

Attachment: PS file using ReusableStreamDecode filter.

PS file Using ReusableStreamDecode filter.

Comment 28

[Pete Zha]

Seems there is no way to do it in postscript level 2. I tried the ps ZH.Dang
provided but can not print on Xerox DocuPrint N32 which only support up to
postscript level 2.

Comment 29

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

Postscript is a programming language --- surely there's some way to store and
reuse the data? kherron, can you help?

Comment 30

[Kenneth Herron]

PS lets you store image data in variables and print from them, but unless the
images are tiny you risk using up all of the printer's memory. PS programs are
executed as they're read in by the PS interpreter, so reducing the amount of
memory used by the running program is viewed as more important than reducing the
total size of the program.

The current image-printing code uses all PS level 1 features, though we use
level 2 features elsewhere,such as for printing unicode text. If we wanted to
use level 2 features for images, we could ascii85-encode the image data instead
of just hex-encoding it; this would reduce the volume of image data by almost half.

PS level 2 also supports tiled patterns. For patterns containing sampled images,
the pixel data has to be stored in memory, which again risks using up the
printer's memory. This can be avoided by tiling the image in chunks, though I
don't know if artifacts at the chunk boundaries are a problem. If I had time to
work on this bug, I'd be trying something like this.

Personally, I'd like to avoid requiring PS level 3.

Comment 31

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

Comment on attachment 154337 [details] [diff] [review]
Modified patch

okay, if it's that hard then let's just check this in. Thanks Kenneth (and
Pete!)

Comment 32

[Pete Zha]

This is a function lose. Can I check it in 1.8a3?
It will only affect ps module when the user enable "Print background (color&image)"

Comment 33

[Asa Dotzler [:asa]]

Comment on attachment 154337 [details] [diff] [review]
Modified patch

a=asa for checkin to 1.8a3. Pete, approval to land reviewed patches is
requested in the patch, not in blocking status for the bug.

Comment 34

[Pete Zha]

ok, not a blocker. Thanks for approval!

Comment 35

[Pete Zha]

checked in

Comment 36

[ZF.Dang]

Thanks :)