Open Bug 399225 Opened 17 years ago Updated 2 years ago

printing selection prints in extremely small font and with very long lines; table-related?

Categories

(Core :: Printing: Output, defect)

defect

Tracking

()

People

(Reporter: dsb, Unassigned)

References

()

Details

(Whiteboard: [SmBugEvent])

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070509 SeaMonkey/1.1.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070509 SeaMonkey/1.1.2

When a selection of text is printed (by selecting text, and then choosing the "selection" option in the "Print Range" set of options), Seamonkey prints the text in an extremely small font (maybe 5 or 6 points).

One particular symptom is that the text is formatted in very long lines (about 320 characters per line).

I wonder if something is wrong with picking the initial box into which to render the text.  (I can't tell if Seamonkey is picking a very wide box, formatting the text at a normal font size, and then reducing everything to fit on the printed page, or if Seamonkey picked a very small font size for some reason and then otherwise formatted the text normally to dimensions of the printed page.)


Reproducible: Always

Steps to Reproduce:
1. Display http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/
2. In section 3.4.2, select from the first occurrence of "{attribute wildcard}" to right before the following occurrence of "{content type}".
3. Issue the Print command.
4. In the Print dialog box, the "Print range" section, select "Selection."
5. Click Okay and print the document.
Actual Results:  
The selection text is printed in a very small font (about 5 or 6 points).

The lines of text are very long (many characters per line).  (For example, of all the paragraphs in the selected text, only the paragraph label 2.2.1 wraps to a second line (after "corresponding to the").)

Expected Results:  
The text should have been formatted and printed using a more reasonable font size (10 or 12 points, I guess).

The text selection specified above contained text from two adjacent table cells.

Thinking that that might be significant, I tried again without the initial text "{attribute wildcard"} from the first column.

Strangely, although the text selection now contained text from only one column, the printed result still had blank space on the left corresponding to the space in which the text "{attribute wildcard}", from the first column, printed the first time.


Additionally, selecting a paragraph outside a table and trying to print the selection yields zero pages in the print job.  (I get a header page that something in my environment prints before any print job from any tool, but then I don't get any page at all from Seamonkey.)

Therefore, it appears that something is seriously broken with the print-selection feature.
Can you reproduce with SeaMonkey v1.1.9 ?
Version: unspecified → SeaMonkey 1.1 Branch
(In reply to comment #1)
> Can you reproduce with SeaMonkey v1.1.9 ?

No.  

It looks fixed.  (I don't see the symptoms I reported.  What I do see looks fine.)

Thanks to whomever fixed the bug.
Still an issue in SM2. Suitable is product Core with component Printing: Output but leaving this in Seamonkey to match search runs.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: x86 → All
Version: SeaMonkey 1.1 Branch → Trunk
Moving to Core::Printing
Assignee: general → nobody
Component: General → Printing: Output
Product: SeaMonkey → Core
QA Contact: general → printing
Whiteboard: [SmBugEvent]
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.