Can't print background colors

RESOLVED FIXED in Camino0.7

Status

Camino Graveyard
Printing
--
major
RESOLVED FIXED
15 years ago
15 years ago

People

(Reporter: John Baggaley, Assigned: Conrad Carlen (not reading bugmail))

Tracking

unspecified
Camino0.7
PowerPC
Mac OS X

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1) Gecko/20021207 Chimera/0.6+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1) Gecko/20021207 Chimera/0.6+

I can't find any way to print the background colors on web pages. When printing
web pages, they look absolutely terrible. MS IE on the Mac has an option to
print background colors. Whenever I print, I have to copy and paste the URL from
Chimera to MS IE and print from MS IE.

Reproducible: Always

Steps to Reproduce:
1. print any web page with background colors

Actual Results:  
No background colors appear in the printed document

Expected Results:  
Background colors appear in the printed document
(Assignee)

Comment 1

15 years ago
See bug 155556, comment 9.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Target Milestone: --- → Chimera0.7

Comment 2

15 years ago
I want to throw a PDE together for Chimera. It should be reallly easy in Cocoa.
(Assignee)

Comment 3

15 years ago
Why just for Chimera? If you do that, it should be for mozilla as well. Also, by
default, embedding apps are using the same printing UI code which would try to
load the same PDE.

Comment 4

15 years ago
> Why just for Chimera?

Because I'm  not sure a Cocoa PDE will work in a Carbon app, and vice versa.
Although the print dialogs are shown via Carbon, so maybe it will have to be a
Carbon PDE. Bleuch. Either way, I think we should nib-based UI.
(Assignee)

Comment 5

15 years ago
> Either way, I think we should nib-based UI.

Yeah, I think it will, since in either case, the printing dialogs are Carbon.

I'm working on the nib-based sample PDE from Apple and, using Interface Builder,
have it loading a control hierarchy which I laid out in IB instead of a single
control.
(Assignee)

Comment 6

15 years ago
Created attachment 110070 [details]
In-progress adaptation of DTS sample PDE

Very rough - none of the names and IDs have been changed from the sample. Also,
there is a local copy of nsPDECommon.h in the project dir which obviously
doesn't belong there. That was so I could work on it outside a mozilla tree and
test with AppUsingSheets. Those changes need to be made to the real copy of
that file.

From the sample, the files PDECore.c and PDEUtilities.c should not have to
change. I did have to make 1 change to PDECore.c. It was not embedding the
controls early enough and was calling the routine to sync the pane with the
print data before the controls in the pane existed (???)

Then, nsPrintingPromptServiceX.cpp needs some changes:
(1)
http://lxr.mozilla.org/seamonkey/source/embedding/components/printingui/src/mac/nsPrintingPromptServiceX.cpp#83

Now that nsILocalFileMac has GetCFURLRef(), this code can be simplified and it
will be the same for Mach and CFM except for (grrr) "Essential Files".
(2) The values from the plugin (the new stuff defined in nsPDECommon.h) need to
be used here:
http://lxr.mozilla.org/seamonkey/source/embedding/components/printingui/src/mac/nsPrintingPromptServiceX.cpp#192
(Assignee)

Comment 7

15 years ago
Simon, I have this close to done. I'm going to move where the PDE gets built
from gfx/printerplugin to embedding/components/printingui/src.mac.

Comment 8

15 years ago
Sounds good to me.
(Assignee)

Comment 9

15 years ago
Created attachment 110248 [details] [diff] [review]
new PDE

  This is a new print dialog PDE, which will replace the one in gfx. The one in
gfx needed to be replaced because the project was never checked in (only the
plugin binary) and it used ResourceManager (non-localizable) resources. The new
one uses a nifty Nib-based UI so that it's much easier to add new UI to it in
the future, and localization is done on separate text files.
  It's a Project Builder project, buildable from a makefile. When built from
the makefile, the finished plugin is copied to dist. The makefile in
xpfe/bootstrap picks it up from there when building the app bundle. I think
this is better than having the xpfe/bootstrap makefile grovel into the tree for
pieces of the bundle. It's what I want to do with the Resource Mgr resources
components define. Perhaps we should have a "macbuild" or some such dir in the
top level of dist for this purpose? Maybe called "macbundle?"
  Though not included in the diff, gfx/src/mac/printerplugin, can be removed
once this is checked in. For the CW build, I really don't want to check in a
built copy of the new plugin. Either we can build a Mach-O plugin bundle with
CW or, ahem, the PDE feature is only supported on Mach-O builds.
  The new code uses the same POD struct to hold the settings between the app
and the plugin. If somebody had saved a print settings setup with the old
format data, it will now be of an unexpected size and safely default to new
settings. I think we can live with this.
Attachment #110070 - Attachment is obsolete: true
(Assignee)

Comment 10

15 years ago
Forgot to mention: the 4 files which still have the Apple copyright are
untouched from their original form. If I understand the copyright notice, that's
what should be done. Modified files have the MPL on them. Since we have other
Apple DTS sample code in the tree, I'm assuming the license issue isn't one. 
(Assignee)

Comment 11

15 years ago
Created attachment 110348 [details] [diff] [review]
Chimera part

The trunk patch for the PDE applies just fine to Chimera branch. This patch
just copies the PDE plugin into Chimera's bundle.
(Assignee)

Comment 12

15 years ago
Checked into Chimera. In the print dialog, choose "Web Browser." There, you can
turn on or off background colors & images, as well as some other things.

* "Web Browser" was chosen as the menu title because this PDE will be used by
Chimera, Mozilla, embedding apps, etc. There needs to be some way to set this 
during the build process (maybe by munging the PDE's Localized.string with sed?).
* Printing BG colors & images still defaults to OFF. I think now it should
default to ON
* It would be nice to have control over printing of headers and/or footers. At
this point, it would be easy to add.

Comment 13

15 years ago
Print options for bg color and bg images are defaulted off in the dialog.
Verifying that enabling them will allow user to print the assign bg color or bg
image on page. Also, frame printing is working for the selected frame (and
active selection) as well as each frame seperately. Tested with the
2002-12-31-04 NB under 10.2.3.

Comment 14

15 years ago
This is in now.
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
(Assignee)

Comment 15

15 years ago
I'll just make a different bug to get this PDE stuff checked into the trunk.
You need to log in before you can comment on or make changes to this bug.