Closed
Bug 36796
Opened 25 years ago
Closed 23 years ago
Mac Page Setup needs to be implemented [mac][print][print ui]
Categories
(Core :: Layout, defect, P3)
Core
Layout
Tracking
()
VERIFIED
FIXED
mozilla0.9
People
(Reporter: sfraser_bugs, Assigned: sfraser_bugs)
References
Details
(Keywords: helpwanted, Whiteboard: [PDT+])
Attachments
(1 file, 6 obsolete files)
(deleted),
patch
|
alecf
:
superreview+
|
Details | Diff | Splinter Review |
We need to implmement page setup/print setup, store the users preferred printer
settings etc.
Comment 1•25 years ago
|
||
This is a chrome issue... not sure who gets this..
Assignee: dcone → sfraser
Assignee | ||
Comment 2•25 years ago
|
||
So I take is support for saving the users's preferring Print Setup options is
implemented? What are the API calls I need to make?
Assignee | ||
Comment 3•25 years ago
|
||
Don: I'm sorry, but I don't see the APIs I can call for this anywhere. Print() is
a method on nsIContentViewerFile, but there is no corresponding PrintSetup
method. The only things I can see are in gfx/ps, which is way to low to call from
JavaScript.
Assignee: sfraser → dcone
Comment 4•25 years ago
|
||
Print setup is currently platform specific. We are using the print dialogs
supplied by the platforms.. except for GTK which Syd duplicated a generic Linux
dialog for PostScript. I will support the API's which we come up with (margins,
headers, etc, etc).
Assignee: dcone → don
Updated•24 years ago
|
Putting on [nsbeta2+][5/16] radar. This is a feature MUST complete work by
05/16 or we may pull this feature for PR2.
Whiteboard: [FEATURE] → [nsbeta2+][5/16][FEATURE]
Comment 6•24 years ago
|
||
I don't see why (as I wrote in bug 11767, which is also on don's list marked
milestone Future) there can't be a cross-platform, XPIDL-defined interface to
the platform-specific Print Setup code. Is that really don's job? Don, who is
gonna do this? Do you need help?
When I see SVG stuff going into the tree just before the feature freeze (and
don't get me wrong, I like SVG -- but let some external-to-netscape.com hackers
do it), while crucial, basic features are at risk, I start to get ornery. And
nosey! Maybe, in absolute priority order, the cc: list of this bug should be
helping with Print Setup and similar bugs first, then (if there's time) helping
with SVG?
/be
Clayton, this isn't an XPApps task. We don't do platform-specific dialogs like
this. I think dcone or a toolkit person needs to own this bug and bug #11767.
Assignee: don → clayton
Target Milestone: M17 → ---
Comment 10•24 years ago
|
||
On exception list for PR2, removing 5/16...giving [nsbeta2+]Exception Feature
status.
Whiteboard: [nsbeta2+][5/16][FEATURE] → [nsbeta2+]Exception Feature
Comment 11•24 years ago
|
||
*** Bug 11767 has been marked as a duplicate of this bug. ***
Comment 12•24 years ago
|
||
Ok, There seems to be alot of confusion about what this bug means. The source of
the confusion is there are two separate dialogs used to setup printing.
a cross-platform page setup dialog where the user specifies margins, whether or
not to print the background etc.
a printer driver specific dialog that is provided by the printer manufacturer.
This dialog is usually brought up using a button off the page setup dialog or it
is displayed when the page is told to print.
Given this:
The cross-platform page setup dialog should be done in XUL and owned by either
the XPFE or BROWSER teams.
An API specifying the page setup settings needs to be added to the
contentViewer, PresShell or other appropriate interface in layout. This should
be
owned by layout.
An abstract Interface should be created for bringing up the printer specific
device driver. This should should live in widget, and needs to implemented on
each platform.
So which of these parts does this bug cover? The description seems generic
enough to cover all parts, but there are potentially three different owners for
this problem. Thats why this bug keeps bouncing around.
I think dcone should own the problem of creating the API's for both layout and
widget and we should file a separate bug for the creation of the XUL page setup
dialog.
Does anyone disagree with this?
Assignee: av → dcone
Assignee | ||
Comment 13•24 years ago
|
||
That's an excellent analysis, and the bug, as filed, covers all parts. Feel free
to break them out into separate parts.
Comment 14•24 years ago
|
||
CC'ing Syd
Comment 15•24 years ago
|
||
Don Cone is currently working on the PrinterService + the API and the
implementation for bringing up the Native PageSetup Dialog on the Mac. He should
be able to checkin a first pass at the PrinterService and be able to bring up
the Native PageSetup Dialog tommorow (6/22). This will provide no increase in
functionality for the beta2 user. The PrinterService will hold the current print
settings but it will have no effect on printing.
Comment 16•24 years ago
|
||
Deadline for exception features has passed, and PDT feels that we can ship
Seamonkey without this feature. Maybe we can get to it for the next rev. Marking
nsbeta2-
Whiteboard: [nsbeta2+]Exception Feature → [nsbeta2-]Exception Feature
Comment 17•24 years ago
|
||
This bug has been marked future because we have determined that it is not
critical for netscape 6.0. If you feel this is an error, or if it blocks your
work in some way -- please attach your concern to the bug for reconsideration.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Comment 18•24 years ago
|
||
Page Setup not critical? I'll be damned!
Assignee | ||
Comment 19•24 years ago
|
||
I hereby attach my concern. Every Mac application that prints has Page Setup.
Mozilla prints. Therefore, Mozilla must have a Page Setup menu.
Comment 20•24 years ago
|
||
I have all the code ready to implement this.. when and if this changes.
I agree with Simon and Pierre..
Comment 21•24 years ago
|
||
Cool... Changed milestone from Future to M18.
Target Milestone: Future → M18
Comment 22•24 years ago
|
||
Only problem is the PDT team will not approve this.. I worked on it.. got it
almost ready.. they consider this a feature.. and said no!
If we can convice to finish this.. then I can, until then.. its future.
Target Milestone: M18 → Future
Comment 23•24 years ago
|
||
I see an nsbeta3 keyword. Why can't the milestone remain at the next one after
nsbeta2? Future is taken to mean (and used to mean) "not in netscape 6" or "not
in the next major release" of mozilla.org-based code.
Don, could you please attach your patches to get this almost ready? Then maybe
someone not bound by pdt rules could finish it. That's worked time and again;
attaching patches in progress to bugs is a Good Thing. Maybe we can get this in
soon, with waterson or brendan approval and your code-review approval, if some
non-netscape.com contributor picks up the ball.
Comment 24•24 years ago
|
||
CCd phil for re-evaluation since he's the one who wrote that "PDT feels that we
can ship Seamonkey without this feature".
This can't be a Future bug. I don't understand why PDT refused dcone's fix.
Comment 25•24 years ago
|
||
Marking in nsbeta3-
Whiteboard: [nsbeta2-]Exception Feature → [nsbeta2-][nsbeta3-]Exception Feature
Comment 26•24 years ago
|
||
Adding nsbeta2 keyword to bugs with nsbeta2 triage value in status field so the
queries don't get screwed up
Keywords: nsbeta2
Comment 27•24 years ago
|
||
Removing future/beta3- for reconsideration, per jar and michaell at the
"Mac sucks" meeting.
Whiteboard: [nsbeta2-][nsbeta3-]Exception Feature → Exception Feature
Target Milestone: Future → M18
Comment 28•24 years ago
|
||
FWIW.... during the mac meeting today it was asserted that this was completely
done, and a patch was in hand, and that Phil had insisted that the fix not be
checked in.
Reading the comments above from dcone (who would have authored the bulk of this
feature), the statement made was that this was "almost ready," and that he
stopped working on it because it was considered a feature. (He also said that it
"all code was ready to implement this" at an earlier point, but the last
position statement talked about getting permission to "finish it" as well).
As I read the comments, it was an incomplete feature, that would need to be
finished, and was instead latered.
Although this bug is currently listed as Mac System 8.5, I believe this is a XP
feature defficiency. I think the feature didn't make the train on any platform,
and now we're racing to make sure the train even runs at all on any tracks
(platforms).
Appology in advance to the folks that I misunderstood (either dcone above, or
the mac folks at the meeting today)... but I'd be happy to be corrected.
I'd also note that it is very uncommon to not have a page-setup on most any
platform... but I am curious to better understand why this issue is seemingly
pivotal on Mac (certainly that was the sentiment expressed above). Hopefully
the relative importance was caught in in the mac meeting today by Michaell as
folks prioritized critical development work needed to better the mac.
As one last comment, based on my memory of discussion of this bug... even after
dcone finishes the infrastructure for this bug (back end work), there is a bunch
of front end work (UI) to be done, as well as preference saving work to be tied
in, and of course qa tests to be added for this area. Am I mistaken about that
memory of "what it would take to land this feature?"
Thanks,
Jim
Comment 29•24 years ago
|
||
I think you have a good understanding of this bug. I have the bulk of the work
completed communicate information between the page setup, preferences to the
actual print job in an XP way. Most is even checked in.. I have to hook up the
factories to finish this. The calling of the page setup dialog (Platform
specific) and the filling in of the printer object would have to be done. Also
the printer code would have to use these setting from this object.
Comment 30•24 years ago
|
||
Let me summarize the current state of this bug:
Printer Service (Holds the current printer settings to be accessed from Layout,
Preferences and UI)
MOSTLY DONE
Hook up layout to use settings in Printer Service (i.e print background, Margins
etc.)
NOT STARTED
Create a dialog to let the user specify the settings
NOT STARTED
Bring up platform specific Page Setup dialog - (Mac is the only platform with a
native page setup dialog. On WIN32 and Linux the page setup dialog is created by
the application)
NOT STARTED
Save and Load printer settings from preferences
NOT STARTED
The Mac is unique in that some of the settings that are found in the printer
dialog (The dialog brought up just before printing) are located on the Mac's
page setup dialog instead. Most notably, page orientation. On WIN32 page
orientation (landscape/portrait) is on the printer dialog so it is settable in
the current build. On the Mac we are not able to set the page orientation
because we would need to bring up the native Mac pagesetup dialog.
As a partial solution we could implement a method on the PrintService to bring
up the pagesetup dialog on the Mac. This would allow the user to set the page
orientation. We would also need to create a PageSetup menu item which calls this
method.
Comment 31•24 years ago
|
||
Added [NEEDINFO] to status.
What is the minimal implementation for we can get away with? If we need a full
page setup I'll have to nsbeta3- this bug. If we can come up with a subset,
such as just bringing up the native pagesetup dialog on the Mac, we can probably
get that in.
CC'ing ekrock
Whiteboard: Exception Feature → [NEEDINFO]Exception Feature
Comment 32•24 years ago
|
||
This is an out feature, but you can do the subset, native page set up only on
the Mac. Please see what Mac folks vote. If all say yeah! then putting in
[nsbeta3+] for that.
Whiteboard: [NEEDINFO]Exception Feature → [nsbeta3+][nsbeta2-]Exception Feature
Comment 33•24 years ago
|
||
I *REALLY* don't see how netscape can ship without this feature and get away
with it. In the beta's, yes. As a supposeably "finished" product, no. The press
will have a field day.
It's starting to get to the point where slipping the schedule a month will do
LESS damage then releasing netscape 6 in a still very buggy and feature missing
state. It's better to be considered "late" (which you ALREADY ARE, by idiotic
people who can't wait 5 god damn minutes for ANYTHING) then to be considered
"late AND buggy".
Keywords: 4xp
Comment 34•24 years ago
|
||
Marking nsbeta3-.
Whiteboard: [nsbeta3+][nsbeta2-]Exception Feature → [nsbeta3-][nsbeta2-]Exception Feature
Comment 35•24 years ago
|
||
My $0.02.
<Rant>
How exactly are we expecting *any* Macintosh user to use a browser that they
can't print MapQuest (another of our brands, by the way) Maps from? 4.x had
quite a few bugs that could be worked around by going into Page Setup and
changing the Print Zoom to 75% instead of 100%. NS6 doesn't even have that, and
quite frankly I can't print a page that is wider than a normal page. Its about
2.3 pages wide (horizontally) and its just cutting off whatever is to the right
of the roght margin. No extra pages, nothing. The ideal thing is to put this
page in Landscape Mode, but-guess what!-I can't! No Page Setup to do it in!
Windows has the capacity to do this all in the print dialog, but on the Mac there
is no other option.
Off to print with IE.
</Rant>
Comment 36•24 years ago
|
||
The more I think about it, the more it bothers me that 4.x had crappy printing on
the mac, and that NS 6 has managed to do even worse. I'm upgrading the severity
to critical because I can't see any reason why anyone in their right mind would
bother to use our product while doing research (or map searching, or e-mail, or
whatever) only to find out they can't print a thing on it properly. *Properly*
being the key word here. Yes, I can get half a page. Great, but unless I'm
psychic, I can't properly fill in the blanks.
I'm sitting in my cube waiting for someone to smack me upside the head. Call me
and I'll accomodate appointments.
Severity: normal → critical
Comment 37•24 years ago
|
||
Is there any low-hanging fruit here? Could we bring up only Page Setup, only on
the Mac, using the native dialog, perhaps even disabling any settings that
aren't easily supported? Are there any printer companies (cough HP cough) that
might loan us an engineer to help with this? It is rather pitiful that we can
prefill your spouse's mother's maiden name in forms, but can't print them. cc
pinkerton, saari, danm, sdagley,scc
Comment 38•24 years ago
|
||
Peter: Don was close to being able to bringing up the Mac native page setup
dialog, but there's more work to be done and Don is overloaded with other bugs.
If someone wants to pickup where he left off, that would be great.
Don, correct me if I'm wrong but his is my take on the current state of this
feature:
Most of the infrastructure is in place to be able to bring up the Native
PageSetup dialog on the Mac. The print service is checked in and includes a
method to bring up the NativeDialog. The print service's interface has been
specified in IDL so it should be accessable to JavaScript.
What remains to be done:
1. Create a Mac specific print service which implements the call to bring up the
NativeDialog.
2. Use the settings provided by the Mac specific page setup dialog when
printing.
3. Register the printer service
4. Write the XUL/JavaScript to access the printservice and call the method to
bring up the Mac page setup dialog.
Comment 39•24 years ago
|
||
Adding shrir to the cc list
Assignee | ||
Comment 40•24 years ago
|
||
I really agree with the above few comments. Clearing status whiteboard for
reconsideration.
Whiteboard: [nsbeta3-][nsbeta2-]Exception Feature
Assignee | ||
Comment 41•24 years ago
|
||
Adding nsmac2 keyword, since printing is important for Mac, and IE 5 currently
beats us hands down here.
Keywords: nsmac2
Comment 42•24 years ago
|
||
Would love to fix this, but there just isn't time before beta3.
Added helpwanted keyword.
Keywords: helpwanted
Whiteboard: [nsbeta3-]
Assignee | ||
Comment 43•24 years ago
|
||
Are we really not going to fix this for rtm? Adding keyword, to get it on radar.
Keywords: rtm
Comment 44•24 years ago
|
||
Comment 45•24 years ago
|
||
The patch I posted implements the native Page Setup dialog for Mac. I only
implemented the nsPrintOptions component registration for the Mac and Windows.
The other platforms would have to be implemented, not a big task and not
required to get the Mac native page setup working. Also the PrintOptions
service needs to be registered.. and I registered this service in
nsAppRunner.cpp..not sure if this is the appropriate place. This patch did not
put them page setup menu item in apprunner..
Comment 46•24 years ago
|
||
This will need heavy review and super-duper approval, and probably should be
trunk-tested before rtm-plussing to attract PDT consideration for N6. There is
very little (if any) time left for that, but I think this is still worth the effort.
Comment 47•24 years ago
|
||
marking [rtm need info]
Still need to add a menu item + Javascript to call the print service method
which brings up the Native Mac Dialog. Need help from UI/XUL person.
Whiteboard: [nsbeta3-] → [nsbeta3-][rtm need info]
Comment 48•24 years ago
|
||
Not to throw another hurdle into your way on this, but if you guys are serious
about trying, then you'll need to talk to international. If you are adding a
menu item and a complete dialog that hasn't been localized....Even if the dialog
is native, the menu item will be a stickler.
Just a bit of advice.
Comment 49•24 years ago
|
||
cc'ing folks on the xpapps team
Comment 50•24 years ago
|
||
I can probably add this. We already have a [disabled] Page Setup item, so
this shouldn't be a problem wrt internationalization.
Comment 51•24 years ago
|
||
Marking rtm-. Getting off the rtm radar.
Whiteboard: [nsbeta3-][rtm need info] → [nsbeta3-][rtm-]
Interesting bug, so I'm cc:ing myself to this.
Comment 53•24 years ago
|
||
we should probably release note this since there is a menu item called Page
Setup and it's always disabled. I really wish there were some way to print at a
smaller percentage or change the orientation. These are commonly used, expected
behaviors that affect dogfood usage so I'm adding that keyword too in case it's
relevant beyond rtm.
Removing old keywords nsbeta2 and nsbeta3 and nsbeta3- from status whiteboard.
OS: Mac System 8.5 → All
Whiteboard: [nsbeta3-][rtm-] → [rtm-]
Comment 54•24 years ago
|
||
Adding to Composer section of Release Notes, and would appreciate help on the
writup:
Is this truly a problem on all platforms, as indicated in the Platform category,
or just the Mac, as the bug comments seem to indicate?
Any workaround info that we can provide?
Comment 55•24 years ago
|
||
This is just a Mac problem. The biggest problem with this bug will be that
Landscape will not be an option.. I will look for workarounds today and will
update this bug.
Hardware: All → Macintosh
Comment 56•24 years ago
|
||
Why is this a Mac-specific bug? Page setup is not available for me on Linux
either (the menu item is always disabled).
Don Cone--why is landscape special? What is the problem with it?
Is the above patch checked into the trunk?
Comment 57•24 years ago
|
||
*** Bug 60475 has been marked as a duplicate of this bug. ***
Comment 58•24 years ago
|
||
Page setup is also not available on Windows 2000 and Windows 98
(Trunk build 2000111604)
Comment 59•24 years ago
|
||
Removing myself from list of cc's.
Comment 60•24 years ago
|
||
Mac builds need this implemented because currently there is no option to match
the window width to the printed page. I hate to have web page print outs chopped
off at the edge and lots of nearly blank pages printed out afterwards. This is
THE reason I can not use Mozilla for my regular work.
Updated•24 years ago
|
Target Milestone: M18 → ---
Comment 61•24 years ago
|
||
I took a time today to read all the comments in this bug. I just can not
believe PDT is blocking this from getting fixed. If it wants itself to claim a
usable browser, Mozilla needs this implemented to print the window fit into a
page. Why is it unnecessary to implement a functionality that simply matches
NS4.5-4.7? I can not see any point there. If internationalization is a
potential problem, fine that can be addressed in relnotes, although I very much
doubt it matters at least in Mac, because the dialog called is in the System
extention and handled by OS.
Comment 62•24 years ago
|
||
Since we seem to have a prototype ready, nominating for beta1.
Comment 63•24 years ago
|
||
I am wondering if the default page size is set for US letter or not.
Here in Japan and a major part of the world, A4 letter is the default. Maybe
most of you are not experiencing the problems I see because of that.
That may explain the lack of enthusiasm here, which, if truly the case, is WRONG.
Comment 64•24 years ago
|
||
Comment 65•24 years ago
|
||
Comment 66•24 years ago
|
||
shouldn't you use an nsCOMPtr?
Comment 67•24 years ago
|
||
I think since its a Singleton.. created only once and registered as a service
for the life of the App.. it does not need to use a nsCOMPtr.
The registration keeps track of this object for the life of the application.
Comment 68•24 years ago
|
||
dcone: you've created a leak, because RegisterService adds its own ref to the
service-instance you pass in (as it has to, per the rules of XPCOM -- the caller
cannot "hand off" its own reference). That leaves the reference added by
CreateInstance for its out parameter stuck, which means a leak.
It's a new millennium, there really is no excuse not to use nsCOMPtrs. But you
still need to know the rules of XPCOM, or you can get burned by cycles and bad
ownership models.
/be
Comment 69•24 years ago
|
||
*** Bug 65952 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 70•24 years ago
|
||
Can we get a target milestone on this bug please? 0.8 would be good, 0.9 would be
acceptible.
Comment 71•24 years ago
|
||
Setting milestone for mozilla0.9.
For mozilla0.9. We will enable bringing up the native Mac PageSetup dialog.
Target Milestone: --- → mozilla0.9
Updated•24 years ago
|
Summary: Page setup (Print setup) is unimplemented → Mac Page Setup needs to be implemented [mac][print][print ui]
Updated•24 years ago
|
Keywords: mozilla0.8.1
Updated•24 years ago
|
Keywords: mozilla0.8
Comment 72•24 years ago
|
||
Note: We need this print menu for Mail 3-pane window too. With 4.7x I can
access print Landscape with the Page Setup menu item. I can't print Landscape on
Mac and Linux with 6.01 or 6.5 because Page Setup is missing (and I haven't
found another way to access it). I will put my name on the CC list, if the Mail
3-pane window File menu list is done by mailnews group, please let me know and
I'll write a new bug. I did not see that this was specific to mac.
Comment 73•24 years ago
|
||
Comment 74•24 years ago
|
||
May want to rename ShowNativeDialog to ShowNativePageSetupDialog. Since we may
also want to support ShowNativePrintDialog later.
r=kmcclusk@netscape.com
Comment 75•24 years ago
|
||
sr=attinasi
Comment 76•24 years ago
|
||
it doesn't look like this will work under carbon.
Comment 77•24 years ago
|
||
the native call is there for the Mac OS9.
I created a new bug 76378 for hooking this up.
Comment 78•23 years ago
|
||
Not sure how I can verify this .. Don, if this is just a code issue let me know..
Comment 79•23 years ago
|
||
Chris--I don't really think you can verify this bug until 42817 and 65871 are
fixed (since we can't easily know if all of the page setup functionality works
without the UI) :-/
Comment 80•23 years ago
|
||
Why was this considered fixed? It sure isn't on the Mac.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 81•23 years ago
|
||
This is fixed.. because the call is there. There are other bugs.. that mention
putting page setup in the file menu. This bug was about getting the Mac
Pagesetup working with and API. So my part on this issue for the Mac is
complete.
Comment 82•23 years ago
|
||
Marking fixed. Another bug was opened for using the Mac Print Setup code that
was implemented here.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 83•23 years ago
|
||
This is so not working. I see no way that the mPrintRecord stored in
nsPrintOptionsMac() ever get to the printing code.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Updated•23 years ago
|
Attachment #16871 -
Attachment is obsolete: true
Assignee | ||
Updated•23 years ago
|
Attachment #22275 -
Attachment is obsolete: true
Assignee | ||
Updated•23 years ago
|
Attachment #22276 -
Attachment is obsolete: true
Assignee | ||
Updated•23 years ago
|
Attachment #30639 -
Attachment is obsolete: true
Assignee | ||
Comment 84•23 years ago
|
||
Assignee | ||
Comment 85•23 years ago
|
||
nsPrintOptionsMac did simply not work, and must never have been tested. Bad
things:
PrStlDialog() was not called inside a PrOpen/PrClose block, so it rarely worked.
And when it did, the watch cursor showed up over it.
Also, there was no way the print record we got from PrStlDialog() could be fed
into the printing code.
This in-progress patch adds a 'GetNativeData' call to nsIPrintOptions, which the
mac printing code can use to get at the print record. It also does a bunch of
cleanup, so it larger than necessary.
Comment 86•23 years ago
|
||
Patch looks fine except there is a little more whitespace cleanup you could do
(for example the following line and the line that follows it):
sDefaultFont = new nsFont("Times", NS_FONT_STYLE_NORMAL,NS_FONT_VARIANT_NORMAL,
and also this line you added:
NS_IMETHOD GetNativeData(PRInt16 aDataType, void * *_retval);
StHandleOwner seems to have tabs in it
nsPrintOptionsMac::~nsPrintOptionsMac() also seems to have tabs in it (though you
aren't touching much there right now)
r=brade
Assignee | ||
Updated•23 years ago
|
Attachment #53039 -
Attachment is obsolete: true
Assignee | ||
Comment 87•23 years ago
|
||
Assignee | ||
Updated•23 years ago
|
Attachment #53151 -
Attachment is obsolete: true
Assignee | ||
Comment 89•23 years ago
|
||
Assignee | ||
Comment 90•23 years ago
|
||
The last patch adds Page Setup functionality for Mac OS classic and Mac OS X. It
stores page setup settings in the preferences (as a Base64-encoded string)
between runs, and will load the settings from prefs when nsIPrintOptions is
instantiated for the first time (i.e. a page setup in the last session will
affect printing in a subsequent session).
Because the code that shows the page setup dialog is separate from the printing
code, and not in a per-window or per-document data structure, we are not able to
use the Carbon session-based printing APIs. We have to use the more backwardly-
compatible non-session APIs instead, so I had to touch some of the Mac OS X
printing code.
Note that you'll need the XUL patch in bug 42817 to see page setup in the UI.
Reviews please.
Status: NEW → ASSIGNED
Assignee | ||
Comment 91•23 years ago
|
||
Note that you also have to add nsPrintOptionsX.cpp to the carbon targets of
gfx.mcp to have this work.
Comment 92•23 years ago
|
||
Yea! Thanks. I'm not too familiar with Carbon printing but the patch looks good.
I'll apply it and check it out further.
Assignee | ||
Comment 93•23 years ago
|
||
Note to self: this line:
+ ::PMDefaultPageFormat(mPageFormat);
in nsPrintOptionsX::ShowNativeDialog() needs to be removed.
Comment 94•23 years ago
|
||
Comment on attachment 53208 [details] [diff] [review]
Review-worthy gfx patch
ok, looks decent to me, pending a thorough mac r= :)
sr=
Attachment #53208 -
Flags: superreview+
Assignee | ||
Comment 95•23 years ago
|
||
sdagley gave an r=
Assignee | ||
Comment 96•23 years ago
|
||
These changes are in, now. No menu item yet, tho (see bug 42817).
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Comment 97•23 years ago
|
||
PDT+, let's get this into the 094 branch.
cc'ing robinf and msanz.
Updated•23 years ago
|
Whiteboard: [PDT+]
Assignee | ||
Comment 98•23 years ago
|
||
This has been checked in on the 0.9.4 branch
Comment 99•23 years ago
|
||
cc yxia and danielmc and rclose - not sure if there is new UI for this or not.
Comment 100•23 years ago
|
||
Verifying that page setup command is functional in the trunk OS 9 build
(2001-10-16-08).
*Used Page setup dialog to scale print out at 50, 75, 100, 150 % out of composer
and navigator.
*Specified Landscape and portrait modes and printed page.
*Switched between printers in Page setup dialog and printed page.
Keywords: vbranch
Comment 101•23 years ago
|
||
Chris, when Mac branch builds are out, try these things out per Simon's
email:
On Mac & Mac OS X:
* Verify that Page Setup appears in every File menu that has Print.
* Verify that Page Setup appears on Composer's Print toolbar button
dropdown (it was there before), but not on any other Print toolbar
dropdowns (this is just the way things were, not a deliberate design
choice).
* Verify that Page Setup works in every location in which it appears
(including when no windows are open). It should show the Page Setup
dialog for the currently selected printer, and should remember
settings from the last time you used it, even if in a previous
session (settings are stored in prefs, hence are per-profile). Printing
should use the last-specified Page setup options.
Switching between printers should not cause problems; test the case
of doing Page Setup in printer A, switching to printer B, and then
doing a Print without a preceding Page setup. Test when no printer
is selected (remove all printers).
* Verify that printing on Mac OS X still works as it did before.
On Windows & Unix:
* Verify that File menus look as they did before this change, that Print
still works, and that Page Setup on Composer's toolbar button dropdown
does nothing bad.
Comment 102•23 years ago
|
||
Verified on the Mac OS X build (2001-10-16-04).
* Page setup command appears in all application modules:
Nav, IM, Mail, Composer, Address Book
* Print button popup in Composer displays Page setup option and is functional.
* Page setup dialog shows previous settings
* Printed from Composer, Nav, Mail, and IM.
Need to still test on Mac OS 9 branch...
Comment 103•23 years ago
|
||
Under Windows branch (2001-10-16-05) , Print function works from File menu and
Composer's Print button.
Sujay,
My linux machine has been setup for my network printer so I will need you to
check this.
Comment 104•23 years ago
|
||
Sorry, my linux machine hasn't been setup to print... Need for you to check..
Comment 105•23 years ago
|
||
Chris, I will take care of the linux issue.
Mac branch builds are out...you can go ahead and verify this
on branch using Simon's verification instructions.
thanks.
Comment 106•23 years ago
|
||
Verified on the Mac OS 9 branch build (2001-10-17-03)
* Page setup appears and works in Nav, IM, ,Mail, Composer , and Address book.
* Previous settings appears in page setup dialog.
* Printed from Nav, IM, Mail and Composer after specifing various scaling and
page settings.
* Switching to between different printers is successful and print jobs are sent
poroperly.
Comment 107•23 years ago
|
||
Marking verified on both Mac OS 9 and OS X 10.1
Status: RESOLVED → VERIFIED
Comment 108•23 years ago
|
||
verified on Linux 10/17 branch build the following per Petersens/Simons request:
* File menu works and appears they way it did before thix fix
* Print functionality works
* Page Setup on Composer's toolbar button drop-down does nothing bad
Comment 109•23 years ago
|
||
Is this expected?
I tried to use scaling and orientation on the Page Setup dlg and then print.
Looks great.
However, when I view the preferences js file (which I know most users won't do),
for the parameter for user_pref("print.macosc.pagesetup"), I get a huge section
of characters which seem encrypted to me.
Comment 110•23 years ago
|
||
It's not encrypted. It's just a native print record which is base64 encoded as
text so it can be put in a prefs file. Same thing as with file aliases in Mac
prefs files. I wouldn't worry about it.
Assignee | ||
Comment 111•23 years ago
|
||
What Conrad said. That's expected.
You need to log in
before you can comment on or make changes to this bug.
Description
•