linux x86 2002-03-06-21 When I attempt to print out a page containing a table, where one of the table columns contains GIFs, if the table row needs to be split between two different pages, then instead of splitting the GIF as well, the GIF is actually printed in its entirety on both pages, but in a "squashed" form so that it fits in the allowed space. If area of the two mini-gifs is equal to the expected size of the picture. I notice this when printing out routes from www.mapsonus.com. I have included an example URL in this bug report. After going to the URL, click on the link for "replace this column with detailed maps for all turns". Then print out the resulting page. The picture for turn 4 is split between two pages, but each is actually a complete, squished copy of the original picture. When I try to do a print preview of a route, it appears to actually split the picture, which is probably better than squishing it. You can try creating different routes at mapsonus, if platform/paper size issues prevent the above URL from reproducing the problem for you.

I have observed this even without tables. I had a simple document with nothing more complex than <p> tags and <img> tags, and it still split my image as you describe

confirming. I see the problem also using 3/12 build on win 98. see the squished image at the top of page 3. follow the instructions in the bug report to see the problem on the output.

In addition to the very squished image at the top of page 3, the image at the bottom of page 2 (which is the same image) is also slightly squished, if you look at it closely. It's just not as bad as the one on page 3, since it's only slightly smaller than full-size.

Taking the bug.

cc: amar

I'm posting a more complicated example, but it clearly shows the worst case I've seen. This really fails in version 1.2.1. I saw the problem on rare occasions on 1.1, but 1.2.1 has gotten much worse. In my example, it gets in trouble when the table spans the whole page, so neither the start or end is on a page. See attached example. I had to remove nearly all the text content, but its still works. In the real version of this example, it was much longer than this.

Sorry, somehow I posted the example to the wrong bug.

Reproduced on 1/08/03 Trunk build, Linux.

mass reassign to default owner

This has nothing to do with tables. This is purely an image splitting bug. There are actually two problems -- the first is XP, the second is PS-only. Not sure the first one is a real problem, even... 1) The codepath in nsImageFrame::Paint that uses DrawScaledImage draws the whole thing instead of just a rect from it. I tried to switch to drawing just the rect when I was working on bug 83774 but I got weird artifacts when scrolling (as if the rects were not correct). I don't know whether that was due to a bug in my attempt or to a bug in DrawScaledImage.... 2) nsRenderingContextPS::DrawScaledImage always paints the whole image and ignores the source rect passed in.

Boris Zbarsky wrote: > This has nothing to do with tables. This is purely an image splitting bug. > There are actually two problems -- the first is XP, the second is PS-only. > Not sure the first one is a real problem, even... What about splitting this bug and file two new bugs, one for the XP issue and one for the PostScript-module issue and make this one depend on the new ones ?

I have a simple page with just text and left-aligned images that shows a similar problem. The images are a few inches deep, and when there isn't enough room to add the next image, mozilla either compresses it or cuts it and sometimes includes the following image positioned to the right. It happens with mozilla-1.4rc3 and also with netscape 7.0.2, both for Linux (RedHat 9 on a Pentium). The page prints OK with netscape 4.76. http://williambader.com/totem20030621/totem20030621.html When there is not enough room for an image to fit at the bottom of a page, if the image is smaller than the page length, mozilla should advance to a new page the same as netscape 4.76.

Is bug 203092 the symptom of the XP bug?

Very possible; I'm not familiar enough with win32 gfx to tell for sure.

Without table and with one table no image was splitted (blank rest of page and starting image on new page - OK). EXAMPLE: With nested tables the third image is splitted and spans over to pages. In print preview it's cut correctly, in print the image is squashed twice in both parts. This happens with GIF, PNG and JPG files. I'm using Mozilla 1.4 [1] under Windows 2000 [2]. [1] Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.4) Gecko/20030624 [2] Version 5.0 (Build 2195: Service Pack 4)

Image file added for the given example.

Now refering the attached image file (sorry; I'm learning). What I expect: Best case: don't split image (when it's not to big) Second-best case: split image correctly

Images are split correctly on builds with the checkin for bug 119263 - trunk and 1.5 branch. *** This bug has been marked as a duplicate of 119263 ***