[Build-ID: CVS build from 2001-11-13-20] A few times when printing with mozilla I have noticed that part of the text on the page overlaps. I can reproduce it on the above mentioned URL. The overlapping even shows up on a Print Preview so I will therefore attach a screenshot of that. This is on Linux with a HP LaserJet 4MP PostScript printer. I think it is postscript level 2. I always print A4 format and greyscale. The same page prints just fine with Netscape 4.x. As you can see this is on a page with non-ASCII character, but I'm not sure if that's related. Let me know what other details might be of interest.

I just printed this URL out and I do not see any overlapping text/lines... I printed out 5 pages. can you point me to which page and line you are referring to? I don't see any overlapping text. Roland can you confirm this?

I should add that the overlapping is not quiet as bad as the Print Preview screenshot when the page is printed. I just noticed an important clue: the overlapping only happens in the places where the text is bold. The text following the bold text is overlapping with the bold text. It looks as if the text following the bold text has been moved perhaps 1 or 2 characters too much to the left.

sujay@netscape.com, I wrote the wrong URL at first, did you print out the URL I added later? Also, are you testing this on Linux?

I got the correct URL..I tried on Windows...works fine there.. I will re-try on Linux... Boris, do you see this on Linux ?

Yeah, I see this. Not quite as severe here, but definitely overlapping.

CC:'ing rods ...

I'm still seeing this with a recent build. Here is another testcase: http://lwn.net/2002/0117/kernel.php3 Notice that the overlapping happens with the bold headers in this case too. I will attach a screenshot of how print preview looks for this page (which is exactly how the printed page looks too).

I saw some text overwrite other text while doing the fron-end Printing tests for Character: http://www.mozilla.org/quality/browser/front- end/testcases/printing/charactertest.html Specificly, I noticed the following: Superscript Tage test: overwrote some of the test Bold Tag Tests: some, but not all, of the bold text was overwritten.

Jay, I can confirm that with 2002-01-28-00 from the 0.9.8 branch. The comments about bold and superscript text matches well with my experience in this bug (see comment 13).

It really concerns me that this bug has target milestone mozilla 1.1. Is has a good testcase, and it happens on basically all pages with bold text. I'd really like to see this one fixed for 1.0.

It's really hard to NOT run into this bug on pages with Linux.

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

The overlapping may have been fixed for the output with the fix to 37685. As far as print preview.. that would be a different issue.. since print preview uses the same fonts and metrics as the normal view. Check and see if the print outs are fixed.

I tested the printout on this.. that works just fine. Now it seems that its only the print preview part that has overlapping text. I am going to change the summary to reflect that the overlapping text is just in print preview.

I can verify that it is now only on print preview that the overlapping is visible.

Build 2002031207 on FreeBsd 4.4 My test URL for this bug: ftp://ftp.oleane.net/pub/mozilla/ The overlapping on the print preview seems to occur on a color change.

Still present on 20020421 , Also I'm not able to change the "Gap of Paper to Margin" Always when I try to do so, It jumps back to 0.5 As well as not remembering state, that I set up A4. It gets back to Letter everytime.

I stayed on Build 2002032707 for FreeBSD 4.4 because for the time being it is fine for me: - print preview is OK - paper size and print command are saved OK - As to the "Gap from edge of paper to Margin(inches)", it does not work from the "Printer Properties" window. Hence, I set the gaps in the file /usr/local/mozilla/defaults/pref/unix.js, for example: pref("print.print_edge_top", 30); // 1/100 of an inch. This works fine.

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

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

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

My dupe was for overlapping text in Print Preview in RC1 on Windows2000. OS probably can be changed to ALL as this appears to be happening on a variety of OS's.

OS->All.

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

Here is a picture of page 1 of http://industry.ebi.ac.uk/~thanaraj/gene_altSplice.html in print preview mode on a sparc solaris 2.8 machine running 20020513 showing overlapping text.

The above web page also doesn't print correctly as the pictures come out at different sizes. That bug is 119263.

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

I think this screenshot is the worst version of this bug, not only overlapping text but also broken tables etc.

I'd like to add yet another URL to this bug report: http://www.uphs.upenn.edu/surgery/clin/gi/gallblad.html This page prints fine, but in Print Preview it has overlapping text; specifically the hospital information in the right hand column overlaps some of the regular text. This is for Mozilla 1.0 (2002052918) running on Red Hat Linux 6.2. I'd also like to note that Print Preview shows that this web page will print out on 2 pages of paper while it actually prints on 3. Should I open a new bug on that?

Just to remark that I still see this, and that I also found out that text is cutted in print preview, so that it looks like the page would not fit to A4. Printing this page however fits it into the A4 format.

Any news on this ? Now, that the target milestone of 1.1alpha has passed ?

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

On build Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2b) Gecko/20021016, this bug is still occurring. It is not just happening with bold text. It happens with the red text on this bug-reporting page: http://bugzilla.mozilla.org/enter_bug.cgi?product=Browser&format=guided I don't know html, etc, but displayed the source for the page and compared it to the print preview display and note that the presence of html coding seems to cause overlapping in the "portrait" view. However, in the "landscape" view of print preview, that html coding causes large gaps between characters meant to be separated by only a character. I also tried changing the hardware resolution and got the same results of overlapping characters in the portrait view at 640x480 and 1024x768 as well as 800x600, my usual display. Therefore the problem probably is due to a defect in the html rendering applied to the print preview display. The rendering engine is subtracting too many character or pixel positions for each html tag (is that the right word?) in the portrait view and adding too many in the landscape view. In comparison, the plain text in the boxes like this text entry box seem unaffected by that rendering error.

My observations just above still seem to be valid for Mozilla 1.2-final (Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2) Gecko/20021126). The html rendering isn't treating html tags as control codes that space in a line should not be assigned to when shrinking or expanding an html page to fit the print preview window.

Hi, I just got the latest Mozilla 1.2.1/Linux and the overlapping words are (still) present. Please try to print preview this URL: http://geo.arc.nasa.gov/sge/health/landepi.html Luckily the paper print is fine. Markus

Here's another example where Print Preview is messed up, but the actual hardcopy is fine (Mozilla 1.1 running on RedHat Linux 7.1): http://www-3.ibm.com/chips/products/powerpc/newsletter/dec2002/newproductfocus2.html Print Preview shows Figure 2 (the photo comparing the PowerPC 970 and POWER4 chip sizes) on top of some of the paragraph text. The picture should be flush right with the paragraph tet wrapping before it hits the picture. The printout is fine. Print Preview also has problems with Figures 3 and 4. These images show up as being cut-off at the bottom of Page 1. Only the top third of the image shows up on Page 1. Page 2 is even worse because it again shows Figures 3 and 4 as cut-off, but this time it shows the top three-quarters of the images with the bottom quarter missing.

see also bug 202935 and bug 193471

compare print preview with the one of testcase 2

retargeting

.

Just to note that this is still an issue for me on Moz 1.6b / Windows XP SP1. I can confirm that it does seem to be related to colour changes: I get the overlap mainly when the text switches from plain-text to blue hyperlink text and back.

Contrary to some comments expressed earlier in the bug comments, print preview text overlap _is_ now affecting the actual printed output. Seen on HP LJ4, Moz on Windows, printed via CUPS/GS on Linux print server. There is definitely a relationship btw the print scale and the overlap. I have included 3 new attachments showing the same 2 overlaps, same page, but scaled to 60%, 80% and 100%.

See other comment

I see this bug in: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040203 Firebird/0.7+ as noted by André Dahlqvist on 2001-11-13 15:20 PST , the overlapping happends when you have bold text. Its bad that it did not get fixed at Moz 1.0, I hope it gets fixed at least by Firebird 1.0.

Recent comments note points about bold text, etc. The original problem was this, I think: The html rendering isn't treating html tags as control codes that space in a line should not be assigned to when shrinking or expanding an html page to fit the print preview window. This was from comment #37. Besides skipping over the space occupied by html tags, bold fonts and maybe others take more space than regular fonts. In scaling down a page to fit the preview window, everything must be shrunk somewhat. Doing a print preview of this Bugzilla page shows much-improved rendering, but still some crowding due to bold fonts. Isn't kerning the word for adjusting the spacing between printed characters? It's no doubt a fine art to make the result look good.

I agree with comment 36 and comment 49. I just want to add that the spacing between the words is dependent on the printer and the page size (or orientation). I am attaching 2 screenshots. Notice also the underlining of the links spans out of the text. However even on my problematic low res printer, the actual printing is completelly clean and correct to the pixel.

This was with Mozilla 1.6final.

This still happens to me on Mozilla 1.7 rc1. 1.7 is supposed to be the next stable basis for applications, so maybe it's time to fix this? There's also a BiDi bug that I think is the same bug. Take a look at http://www.penguin.org.il/guides/lvm-intro/, and look at the print preview (this is a Hebrew document, so you'll need a Hebrew font for this). In the preview, the lines are wobbly (they should be right-aligned). Printing is fine. Tested on Firefox 0.8 and Mozilla 1.7rc1 on Windows 2000 Pro.

The link in comment #38 has a print preview with some problems. The print preview of this Bugzilla page with its html tags looks pretty good. What's in the link in #38 that makes the blue html remarks show incorrectly. Tabs? The link in #54 looked reasonable, to someone who doesn't read Hebrew.

(In reply to comment #55) > The link in #54 looked reasonable, to someone who doesn't read Hebrew. > There's two things wrong with it. One is, in many of the headers, the header text is too close to the counters (Hebrew has no single-letter words; what seems like single-letter words in the page is numbering, like a,b,c). The other is, the text body should be right-aligned; instead, it is wobbly. The screen display is fine, and so is the paper printing, it's just the preview that is problematic.

Using 1.7RC2 for Win98SE, this page http://www.mozilla.org/start/ showed some problems displaying links. Also, it shows two behaviors I haven't noticed before. If the amount of shrinkage is changed (from the default "shrink to fit"), the size of the print preview doesn't change, only the size of the fonts. Second, the sidebar with Roadmap, Projects, etc and the top banner with "download products support..." doesn't appear. Should these elements be in the print preview? I printed the page, and got a correct rendering of what the print preview page incorrectly displayed---except for the serious character-display bug that may be Win98-specific. Gotta check on that next.

Bug #236273 also notes printer-dependent print preview problems. I commented in part there: If the print preview display depends on the printer, then it's processed a little for the printer instead of just adjusted to fit a paper-size section of screen. Is that what the print preview code should be doing? If so, then the print preview maybe is where all the processing should take place to make a bitmap to send to the printer, and the printer should print the bitmap perfectly. That's not happening, as my problem with printing text (fonts) with Mozilla 1.7RC1 and RC2 is showing. Should print preview be doing printer-specific processing? If so, what's the intended output? Shouldn't print previews be independent of the printer and simply show the page layout, sizing, and (correctly) the number of pages?

Commenting to JRT re his comments on May 24: The whole idea of print preview is to show what you would get on the printer, as exactly as possible. It was never intended as some sort of document overview or extended zoom facility. Because the windows printer system is basically based around bitmaps, this means the print preview should really create the same bitmap that would be sent to the printer with the current printer settings, which includes respecting paper size, printable area, mono/greyscale/colour and so forth. It includes ensuring that the rendering was precisely at the printer resolution. In theory it would mean rendering as character-cells (i.e. as in ELinks) when printing to a text-only printer! [ I just tried: MS Word doesn't go this far!] The benefit of doing things the way the system as designed is that the code for 'print preview' is shared with 'print'. The downside is that it's hard or impossible to take advantage of printer-specific features, and it could be costly in processor time.

Thank you for the explanation. I printed some test pages today for a different problem and found that they rendered fine though the preview showed the usual irregularities.

Confirmed on : - Firefox 0.9 on Windows XP - Firefox 0.8 on freebsd See the new testcase, it's the simplest I could design : a table with 1 row, 1 cell and a 1px bordel. You can see that : - browser-view is correct - printpreview shows text beyond the end of the cell/table - once printed on a Epson EPL-6200 on windows XP, it's ok but slightly différent from browser-view (words cutted differently) The critical part of the testcase is in the CSS-part : TD { FONT-SIZE: 10px; LINE-HEIGHT: 12px; FONT-FAMILY: Arial } See the 4 new attachments.

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

(In reply to comment #61) > Created an attachment (id=150808) [edit] fails in FF but not in suite/seamonkey. Is there a reason this bug is in component printing and not print preview? Is the current wisdom that the problem with tables and tags have the same root cause?

Original test case can be found at http://web.archive.org/web/20010512232622/www.sm.luth.se/csee/courses/smd/001/ Several different problems are described here, tags (original report), tables, etc. The root cause may eventually be proved to be the same (that remains to be determined), but the visible symptoms at least are different. Can we stick with just tags and anchors in this bug? [confirmed bugs for tables includes bug 238415 - if your problem is with tables, you might hitch your wagon there if the symptoms fit.] comment 49 I think seems to sums up the issue wrt tags and anchors. Is anyone seeing this issue with tags in OS other than windows?

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

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

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

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

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

Comment on attachment 201093 [details] Please fix this problems not a patch

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

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

No problem for printing. No preview problem in Firefox 1.5.0.7.

Mozilla/5.0 (X11; U; Linux i686; pt-BR; rv:1.8.0.7) Gecko/20060911 SUSE/1.5.0.7-1.3 Firefox/1.5.0.7. Perfect when printing out (to a file).

I am not sure if comparing a SuSE build with a mozilla.org build is fair. SuSE might have applied code changes. You should only compare mozilla.org with each other.

in testcase (a smaller version of Justin's testcase from bug 271994) the superscript is too close to preceeding character fixed on FF windows trunk build between 2006-02-22 and 2006-03-03 (all the trunk builds that I tested between those two just looped on startup). I have not tested FF 2.x

This is "fixed" on trunk, but that's only because print preview broke with Thebes becoming default (it doesn't actually use the printer). The fundamental issue is measuring using printer fonts and drawing using screen fonts which aren't the same size. There's basically 3 possible ways to go about text for print preview: 1. Measuring using printer fonts and drawing using screen fonts. This is what we do "now" (at least before Cairo). This method causes this bug. 2. Measuring and drawing using screen fonts. This leads to print preview not laying out exactly the same and printing. (This is sort of what's happening in Thebes builds, with the additional problem of not getting the right page dimensions.) 3. Printing and drawing using printer fonts. This is the correct solution, but requires new platform-specific code. I think that this needs to be fixed per-platform; on Windows, we could use CreateCompatibleDC. I'm not sure what's possible on other platforms. (If I'm completely misinterpreting the issue, someone please correct me.)

I'm still seeing this bug in FF 2.0.0.2 on WinXP SP2. It happens in both the print preview and the actual printed page, although sometimes the effect seems more noticeable in the preview. It's happening mostly on bold text and links. Also worth noting is that the underline on some of the links doesn't span the full width of the text either -- it's usually short by 1-2 characters at the end of the link -- although this seems to be happening just in the print preview.

First off, the fact that this bug is still open generally means we know the issue still exists; "me too" comments don't help anyone. Secondly, this bug doesn't cover any issues with actual printed documents; please file a separate bug if you're seeing an issue like this on paper.

in general...preview issues for FF 1.5 and 2.x too are pretty well known and probably don't need to be commented or affirmed. in general...attach a reduced testcase for issues that don't have a testcase IF you tested and it failed with a trunk build. Print issues (both preview and paper) are specific and well defined in the bug summary (at least they should be). A good search will hit the right bug(s) with terms like table, header, footer, scale, orientation, font, etc. specify an exclude string of "preview" to bugzilla search to find "Paper" printing issues

Since firefox 2.0.0.8 (Linux only) I have also a problem with overlapping text. The difference to the descriptions above is, that the preview is shown right, but the printed output isn't. The output doesn't depend on the printer used, it is "wrong" even for PDF output through CUPS-PDF. The attachment id=291885 shows the original page and the problem part of the output.

WORKSFORME with mozilla-central nightly on Ubuntu 9.10. I tried printing attachment 242856 [details] & print-previewing attachment 150808 [details], and got nothing overlapping. Please reopen if you can still reproduce in a recent Firefox build. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20091204 Minefield/3.7a1pre