389949 - On Linux, Landscape mode prints in Portrait mode

Status: RESOLVED FIXED

(Core :: Printing: Output, defect, P2)

Description

[Edward]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a7pre) Gecko/2007072603 SeaMonkey/2.0a1pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a7pre) Gecko/2007072603 SeaMonkey/2.0a1pre

When printing a web page with SeaMonley 2.0 for Linux, the footers will not print at the bottom of the page.  This was originally mentioned in Bug 382743.  

Also, when printing in Landscape mode, it continues to print in Portrait mode, but the printing will start around the top quarter of the page and both headers and footers will not print at all.  This was thought it might be Bug 381631, please see Bug 382743 for comments.

Reproducible: Always

Steps to Reproduce:
1.Load any web page.
2.Click Print (or select File/Print) and print page.
3.Footers will not print at the bottom of the page.

4.Select Landscape mode and print.
5.Page prints in portrait mode beginning one quarter down the page and both headers and footers will not print in this instance.

Actual Results:  
Footers would not print when printing in Portrait mode.
Both headers and footers would not print in Landscape mode.


Expected Results:  
Portrait mode:  Footers should have printed.
Landscape mode:  Bot headers and footers should have printed and the printing should have begun at the top of the page.

Printer is an HP DeskJet 3930 using the 3900 driver.

Problem occurs with SeaMonkey 2.0 for Linux, using openSUSE 10.2.

Comment 1

[Edward]

Bug 382743 mentioned above is INCORRECT.  

Please see Bug 387243 for comments.

Comment 2

[Kenneth Herron]

This is really two separate issues.

Edward, could you print a page in landscape mode to a file and attach it to this bug? Preferably something short -- a blank page would be fine.

Comment 3

[Edward]

Attachment: Page saved as file, per request.

Comment 4

[Edward]

In the attached file, the headers and footers are shown.  However, when this file was printed, the header was chopped off and the footers did not print at all.

Comment 5

[Kenneth Herron]

As you note, the footers are present in the output file. If your printer isn't printing them, the simplest explanation is that they're positioned too close to the edge of the paper for your printer. You can adjust the printable region boundaries through the printer properties dialog:

1) Open File->Print
2) Select the printer of interest
3) Click Properties
4) Adjust the margins in the dialog that appears

Regarding landscape mode, the sample print job is definitely formatted as portrait. I tried a self-built copy of seamonkey from 7/28 and a copy of the 7/26 nightly, and I was able to print landscape from both of them without much trouble:

1) Open File->Page Setup
2) Select the "landscape" radio button
3) Click "Ok" to close the dialog
4) Open File->Print
5) Optionally select "Print to file"
6) Click "Print" to print

However, after step 4, if I changed the printer preselected by the dialog, then I got a portrait printout. The reason is our Fine print settings logic: each printer has its own landscape/portrait flag; changing it in Page Setup only affects the current default printer (as well as the "global" setting, which is overridden by the individual printer settings). To get a landscape printout on the changed printer, I had to do the following:

1) Print once to the printer to make it the default (print to file is fine).
2) Return to Page Setup and set the landscape flag again.
3) Print again to the same printer.

Comment 6

[Edward]

I changed the bottom margin in the settings from the default (.55) which works perfectly in SeaMonkey 1.1.3 (and 1.1.5pre), to 0.4" and 0.7" and in both instances, the footers still would not print with SeaMonkey 2.0.

The headers are also spread too far apart at the top, as the far left and far right of the headers are chopped off when printing with SM 2.0.

Since the printer settings used with SM 1.x work and were imported into SM 2.0 when it was installed, I cannot see why all of a sudden, there are printing issues with 2.0.

Comment 7

[Edward]

In Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.9a8pre) Gecko/2007090804 Minefield/3.0a8pre (latest nightly available)

I am also seeing the same behavior, footers nor printing and headers chopped off at both the left and right sides of the paper when printing.  

Comment 8

[Edward]

Kenneth - I changed the margins all the way around to all zeros and the headers are still chopped off.  As this problem is NOT present in the latest SeaMonkey (1.1.x) and Firefox (2.x) releases for Linux, from what I can tell, something changed in the FF 3 and SM 2 (both Linux) trunks (?) where the headers are now too far apart, causing them to be chopped off, even with zero margins.  

The footers do not print at all in SM 2 and FF 3 (both Linux), regardless of the margin settings.

Comment 9

[Edward]

"The footers do not print at all (Portrait mode) in SM 2 and FF 3 (both Linux), regardless of the margin settings."

Neither headers nor footers will print in Landscape mode.

Comment 10

[Edward]

Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.9a9pre) Gecko/2007102902 SeaMonkey/2.0a1pre

Print Preview will display page with footers, headers are not displayed.

Printing to an Epson Stylus Color 400 printer:  neither headers nor footers will print in Portrait mode.  

In Landscape mode, Print Preview only displayed the footers, no headers.  The page prints in Portrait, it is also shifted over to the right and neither headers nor footers printed.

Comment 11

[Edward]

In regards to comment 10, the results are the same as in my original comment (comment 1).

Comment 12

[Edward]

This nightly:

Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.9b2pre) Gecko/2007112602 SeaMonkey/2.0a1pre

appears to have fixed this problem.  

Comment 13

[Jason Bassford]

No bug or patch referenced as the fix.

Comment 14

[Edward]

On my laptop which uses 1400x1050 (SXGA+) resolution by default, the headers are not displayed in Print Preview (the footers are) and both headers and footers will print fine.

Comment 15

[Edward]

Reopening bug.  The nightly referenced in comment 12, Print Preview displayed the headers and footers only after the very first launch of SeaMonkey after installation, on a desktop with 1280x1024 resolution.  Print Preview has NOT displayed the header at all since then.  

On the laptop referenced in comment 14, headers have not displayed at all, even on the first launch of SM after installation of same nightly (2007112602).

The Print Setup selection of this nightly continues to reference millimeters for margins instead of inches - not known if this has something to do with this issue.

Comment 16

[Edward]

In the latest niightly trunk build:

Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.9b2pre) Gecko/2007112802 SeaMonkey/2.0a1pre

Print Preview (Portrait):  Headers are -not- displayed, footers are displayed, resulting printout shows both headers and footers printed, printing appears normal.

Print Preview (Landscape):  Headers are also not displayed, footers are displayed, resulting printout prints in Portrait mode instead, with both headers and footers printed but chopped off at right margin and printing began at about 1/3rd down the page.

Comment 17

[Edward]

To clarify comment 15 above, the headers only appeared in Print Preview that one time, all subsequent launches of that nightly trunk of SM did not display the headers in Print Preview.

Comment 18

[Edward]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b3pre) Gecko/2008011402 SeaMonkey/2.0a1pre

In the current nightly, Landscape mode still prints as portrait.  When Print to File is used, the file that is created, is opened with the Evince Document Viewer by default (using Mandriva Linux with Gnome desktop).  Although the displayed file was in Landscape, Evince still printed the file in Portrait, even after the print settings in Evince were also set to Landscape.  It would appear that there is also a problem with SM 2's Print To File option.

Comment 19

[Edward]

Editing title of bug as headers and footers are printing.  

Comment 20

[Kenneth Herron]

Edward, could you attach a new sample print to file? Maybe not something completely blank this time.

Comment 21

[Edward]

Attachment: File per request

Attaching a sample print of the Mozilla home page.  In the file, the headers and footers are displayed, but when printing from the browser directly, the headers and footers did not print in Landscape mode.  This may also be helpful in addressing bug 336672.

I also noticed that in the currently nightly:  Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.9b3pre) Gecko/2008012601 SeaMonkey/2.0a1pre  the Page Setup nor Print screens ave anything to change the page margins as prior nightlies did.

Comment 22

[Daniel Holbert [:dholbert]]

(In reply to comment #21)
> Created an attachment (id=299488) [details]
> File per request
> 
> In the file, the headers
> and footers are displayed, but when printing from the browser directly, the
> headers and footers did not print in Landscape mode.

Just to clarify -- so, you're saying that print-to-file is fine, but when you print to a *real* printer in landscape mode, it chops off the headers & footers?

Comment 23

[Edward]

Correct.

I am using Mandriva Linux with the Gnome desktop, this uses Evince Document Viewer by default, to open/view/print PostScript files.  Although I did not see any particular settings in Evince pertaining to margins or landscape/portrait, Evince will automatically print the document as it is formatted, a landscape file will print in landscape, a portrait file will print in portrait.

I also did the same test using SeaMonkey 1.1.8pre, print-to-file works.  Print files saved using 1.1.8pre as both Landscape and Portrait, printed perfectly, including all headers and footers.

Comment 24

[Kenneth Herron]

Attachment 299488 [details] is formatted as a landscape document, with a landscape oriented bounding box. However, my mac's preview utility displays the document as if it were portrait, so the top part of the page is empty and some of the text runs off the right side.

I tried adding %%DocumentMedia and %%Orientation directives to the file's DSC, but neither of these affected the way preview would display the file. What did make a difference was to add a setpagedevice directive "<< /PageSize [ 792 612 ] >> setpagedevice" to the file. Once I added this, preview would display the file as a landscape document.

I still think the problem with headers & footer is just that they're too close to the edge of the paper. In your latest attachment, they're only about 1/10th of an inch from the edge of the paper.

As I recall, gecko uses the printable region margins to position the headers & footers. There used to be UI to adjust the values, but the new dialogs following bug 193001 don't seem to have anything for that. Maybe gecko should position them just outside the content margins rather than just inside the printable region margins.

Comment 25

[Edward]

I believe this feature (margin/header/etc. settings) needs to be restored. 

For both of my HP DeskJet printers using SM 1.8.x, I changed the bottom margin (in the Print settings) to .60" in order for the footers to print.  If that setting remained at the default .50", then they would not print.

If the headers and footers in the attachment are really that close to the edge of the paper, then it is an excellent argument in favor of restoration of that feature, as there is no place to change that setting...

Comment 26

[Kenneth Herron]

Come to think of it, the headers in the sample may be close to the edge of the paper because it was a print-to-file operation. Gecko should be getting the printable region from the GTK printing system, and GTK's print-to-file printer may have very small margins. When you print to an actual printer, GTK should get the margins from the printing system--CUPS, for example--and gecko should use those.

The old user interface for setting the printable region was a workaround for the fact that the old printing code was poorly integrated to the platform printing system. There was no way to get accurate information about the actual target printer. That's not the case now.

Comment 27

[Daniel Holbert [:dholbert]]

So, I see two remaining issues here, *both* when printing to an actual printer under Linux.

   A. Printer margins seem to be completely ignored. (regardless of orientation)

   B. When printing in Landscape mode, the output is rotated 90 degrees, so that I've got a landscape-oriented printout placed on portrait-oriented paper, with the lower-left corners lined up.
  i.e. I get something like this, where the parenthesized text is stuff that doesn't show up on the actual printout.
  --------------------------
  |                        |
  |                        |
  |Page Title              |(http://a.b)
  | Content  Content  Conte|(nt Content)
  | Content  Content  Conte|(nt Content)
  | Content  Content  Conte|(nt Content)
  | Content  Content  Conte|(nt Content)
  | Content  Content  Conte|(nt Content)
  | Content  Content  Conte|(nt Content)
  | Content  Content  Conte|(nt Content)
  | Content  Content  Conte|(nt Content)
  |Page 1 of 1             |
  --------------------------

I'll probably file a separate bug for Issue A, unless one already exists.

Comment 28

[Daniel Holbert [:dholbert]]

(In reply to comment #27)
>    A. Printer margins seem to be completely ignored. (regardless of
> orientation)
> ...
> I'll probably file a separate bug for Issue A, unless one already exists.
> 

Filed bug 417356 for Issue A.

Comment 29

[Daniel Holbert [:dholbert]]

I can work around the bug by forcing us to use a PDF surface instead of a PS surface here:
http://mxr.mozilla.org/seamonkey/source/widget/src/gtk2/nsDeviceContextSpecG.cpp#477
 477   if (format == nsIPrintSettings::kOutputFormatPDF) {
 478     surface = new gfxPDFSurface(stream, surfaceSize);
 479   } else {
 480     surface = new gfxPSSurface(stream, surfaceSize);
 481   }

So, the issue seems to be specific to the gfxPSSurface class.

Comment 30

[Michael Ventnor]

(In reply to comment #29)
> I can work around the bug by forcing us to use a PDF surface instead of a PS
> surface here:
> http://mxr.mozilla.org/seamonkey/source/widget/src/gtk2/nsDeviceContextSpecG.cpp#477
>  477   if (format == nsIPrintSettings::kOutputFormatPDF) {
>  478     surface = new gfxPDFSurface(stream, surfaceSize);
>  479   } else {
>  480     surface = new gfxPSSurface(stream, surfaceSize);
>  481   }
> 
> So, the issue seems to be specific to the gfxPSSurface class.
> 

We really should not do that. Lots of aging printers have had problems because we send PDF data to it (CUPS doesn't do any kind of translation or filtering).

Comment 31

[Daniel Holbert [:dholbert]]

(In reply to comment #30)
> (In reply to comment #29)
> > I can work around the bug by forcing us to use a PDF surface instead of a PS
> > surface here:
> We really should not do that. Lots of aging printers have had problems because
> we send PDF data to it (CUPS doesn't do any kind of translation or filtering).

Agreed -- I wasn't suggesting that as the final fix, I was just pointing it out to indicate that the problem is specific to gfxPSSurface.

Comment 32

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

From the generated file:

%!PS-Adobe-3.0
%%Creator: cairo 1.5.5 (http://cairographics.org)
%%CreationDate: Sat Jan 26 20:23:10 2008
%%Pages: 2
%%BoundingBox: 0 0 792 612
%%DocumentData: Clean7Bit
%%LanguageLevel: 3
%%EndComments
%%BeginProlog

%%Page: 1 1
%%BeginPageSetup
%%PageBoundingBox: 0 0 792 612

Page 2 is the same.  Are there any other DSC headers that we need here to indicate portrait mode?

Adrian, any ideas?  I see Kenneth tried %%Orientation in comment #24, and was able to get something working with a setpagedevice.  Though I realize now that Cairo has no idea what the page orientation is -- all it knows is the page bounding box, which it dutifully specifies in the PageBoundingBox.

Comment 33

[Daniel Holbert [:dholbert]]

FWIW, I think this is a more general problem with gfxPSSurface losing desired page-width/height information at some point. (not just orientation)

Below are 3 experiments as an example, which use custom page sizes instead of Landscape mode.  Tested using Ubuntu 7.10. Experiments A and C demonstrate the correct output, whereas Experiment B is broken.

 SET-UP
   1. Add a PDF printer in Ubuntu's printer-config dialog. (URI: "cups-pdf:/")  This printer generates its output in the folder ~/PDF.
   2. In either Firefox Trunk or gedit,  open the "Page Setup" dialog and create a custom 2in x 5in paper size.

 *Experiment A:
    1. In gedit's page setup dialog, select your custom 2x5 paper size.
    2. Print a gedit document to your Ubuntu PDF printer.
 *RESULTS: The generated PDF file is on 2x5in "paper", as expected.

 *Experiment B:
    1. In Firefox Trunk's Page Setup dialog, select your custom 2x5 paper size.
    2. Print google.com to your Ubuntu PDF printer.
 *RESULTS: The generated PDF file is on A4-size "paper" (presumably as a fallback?) with the 2x5in of content aligned at the lower-left corner. This is broken.

 *Experiment C:
    1. Start a Firefox debug build, with GDB connected
    2. Place a breakpoint at nsDeviceContextSpecG.cpp:477
    3. Perform Experiment B.  When you hit the breakpoint, set format = 2. (pdf surface) as mentioned in Comment 29, and then continue.
 *RESULTS: The generated PDF file is on 2x5in "paper", as expected.

Comment 34

[u285178]

(In reply to comment #32)
> Adrian, any ideas?  I see Kenneth tried %%Orientation in comment #24, and was
> able to get something working with a setpagedevice.  Though I realize now that
> Cairo has no idea what the page orientation is -- all it knows is the page
> bounding box, which it dutifully specifies in the PageBoundingBox.
 
The cairo reference has documentation on this:
http://www.cairographics.org/manual/cairo-PostScript-Surfaces.html#cairo-ps-surface-dsc-comment

It would appear that something like the following is required:

%%IncludeFeature: *LandscapeOrientation: Plus90

However this did not work for me. 

You may have to ask the CUPS developers.

Comment 35

[Daniel Holbert [:dholbert]]

I'm not sure how much gedit can be trusted as a "gold standard", but it looks like their PS output uses the *exact same* height & width for Portrait & Landscape mode, whereas FF3 *reverses* its height and width in Portrait vs Landscape mode.

i.e, here are the relevant headers from the PS output:
  gedit portrait mode:    %%BoundingBox: 0 0 612 792
  gedit landscape mode:   %%BoundingBox: 0 0 612 792
  FF3 portrait mode:      %%BoundingBox: 0 0 612 792
  FF3 landscape mode:     %%BoundingBox: 0 0 792 612   <--- Reversed!

On the plus side, this reversal makes FF3's landscape PS file look "right-side up" (i.e. short and wide) when viewed in a document viewerm, while gedit's landscape PS file is "tall and skinny" with the content turned on its side.

But on the minus side, it seems to make us print landscape-oriented content on portrait-oriented paper, when we print to a *real* printer.


One way to remedy this would be to effectively apply a 90 degree transform to the PS output, as suggested in comment 34 -- but we'd like to apply this transform *before* generating PS output, so that the PS file's bounding-box height and width are the same in landscape and portrait mode.  (like in gedit.)

Comment 36

[Reed Loden [:reed]]

hidenosuke, did you mean to reassign this bug to nobody@?

Comment 37

[Hideo Oshima]

(In reply to comment #36)
> hidenosuke, did you mean to reassign this bug to nobody@?
 
I'm sorry.
Perhaps, I think that it made a mistake. 

Comment 38

[Daniel Holbert [:dholbert]]

Attachment: hacky semi-patch

This hacky patch basically does the rotate as suggested in comment 35.

If I then manually tweak the bounds of the resulting .ps file to make them large, I can see that the document was correctly printed sideways, in landscape mode.

Outstanding issues:
 A. I'd like to do the rotation in nsSimplePageSequenceFrame (per the comment added there in this patch), but I can't right now because of compile errors.

 B. I need to fix the offsetting / page-bounds, so that I don't have to manually edit the outputted PS file's bounds in order to see the landscape-mode page in all its glory. :)

Comment 39

[Daniel Holbert [:dholbert]]

(In reply to comment #38)
Nice -- issue A is fixed by a simple #include "gfxContext.h".

Comment 40

[Daniel Holbert [:dholbert]]

Attachment: patch v1pre (has stupid whitespace changes)

While it's still a bit hacky, this patch essentially fixes the bug.

It makes...
 - physically-printed landscape-mode print correctly
 - print-to-file landscape-mode output be rotated on its side (with the 11-inch dimension being vertical), matching Gedit's output.  This is for both print-to-file/PS and print-to-file/PDF.

Things that may need investigating:
 - We still don't match Gedit in one case: printing to Ubuntu's "PDF Printer" ("cups://pdf" -- not to be confused with "print-to-file/PDF").
  When Gedit prints to the PDF Printer, the outputted page is oriented with the 11-inch dimension being horizontal, whereas Patched FF3 has the 11-inch dimension being vertical.  Maybe Gedit accomplishes this using something like "%%IncludeFeature: LandscapeOrientation" (from comment 34) in the intermediate postscript that it sends to the PDF printer...

 - I think the chunk added to nsPrintEngine.cpp probably needs to be #ifdef'd to be linux-only, or something like that, so it doesn't mess with landscape-printing on other platforms.

Comment 41

[Daniel Holbert [:dholbert]]

Comment on attachment 313734 [details] [diff] [review]
patch v1pre (has stupid whitespace changes)

oops, included some accidental whitespace changes -- reposting in a sec, without those.

Comment 42

[Daniel Holbert [:dholbert]]

Attachment: patch v1

(whitespace changes fixed)

Comment 43

[Daniel Holbert [:dholbert]]

Attachment: patch v2

- Improved comments
 - Added #ifdefs in nsPrintEngine.cpp and nsSimplePageSequence.cpp, to make changes linux-only.

Comment 44

[Daniel Holbert [:dholbert]]

Actually, something i changed is making this patch not quite work as expected anymore -- have to go now, but will fix it up soon.

Comment 45

[Daniel Holbert [:dholbert]]

(In reply to comment #44)
> Actually, something i changed is making this patch not quite work as expected

Hrm -- it looks like it's that MOZ_ENABLE_GTK2 isn't defined in nsPrintEngine.cpp or in nsSimplePageSequence.cpp, so those blocks I added aren't getting run.

Comment 46

[Daniel Holbert [:dholbert]]

Attachment: patch v3

This patch just replaces MOZ_ENABLE_GTK2 with XP_UNIX in the chunks added to nsPrintEngine and nsSimplePageSequence.  This makes the patch work as desired again.

Comment 47

[Daniel Holbert [:dholbert]]

Attachment: (attached wrong file)

This patch just replaces
  #ifdef XP_UNIX
with
  #if defined(XP_UNIX) && !defined(XP_MACOSX)
in the added chunks, because this is a linux-only thing that we don't want happening on Mac.

(A quick MXR search shows that we use this sort of check in quite a lot of places, actually.)

Comment 48

[Daniel Holbert [:dholbert]]

Attachment: patch v4

(oops, attached wrong file before.)

Comment 49

[Daniel Holbert [:dholbert]]

Comment on attachment 314182 [details] [diff] [review]
patch v4

Canceling review request, as I'd forgotten that I want to simplify the inches to points conversion in nsSimplePageSequence.cpp. :)

Comment 50

[Daniel Holbert [:dholbert]]

Attachment: Add POINTS_PER_INCH and POINTS_PER_INCH_FLOAT

I need to multiply by 72.0f points per inch, and I'll feel dirty if I use a magic number.  And we don't have 72.0f #defined anywhere yet.

Hence, this patch adds POINTS_PER_INCH_FLOAT and uses it in place of 72.0f everywhere that MXR could find it in the code.

Comment 51

[Daniel Holbert [:dholbert]]

Attachment: patch v5 (using POINTS_PER_INCH_FLOAT)

Comment 52

[Daniel Holbert [:dholbert]]

I just caught one thing I'll change in the POINTS_PER_INCH patch:

-#define POINTS_PER_INCH               72
+#define POINTS_PER_INCH_INT           72

(to match local naming style of TWIPS_PER_POINT_INT)

Comment 53

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Comment on attachment 314205 [details] [diff] [review]
Add POINTS_PER_INCH and POINTS_PER_INCH_FLOAT

Looks ok, but be careful of such cleanup this late in the game :)

Comment 54

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Comment on attachment 314206 [details] [diff] [review]
patch v5 (using POINTS_PER_INCH_FLOAT)

Looks good!

Comment 55

[Daniel Holbert [:dholbert]]

Attachment: Add POINTS_PER_INCH_INT and POINTS_PER_INCH_FLOAT

Thanks for the r+sr, vlad!

Here's the POINTS_PER_INCH_INT/FLOAT patch, ready to land, with the change from comment 52.

Comment 56

[Daniel Holbert [:dholbert]]

Checked in attachment 314219 [details] [diff] [review] (Add POINTS_PER_INCH_INT and POINTS_PER_INCH_FLOAT)

Checking in content/svg/content/src/nsSVGLength.cpp;
/cvsroot/mozilla/content/svg/content/src/nsSVGLength.cpp,v  <--  nsSVGLength.cpp
new revision: 1.31; previous revision: 1.30
done
Checking in content/svg/content/src/nsSVGLength2.cpp;
/cvsroot/mozilla/content/svg/content/src/nsSVGLength2.cpp,v  <--  nsSVGLength2.cpp
new revision: 1.9; previous revision: 1.8
done
Checking in gfx/public/nsCoord.h;
/cvsroot/mozilla/gfx/public/nsCoord.h,v  <--  nsCoord.h
new revision: 1.16; previous revision: 1.15
done
Checking in gfx/src/thebes/nsSystemFontsGTK2.cpp;
/cvsroot/mozilla/gfx/src/thebes/nsSystemFontsGTK2.cpp,v  <--  nsSystemFontsGTK2.cpp
new revision: 1.15; previous revision: 1.14
done
Checking in layout/base/nsPresContext.h;
/cvsroot/mozilla/layout/base/nsPresContext.h,v  <--  nsPresContext.h
new revision: 3.204; previous revision: 3.203
done
Checking in layout/style/nsROCSSPrimitiveValue.cpp;
/cvsroot/mozilla/layout/style/nsROCSSPrimitiveValue.cpp,v  <--  nsROCSSPrimitiveValue.cpp
new revision: 1.32; previous revision: 1.31
done

Comment 57

[Daniel Holbert [:dholbert]]

Checked in attachment 314206 [details] [diff] [review] (patch v5)

Checking in layout/generic/nsSimplePageSequence.cpp;
/cvsroot/mozilla/layout/generic/nsSimplePageSequence.cpp,v  <--  nsSimplePageSequence.cpp
new revision: 3.168; previous revision: 3.167
done
Checking in layout/printing/nsPrintEngine.cpp;
/cvsroot/mozilla/layout/printing/nsPrintEngine.cpp,v  <--  nsPrintEngine.cpp
new revision: 1.173; previous revision: 1.172
done
Checking in widget/src/gtk2/nsDeviceContextSpecG.cpp;
/cvsroot/mozilla/widget/src/gtk2/nsDeviceContextSpecG.cpp,v  <--  nsDeviceContextSpecG.cpp
new revision: 1.107; previous revision: 1.106
done

Closing as fixed -- woo-hoo!

Comment 58

[Ginn Chen]

https://litmus.mozilla.org/show_test.cgi?id=4020