278267 - text-align property rendered incorrectly in print preview

Status: RESOLVED WORKSFORME

(Core :: Print Preview, defect)

Description

[Hadrien Nilsson]

Go to the specified URL, notice the blue rectangles with text inside. There is
dl list, a li list and a p. In those three cases, the text should be justified.
It is actually but not in print preview. In print preview, pieces of text are
going out randomly out of the rectangle.

If you try a text-align: right; instead, you will notice the same kind of problem.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050113

Comment 1

[Gérard Talbot]

Attachment: 3 texts being replaced by "*"

I took a random text (reporter's 1st parg. in description comment), then use it
in <dd>, <li> and <p>, and make a copy of it by replacing each character
(including commas and periods) by "*". 

If you examine the results in print preview (scale: 100%), you'll see that
normal text is justify-aligned very close to perfection. It's the "*" text that
is not well justify-aligned, that has alignment problems. At a larger scale,
both types of text are well rendered in print preview; I have not tested actual
printing though.
MSIE 6 SV1 and Opera 8.0 beta 1 do a better job of justify-alignment of both
types of text in print preview.

Mozilla 1.8b 2005011308 under XP Pro SP2 here.

Comment 2

[Gérard Talbot]

Attachment: Better testcase: same testcase as previous but with media="all" implied

Same testcase as previous one but with media="all" implied. The rendered
justify-alignment on screen is more accurate (closer to expectation) than the
one in print preview at scale: 100%.

Comment 3

[Hadrien Nilsson]

Attachment: Screenshot of attachment 171241 renderer at 90% in print preview

With a print preview of 90% the bug arises with the attachment test case
aswell.

The margins are set to 0 for the printing options. I've got the same behaviour
with Firefox 1.0 btw.

Comment 4

[Gérard Talbot]

I couldn't find a duplicate for this.

CONFIRMING

Comment 5

[Boris Zbarsky [:bzbarsky]]

This could use a minimal testcase....

Comment 6

[Gérard Talbot]

Boris, I don't know (not sure) what you mean. I thought the current testcase was
adequate (covering 3 types of text), though maybe not minimal.

Only 1 thing to add to the steps to reproduce. When viewing attachment 171241 [details] in
Print Preview mode, then Page Setup... button/Options/Print Background (colors &
images) checkbox must be checked to see the background color and the box created.

I tried again attachment 171241 [details] with yesterday's build and the layout bug varies
with/is more or less noticeable, important depending on % scale.

Comment 7

[Boris Zbarsky [:bzbarsky]]

I mean _minimal_ testcase. Does the bug appear if you don't set the font family?
 If you don't use <dl>?  If you use less text?  If you don't set the width?

The testcase should have as few tags, CSS rules, and characters as possible (in
that order, preferably) while still reproducing the problem reliably....

Comment 8

[Gérard Talbot]

Attachment: Reduced testcase

Instructions: File/Print preview. Make sure Page SetUp has Options, Print
Background (colors & images) checkbox is checked. Then view this text and the
text below with various scale values. Expected results: all text, characters
should be inside the purple-blue background boxes.

CSS declarations of the testcase: 
p
{
	width: 300px; font-size: 12px;
	background: #ccf;
	text-align: justify; /* or right */
}

The bug is not noticeable with any/all scale values and is not that important
when using real normal text. 

Nota bene: I tried with other characters (like wide ones: X or W; or narrow
ones: l or i) and there too, the bug is not always present and only present for
a few particular scale values.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Since not all platforms allow changing the scale value in print preview, can you
do a testcase that shows the problem at the default scale value?

Comment 10

[Gérard Talbot]

> Since not all platforms allow changing the scale value in print preview, can 
> you do a testcase that shows the problem at the default scale value?

The provided testcase shows the problem at "shrink to fit" and at 100% scale
value under XP Pro SP2. Since I do not use anything else than windows XP, I do
not know how I can create another suitable testcase for you or for other
undefined platforms.

Btw, I may have been wrong here and again. <gulp> Honest, unfortunate oversight,
somehow. Bug 185233 looks like a dup of this bug... (or is it the reverse?) I
don't know. Boris, I will let you decide what to do here as I elegantly remove
myself from the CC list, ... again. There.

Adding qawanted keyword

Comment 11

[Gérard Talbot]

Hadrien,

I loaded attachment 174767 [details] in Firefox 3.0 RC1 rv:1.9 build 2008051206 under XP Pro SP3 and then followed instructions and in print preview, the "*" characters are always inside the purple background boxes and this with various scale values, ranging from 70% to 175%, including 100% and fit-to-width. I also tried attachment 171241 [details] and I got expected results with scale values ranging from 70% to 175%, including 100% and fit-to-width.

WFM

Can you try yourself too?

Comment 12

[Hadrien Nilsson]

Tested with :
Mozilla/5.0 (Windows; U; Windows NT 5.0; fr; rv:1.9) Gecko/2008051206 Firefox/3.0

Works fine now when we change the scale by using the combo box.

The problem still arises when we zoom the page with Ctrl + Mouse Wheel.

Comment 13

[Gérard Talbot]

Yes, there is still a problem ("*" characters overflow of background purple-colored area) when using Ctrl + Mouse Wheel in Print preview to increase scale value.

Comment 14

[Hadrien Nilsson]

Cannot reproduce with Firefox 56 on Windows 10 and Ubuntu 17.10