109970 - html tags cause overlapping text in print preview (tags: font, bold, italic, strong, href, underline)

Status: RESOLVED WORKSFORME

(Core :: Print Preview, defect)

Description

[André Dahlqvist]

[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.

Comment 1

[André Dahlqvist]

Attachment: A screenshot of the Print Preview window showing the overlapping text.

Comment 2

[sujay]

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?

Comment 3

[André Dahlqvist]

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.

Comment 4

[André Dahlqvist]

[e-mail], I wrote the wrong URL at first, did you print out the URL I
added later? Also, are you testing this on Linux?

Comment 5

[André Dahlqvist]

Attachment: An attempt to capture the overlapping in the printout with my cheep low-res webcam.

Comment 6

[sujay]

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 ?

Comment 7

[Boris Zbarsky [:bzbarsky]]

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

Comment 8

[Roland Mainz]

CC:'ing rods ...

Comment 9

[André Dahlqvist]

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).

Comment 10

[André Dahlqvist]

Attachment: Screenshot showing similar overlapping at lwn.net

Comment 11

[Jay Farrell]

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.

Comment 12

[André Dahlqvist]

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).

Comment 13

[André Dahlqvist]

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.

Comment 14

[André Dahlqvist]

Attachment: Screenshot of overlapping in print preview of bugzilla

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

Comment 15

[André Dahlqvist]

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

Comment 16

[dcone (gone)]

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.

Comment 17

[dcone (gone)]

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.

Comment 18

[André Dahlqvist]

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

Comment 19

[Harald Weis]

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.

Comment 20

[Carsten Menke]

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.

Comment 21

[Harald Weis]

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.

Comment 22

[Boris Zbarsky [:bzbarsky]]

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

Comment 23

[Boris Zbarsky [:bzbarsky]]

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

Comment 24

[Boris Zbarsky [:bzbarsky]]

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

Comment 25

[amutch]

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.  

Comment 26

[André Dahlqvist]

OS->All.

Comment 27

[Pete Zha]

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

Comment 28

[Raphael Clifford]

Attachment: picture of print preview mode showing overlapping text

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.

Comment 29

[Raphael Clifford]

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

Comment 30

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 31

[Carsten Menke]

Attachment: The worst I found.

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

Comment 32

[David K. Dean]

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?

Comment 33

[Carsten Menke]

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.

Comment 34

[Carsten Menke]

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

Comment 35

[Pratik]

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

Comment 36

[John T]

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.

Comment 37

[John T]

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.

Comment 38

[Markus Neteler]

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

Comment 39

[David K. Dean]

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.

Comment 40

[Devoti Paolo]

see also bug 202935 and bug 193471 

Comment 41

[Devoti Paolo]

Attachment: testcase 1 showing the effect of proportional font

compare print preview with the one of testcase 2

Comment 42

[Devoti Paolo]

Attachment: testcase 2 showing the effect of proportional font

Comment 43

[Vedran Miletic]

retargeting

Comment 44

[Boris Zbarsky [:bzbarsky]]

.

Comment 45

[Ruth Ivimey-Cook]

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.

Comment 46

[Ruth Ivimey-Cook]

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%.

Comment 47

[Ruth Ivimey-Cook]

Attachment: Clips of problem text

See other comment

Comment 48

[damn23]

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.

Comment 49

[John T]

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.

Comment 50

[:aceman]

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.

Comment 51

[:aceman]

Attachment: Print preview on a HPLJ2000 printer.

Comment 52

[:aceman]

Attachment: Print preview on an Olivetti DM 309 (a 9-dot matrix printer with max. resolution of 240x144 dpi)

Comment 53

[:aceman]

This was with Mozilla 1.6final.

Comment 54

[Shai Berger]

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.

Comment 55

[John T]

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.

Comment 56

[Shai Berger]

(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.

Comment 57

[John T]

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.

Comment 58

[John T]

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?

Comment 59

[Ruth Ivimey-Cook]

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.

Comment 60

[John T]

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.

Comment 61

[Boris Hajduk]

Attachment: The simplest testcase I could design

Comment 62

[Boris Hajduk]

Attachment: Browser-view of the testcase is OK

Comment 63

[Boris Hajduk]

Attachment: Print-preview shows text beyond the end of the table cell !

Comment 64

[Boris Hajduk]

Attachment: Final print on Epson EPL-6200 prints ok (but slightly different from browser-view)

Comment 65

[Boris Hajduk]

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.

Comment 66

[Jan Van Looy]

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

Comment 67

[Wayne Mery (:wsmwk)]

(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?

Comment 68

[Wayne Mery (:wsmwk)]

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?

Comment 69

[Wayne Mery (:wsmwk)]

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

Comment 70

[Wayne Mery (:wsmwk)]

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

Comment 71

[Wayne Mery (:wsmwk)]

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

Comment 72

[Peter Weilbacher]

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

Comment 73

[Wayne Mery (:wsmwk)]

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

Comment 74

[amit]

Attachment: Please fix this problems

Comment 75

[Wayne Mery (:wsmwk)]

Comment on attachment 201093 [details]
Please fix this problems

not a patch

Comment 76

[Wayne Mery (:wsmwk)]

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

Comment 77

[Philip Withnall (unavailable)]

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

Comment 78

[Xudong Guan]

Attachment: Test case that shows problem for Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0

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

Comment 79

[Xudong Guan]

Attachment: Preview screen shot of the Test case with attachment ID: 242856.

Comment 80

[Xudong Guan]

Attachment: Preview of the above test case in Firefox 1.5.0.7 (SuSE, Portuguese)

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).

Comment 81

[Peter Weilbacher]

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.

Comment 82

[Wayne Mery (:wsmwk)]

Attachment: testcase causes extra spaces and superscript

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

Comment 83

[Eli Friedman]

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.)

Comment 84

[Dan]

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.

Comment 85

[Eli Friedman]

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.

Comment 86

[Wayne Mery (:wsmwk)]

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

Comment 90

[Martin Tůma]

Attachment: Original page & buggy output as PDF

Comment 91

[Martin Tůma]

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.

Comment 92

[Daniel Holbert [:dholbert]]

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