Closed
Bug 187184
Opened 22 years ago
Closed 21 years ago
[ps] border-top under linux prints all four borders under linux but displays correctly to screen. In win2k, screen and print work correctly.
Categories
(Core :: Printing: Output, defect, P3)
Tracking
()
RESOLVED
FIXED
Future
People
(Reporter: jcardwell, Assigned: rods)
Details
Attachments
(6 files)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212
Under CSS, border-top:1px causes all four borders to print, even though in print
preview only the top border shows up. Using Mozilla 1.3a - the problem occurs
only under Linux actual printout (not print preview) and only when position is
set to something other than static. Does not occur on Win2k/IE
nor in Win2K/Mozilla1.3a.
Reproducible: Always
Steps to Reproduce:
1.Create style rule div.one
{position:relative;display:block;top:0;left:0;border-top:1px solid black}
2.create html: <html><body><div class="one">some text</div></body></html>
3.File->print-preview (linux) sometext has a line above it, file->print prints a
box around the line
Actual Results:
Box prints around the text
Expected Results:
A line above the text
Reporter | ||
Comment 1•22 years ago
|
||
test case for this bug - test under linux in my case I print to laserjet 4100N
Comment 2•22 years ago
|
||
WorksForMe perfectly with Xprint module (see
http://www.mozilla.org/releases/mozilla1.0.2/#xprint), seems to be a
PostScript-module only bug...
Comment 3•22 years ago
|
||
marking as "[PS]"-only bug
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: border-top under linux prints all four borders under linux but displays correctly to screen. In win2k, screen and print work correctly. → [ps] border-top under linux prints all four borders under linux but displays correctly to screen. In win2k, screen and print work correctly.
Comment 4•22 years ago
|
||
I believe I am experiencing the same bug, manifesting differently. If I set...
h2 {
border-bottom: solid 1px;
}
in a stylesheet, I get a border around the body in the document, only when
printing. When print previewing, the border is not present.
Comment 5•22 years ago
|
||
I should mention that I am using 1.3b under Linux, printing in postscript.
Comment 6•22 years ago
|
||
This HTML file will print out correctly in Mozilla/win-32 but not in
Mozilla/Linux
Comment 7•22 years ago
|
||
Incorrect (Mozilla/Linux) print of previous HTML
Comment 8•22 years ago
|
||
Correct (Mozilla/Win-32) print of previous HTML
Comment 9•22 years ago
|
||
I attached some files that shows a similar bug (that has been lurking in
Mozilla/Linux for some time - not sure why I didn't report it before)
Anyway, the print preview of the HTML will show no border, yet when one prints
the page, a faint border will appear. If you print the same page in Windows
there is no border.
The files were created with print-to-file (linux) and Adobe Distiller (windows)
if it matters any.
I have noticed that this bug (a border around the page) also occurs when you use
tables to frame the page, but I don't have a testcase to illustrate that right
on me (but could create one if anyone is interested)
Hopefully my spamming of everyone with test examples (sorry for the flurry of
emails) helps identify the source of the bug.
Comment 10•22 years ago
|
||
The postscript code generation is bogus. A clipped path is set up for
each page body, but not cleared. Hence, the next (and, for that matter,
due to gsave'ing and grestore'ing, every) solid border drawn will get
appended to the clipping path.
TESTCASE
The test case is actually much more trivial than the ones given above:
<html>
<body>
<p style="border: 1px solid red;">buggy</p>
<p style="border: 1px solid green;">ok path</p>
</body>
</html>
Print this document to PostScript and watch the red bordered
paragraph trigger the bug.
FIX
The current path needs to be always cleared after clipping.
WORKAROUND
Edit the PostScript file and insert
/clip { clip newpath } bind def
somewhere into the prolog.
Comment 11•22 years ago
|
||
The testcase in my previous comment (#10) should read
<html>
<body>
<p style="border: 1px solid red;">buggy</p>
<p style="border: 1px dashed green;">ok path</p>
</body>
</html>
of course. Point of the green box was to show that dashed or dotted borders do
not trigger the bug.
Sorry about the glitch.
Updated•22 years ago
|
Priority: -- → P3
Target Milestone: --- → Future
Reporter | ||
Comment 12•21 years ago
|
||
This is a workaround: printing a white border with a different style on the
other sides of the division works around the problem. Similarly, putting a
white (assuming background is white) border with different style prevents
containing divs from having a border when printed in the case of a bordered div
causing contained within other non-bordered divs.
Comment 13•21 years ago
|
||
The fix for bug 80190 contained a fix for this problem.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•