Closed Bug 146799 Opened 22 years ago Closed 21 years ago

Images could be printed incorrectly; images are split across pages

Categories

(Core :: Printing: Output, defect, P2)

Product:
Core
Component:
Printing: Output
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: dk, Unassigned)

References

(
URL
)

Details

Attachments

(1 file)

comment about this bug (146799)
517 bytes, text/plain
Details
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/20020510 BuildID: 20020510 Also tested on RC3. With the same result. When image appears at the end of a page it can be splitted into 2 parts. First is printed on one page 2-nd - on the next. Reproducible: Always Steps to Reproduce: 1.Open url http://mason.gmu.edu/~kersch/cise/KRG/MAC_folder/MAC.html or just any with a number of images 2.Select "Print Preview" or "Print" 3.See the result. On screen or on paper. With this url it happens with the last image (scrinshot of smthing). Sometimes Mozilla crashes (up to RC3) after selecting PrintPreview. But not emmediatelly. Only when toy are trying to open another page. It's not because of content of page you're trying to view.
*** Bug 147503 has been marked as a duplicate of this bug. ***
Summary: Images could be printed incorectly → Images could be printed incorectly; images are split across pages
confirming....
Status: UNCONFIRMED → NEW
Ever confirmed: true
Images are split to not waste paper. Right now they always split. If someone could develop test cases showing when they should split and when not, we could easily fix this.
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → Future
I don't think images should ever be split across pages. It looks awful, and makes reading the stock charts I print out very difficult. None of my other browsers (IE6, Netscape 6.2, and Opera 6.02)split images across pages.
Are you saying that an image that is taller than a page should not be split, but truncated instead (I think not)? What about an image that is taller than a page and starts in the middle of a page - should it start in the middle of the page or get pushed to the next page? I have seen very tall images used as spacers in tables which would break pages if they were started on the next page. But for most images (that aren't taller than a page), should they be pushed to the next page or are there exceptions?
Your going have to bear with me here, as I am not a programmer, HTML or otherwise. I'm just an end user. I can't remember encountering a Web page w/ image's taller than a page. To test this out, I did a quick HTML page containing a very tall image with multiple lines of text above and below it. I then printed it out with my various browsers. IE6 printed a page of text, another page with a truncated image, and the third page containing text. Mozilla printed a page of text, 2 pages each containing the image squashed to fit on a single page, and a 4th page containing text. Netscape 6.2 printed a page of text, another page with a truncated image, and the third page containing text. Its printing looked pretty much identical to IE6. Opera 6.02 printed a page of text, another page containing the image squashed to fit on a single page, and the third page containing text. I guess I prefer the way both Mozilla and Opera handle the printing, except that Mozilla printed two copies of the image. What I don't understand is why, in this case, Mozilla squashed this image to fit on one page. Yet, on other Web pages, such as http://www.os2ezine.com/20020516/pf_4.html Mozilla splits images across two pages. I know I prefer the way IE6, Netscape 6.2, and Opera handle the printing of this example.
*** Bug 148021 has been marked as a duplicate of this bug. ***
*** Bug 148384 has been marked as a duplicate of this bug. ***
DUP Bug 148384 was on W2K, this one is Linux - I assume this is Platform/OS=All, right ? Fixing Platform/OS to All/All ...
OS: Linux → All
Hardware: PC → All
Suggestion: There are two options in the page setup dialog. [ ] Split images across page breaks [ ] Squeeze overlarge images on one page Both options should be disabled by default. How it works: 1. Normally, each image is fully printed on one page (therefore, if it doesn't fully fit (vertically) in the rest of one page, it is completely moved to the top of next page). If its size is taller than the print area of the page, see 2) Overlarge images (taller than the vertical space on the print page) are vertically cut into pieces and spread across the pages. If you want to implement it really tricky, you could add a functionality like this: Be S the remaining vertical space on the bottom of the first page, H the total height of the print area of a page and I (>H) the height of the image; If (I mod H) <= S, the image starts on the bottom of the first page (the rest of the image is spread over the following pages); if (I mod H) > S, you would get an extra piece of the image on the very last page if you started on the bottom of the first page, therefore the image should NOT be started on the bottom of the first page (of height S), but be started on the top of the next page. 2. If the first option is enabled ("Split images across page breaks"), the images are spread over pages as they are right now (but bug-free: not the full image must be printed in the area of each of the pieces); so the first part of an image is started in the remainin space on the bottom of a page, and the rest of the image is printed on the following page(s). 3. If the second option is enabled ("Squeeze overlarge images on one page"), the _overlarge_ image (according to example above: I > H), the image is fully printed on a page by its own, vertically (or maybe even proportionally) down-scaled to fit in the print area of one page (height H). The eventually remaining space on the bottom of the previous page is left blank. 4. If both options are enabled, the first option is basically ignored. What do you think about this suggestion? In my optinion, it would cover all needs regarding the important aspect of image printing (with sensible default behaviour) and give the user all freedom to choose its preferred method of pagination... Ciao, Alex :-)
Alex.. This feature isn't present in the Mac OS X version .. I'm using build 2002061708 and I've no choice.. Images split is a must. As known in Mac OS X you can do a Print Preview and save it as a PDF file.. This is useful if you want to read a web page off line and keep all in one file, that is compatible with all computers. But last time I was forced to use IE cause images where splitted.. So there *must* be a preference that allow you to choose each time what to do. For better compatibility with all Operating Systems I suggest to put it in the Preferences window .. Then the user just have to do a print preview and choose wich one of the two options select. Ciao, Giovanni
-->
Assignee: rods → karnaze
Status: ASSIGNED → NEW
Hi Giovanny, maybe there is a misunderstanding. The two options I described for the page setup dialog are not only missing in the MacOS version, but in all versions - just based on the fact, that this was meant as a suggestion from my side how to deal with the always re-occuring problem of image splitting when printing. In my opinion the page setup dialog is the perfect place for the described options, since many users may activate and deactivate the split and squeeze options each time according to the current web page to be printed (just like activating or deactivating the backround image to be print). Ciao, Alex
Yes, I missunderstood :-P I've not seen the "suggestion" word before the remaining text. Anyway .. I think that according to the fact that the page setup is a system dialog, it would be easyer for developers to insert it in the preferences panel. and I also think that this feature *must* be implemented ;) So, if I'm wrong about the fact that is more difficult to inser this function in the page setup dialog .. then .. the page setup dialog is welcome as the best place to put it for me too. Ciao, Giovanni
*** Bug 174262 has been marked as a duplicate of this bug. ***
*** Bug 177230 has been marked as a duplicate of this bug. ***
The image split is worse than the old IE 5.0 image split. In IE 5.0, the image size is calculated and then part of the image is printed at the bottom of one page, and the remaining part of the image is printed at the top of the next page. If you were to cut the image halves out and paste them together, you would get the complete, correctly-sized image. It is just split in half. In Mozilla 1.1, the image size is calculated and divided across the two pages. This is just like IE 5.0. However, instead of chopping the image into two pieces that could then be cut (with scissors) and pasted together, Mozilla fills the first portion with a squished version of the complete image and the second portion with another squished version of the complete image. So, you end up with two squished copies of the image. The horizontal size is correct, but the vertical size is adjusted according to how much of the image appears on the first page and how much appears on the second page.
*** Bug 181969 has been marked as a duplicate of this bug. ***
*** Bug 181998 has been marked as a duplicate of this bug. ***
There is a new test case. http://www.zdnet.co.jp/news/0211/20/nj00_opt002.html The tanaka.jpg is layout on the middle of the first page (not straddling the pages). When printing to a HP LaserJet 4000 printer, it was seperated two parts. The version of Mozilla I am using is Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130
Ok... the problem is that splitting images simply by splitting nsImageFrame is wrong -- nsImageFrame uses its dimensions to DrawScaledImage or DrawImage the whole image into its area (hence the double image problem people see). It has no concept of painting only part of an image.... if we want to split images by splitting nsImageFrame, it needs to be taught to only paint part of an image.
*** Bug 149667 has been marked as a duplicate of this bug. ***
Summary: Images could be printed incorectly; images are split across pages → Images could be printed incorrectly; images are split across pages
*** Bug 192684 has been marked as a duplicate of this bug. ***
mass reassign to default owner
Assignee: karnaze → table
Component: Printing → Layout: Tables
QA Contact: sujay → madhur
Target Milestone: Future → ---
Target Milestone: --- → Future
print bugs
Assignee: table → printing
Component: Layout: Tables → Printing
QA Contact: madhur → sujay
Target Milestone: Future → ---
*** Bug 140387 has been marked as a duplicate of this bug. ***
*** Bug 201626 has been marked as a duplicate of this bug. ***
to #21 "It has no concept of painting only part of an image...." There must be a concept and it just works. The "Print Preview" don't show the behavior of doubling images but it makes a "real" splits of images. I can't understand, why the "Print" looks different then the "Print Preview". The question "What's the best way of splitting or moving images" (#10) is important, but a completly different question than this bug and should discuss separately.
*** Bug 158641 has been marked as a duplicate of this bug. ***
I think that images should never be split unless they are larger than a page. mozilla 1.4rc3 under RH 9 Linux makes a mess out of the images in the page below. http://williambader.com/totem20030621/totem20030621.html It also messes up splitting images. On pages that start with the bottom of a split image, the next image is incorrectly placed to the right of the split image instead of below it, and the formatting of the surrounding text is messed up.
This bug should have the keyword "4xp" because Netscape 4.76 on RedHat Linux 7.1 does not split images. If an image does not fit, Netscape 4 starts a new page. Images should probably never be split in printing. Books, magazines, newspapers, photo albums, etc., never have split pictures.
Blocks: 212257
This bug makes it impossible to print correctly page with multiple 640x480 photos. IE works in this case correctly. I also agree that images should never be split if they are not larger than page.
I am using version Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6a) Gecko/20031030 and when I receive an email with pictures attached, and then print them, it does the following. If the image would cross the page boundary it acts as if it is going to split the image. However, the entire image is scrunched vertically in both parts on each page. That is the picture is really printed twice with the vertical size squished down to the size it calculated for the split part. Is this part of this bug, or yet another?
*** Bug 203092 has been marked as a duplicate of this bug. ***
*** Bug 222397 has been marked as a duplicate of this bug. ***
Test URL http://www.concordesst.com/powerplant.html It first .if is printed twice. Once on the first page with the vertical axis compressed, then correctly at the top of the 2nd page. Printing with an HP psc 2510 on WinXP.
This gets in the way of persuading people to migrate to Mozilla from MS IE.
Blocks: 164421
*** Bug 234095 has been marked as a duplicate of this bug. ***
This bug seems to have morphed a bit. The original reporter didn't say anything about split images being squashed (ie the entire image printing in the space for part of the image). He was just reporting that images were split over two pages and he thought that was bad. The squashing effect wasn't mentioned until comment 6 by someone other than the reporter. The issue of splitting images over two pages is separate from the image-squashing problem. One is a layout policy issue; the other is a print engine bug. Further, it's probably a platform-specific print engine bug. For image-squashing bugs on windows, see bug 234095. I don't believe we currently have an image-squashing problem on unix/linux; if anyone can produce the problem using current software, please open a new bug report. For other platforms, please open a new bug report. Regarding the issue of splitting images over two pages, I think a general rule that mozilla should never split images is unrealistic, though bug reports about its behavior in particular situations may be appropriate. Regarding this bug report, I think it's had too much irrelevant discussion and too many bug reports about different aspects of the issue duped to it. I don't think it's useful to keep this bug open. If anyone has issues with the curren't software's image-splitting behavior, I think it'd be best to open a new bug and/or un-dupe one of the other bugs duped to this one. Resolving wontfix.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → WONTFIX
This is still a serious issue--I think it should simply be a preference ("Print large images to next page" or "Don't split images across pages" or something similar). In order to kill this bug, perhaps you could un-dupe Bug 174262 "Printing layout splits images over 2 pages"? Thanks.
(In reply to comment #39) > For image-squashing bugs on windows, see bug 234095. I don't believe we > currently have an image-squashing problem on unix/linux; if anyone can produce > the problem using current software, please open a new bug report. For other > platforms, please open a new bug report. This definitely happens on Linux and Mozilla 1.4 and PNG images. We are on an isolated lan with no access to the net, so can't update past Mozilla 1.4 and RH Enterprise WS. The behavior is that the image is split with both images being squashed so that the entire image is displayed in the squashed, clipped area.
If it's a question of the image being too large to fit on the page at all, then yes, the image should be split for printing. If the image will fit within a page, but it begins so far down in the layout that it will overflow the next page break, then simply move the page break abou\ve the image.
If it's a question of the image being too large to fit on the page at all, then yes, the image should be split for printing. If the image will fit within a page, but it begins so far down in the layout that it will overflow the next page break, then simply move the page break above the image. Splitting the image should be the last resort. If you wind up splitting images, the printed output can become quite dificult to read.
*** Bug 264361 has been marked as a duplicate of this bug. ***
(In reply to comment #44) > *** Bug 264361 has been marked as a duplicate of this bug. *** This is a problem. I'm printing a bage of thumbnails, each thumbnail is only 112 pisexls tall. The row at the page's botom is split. Clearly, such small images should be dealt with better, especially when other browsers do not exhibit such behavior. I'd like to use Firefox for all my browsing, but this prevents me from doing so.
No longer blocks: 164421
Blocks: 158464
Blocks: 164421
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: