Closed
Bug 113727
Opened 24 years ago
Closed 23 years ago
Page Setup
Categories
(Core :: Printing: Output, defect, P1)
Core
Printing: Output
Tracking
()
VERIFIED
FIXED
mozilla0.9.9
People
(Reporter: jaimejr, Assigned: law)
References
()
Details
(Keywords: l12y, meta)
Attachments
(5 files, 4 obsolete files)
318 bytes,
image/gif
|
Details | |
311 bytes,
image/gif
|
Details | |
22.07 KB,
image/jpeg
|
Details | |
21.84 KB,
image/jpeg
|
Details | |
51.22 KB,
patch
|
samir_bugzilla
:
review+
bugzilla
:
superreview+
asa
:
approval+
|
Details | Diff | Splinter Review |
This is a tracking bug for work needed to implement the Page Setup Feature. To
do this, we must first define the correct behavior (functional
spec), describe how it works (design spec), and then create bugs for each of the
sub tasks.
From MachV Nav Plan:
* Page Setup Option in File Menu.
* Functionality that includes:
* Customizable Header/Footer
* Page Numbering
* Ability to specify Margin settings (tbd - should contents reflow
when margins are changed or not?)
* Page orientation (portrait/landscape)
* Frame page choices:
* Print as laid out on screen
* print only selected frame
* print all frames individually
Reporter | ||
Comment 1•24 years ago
|
||
Nominating for nsbeta1 as part of the MachV PRD requirements.
Keywords: nsbeta1
Summary: Page Setup → Page Setup
Comment 3•24 years ago
|
||
There also should be options as:
* Print page background color and background picture
* Print table background color and background picture
* Print all text in black
Without this options pages with grey colored text on black background are
unreadable when printed.
Comment 4•24 years ago
|
||
There are now mechanisms for turning on and off background color and image, can
we get these options in this dialog and set the print options accordingly.
Right now in 2002010303 it says:
Header Footer
------ ------
Left: &T Left:
Center: Center:
Right: &U Right:
couldn't it instead be disposed like this:
Header----------------------
Left: ~~~~v Center: ~~~~v Right: ~~~~v
Footer----------------------
Left: ~~~~v Center: ~~~~v Right: ~~~~v
Note: the ~~~~v is supposed to symbolize a dropdown menu, so that one wouldn't
have to enter codes like &U
Comment 6•24 years ago
|
||
->law, p1/0.9.9. What remains to be done on this?
Assignee: pchen → law
Priority: -- → P1
Target Milestone: --- → mozilla0.9.9
The measure unit is inches although my system uses metric. Is this hardcoded?
Shouldn't it adapt to the system?
![]() |
||
Comment 8•24 years ago
|
||
that would be bug 118954, not this one.
What needs to be done:
a. Come up with some means of accepting page header/footer instructions that
don't require the user to know/enter the &PT/&D codes. I don't think there is
another bug for that. There is a proposal in the plan document linked to from
the bug's URL field.
b. Permit input of margins in units other than just inches (inches, mm, cm?).
That's bug 118954, as Boris said.
c. Any other bugs. One that I'm aware of is the fact that the current
implementation treats the page setup info as window-specific settings (that is,
you open page setup and it affects only printouts originating from the same
window). There are other quirks relating to that, probably (e.g., despite
treating the page setup settings as per-window attributes, you can't open up two
page setup dialogs for two windows simultaneously; so when you try the second,
it just brings the previous one to the top, and you change those settings
changing them for a different window than the one from which your request
originated).
![]() |
||
Comment 10•24 years ago
|
||
"a." is bug 66713, no?
Assignee | ||
Comment 11•24 years ago
|
||
Could be, but I decided to close that one and start fresh with this one.
Updated•24 years ago
|
Assignee | ||
Comment 12•23 years ago
|
||
There is one remaining obstacle (i.e., bug): The input <textbox>s do not accept
input for some reason, until you do something that sets them free (e.g., select
Custom... in one of the menulists).
I'll figure that out tomorrow (oops, I mean later today).
Assignee | ||
Comment 13•23 years ago
|
||
Samir, please review.
Comment 14•23 years ago
|
||
XUL comments:
(*) <spring/> is deprecated: use <spacer/> instead
(*) Inline a comment in the XUL about the nifty margin ``image'' and that's
manipulated at runtime
(*) Inline a comment about the ``balancing'' hidden labels
(*) <vbox id="basic"/> and <vbox id="advanced"/> should be
<tabpanel/>s (use orient="vertical" if they default to horizontal)
(*) <vbox index="basic"/> should read id="basic" I believe
(*) Use size="__" instead of style="width: __em;" on <textbox/>es
(*) Remove disabled="true" from the <checkbox id="headersAndFooters"/>
(I don't see us unchecking it anywhere or handling it: are we planning
to implement it later? Maybe we should just remove the checkbox altogether
for now or comment it out and file a bug on whoever needs to implement the
underlying support: backend I suppose).
JS comments:
(*) We appear to be relying on the backend to give us the unit system
(metric or non): is this supported by the backend in terms of grabbing
the system locale and determinig the unit system? If not, is there a
bug for the backend to support else please file one.
The focus problem seems pretty bad. It makes the dialog unusable unless you
know the trick to focus another app and refocus the browser. I found that if
you remove the orientation radiogroup the focus problem goes away. Let's switch
over to buttons that toggle like the print preview UI (and iron out the focus
problem later if we still want to go back to radio buttons).
Comment 15•23 years ago
|
||
Samir Gehani wrote:
> Let's switch over to buttons that toggle like the print preview UI (and iron
> out the focus problem later if we still want to go back to radio buttons).
Currently I am working on a way to get the information about "printer features"
(e.g. supported paper sizes, color spaces, orientations, plex, resolutions etc.)
via an API from the printer (e.g. the "page setup" and "print job options" gets
populated with values supported by the printer instead of using a hardcoded,
limited list which may contain entries which are not supported by the printer
(or not wanted by the admin - for example DIN-A4 on a DIN-A0 poster printer
comes in mind...)). Switching to radio buttons may be bad in that case. What
happens if the printer supports more than the "common" portrait/landscape
choices (for example, many HP printers support "portrait", "landscape",
"reverse-portrait", "reverse-landscape" and "auto"). I assume this would
screw-up the layout, right ?
Comment 16•23 years ago
|
||
Roland,
Yes, it would. But then when you expose this into the Page Setup dialog you
could change over from normal buttons to radiobuttons at that time. The point
is that the focus problem makes the dialog so unusable that we need an
intermediate solution if we are to check these changes in, wouldn't you say?
Comment 17•23 years ago
|
||
Samir Gehani wrote:
> Yes, it would. But then when you expose this into the Page Setup dialog you
> could change over from normal buttons to radiobuttons at that time.
radiobuttons aren't good either because I cannot gurantee how many entries are
returned by the printer subsystem for a requested printer attribute (page size
is AFAIK the worst example here, in theory a printer could return more than 90
entries (per rods windows has ~120 page sizes depending on the OS - but in real
life a printer would (hopefully) only support a small subset of these sizes)).
And this number may be multiplied with the number of trays available in the
printer... Same applies to other attributes, too).
Why can't we stick with the current menulist widget ?
> The point
> is that the focus problem makes the dialog so unusable that we need an
> intermediate solution if we are to check these changes in, wouldn't you say?
Changing this as a intermediate solution is OK for me as long we can return back
to the old menulist some day... :)
Comment 18•23 years ago
|
||
Please do not eliminate the input text fields (and revert to pull-down lists as
suggested in comment #5). With the input text fields, customers of Mozilla can
put text in that say things like "CoName Company Proprietary" (or some other
terms I'd rather not get into here). The way it is now is FABULOUS!!! Just
need to know what the codes are.
Assignee | ||
Comment 19•23 years ago
|
||
Updated patch with Samir's comments (plus merges with recent changes from Rod).
We still need to resolve the horked input focus problem with the textboxes.
I've asked Joe Hewitt to sr=; maybe he can figure out what's up.
Attachment #70276 -
Attachment is obsolete: true
Comment 20•23 years ago
|
||
Comment on attachment 70415 [details] [diff] [review]
patch, v1.1
>+ <radio id="portrait" src="chrome://communicator/skin/icons/pg-portrait.gif" label="&portrait;"/>
>+ <radio id="landscape" src="chrome://communicator/skin/icons/pg-landscape.gif" label="&landscape;"/>
It makes it less flexible for skin developers if we hardcode chrome URLs to
images. So move these images to CSS and r=sgehani.
Attachment #70415 -
Flags: review+
Assignee | ||
Comment 21•23 years ago
|
||
So how do I do that, Samir? I can understand setting background-image style
attribute via CSS, but this is a src= attribute on a <radio> element. It seems
I'd need to style the implementation stuff under <radio>, which doesn't sound
like a good idea, either.
But I'm kind of new at this, so clues welcome.
Comment 22•23 years ago
|
||
If I'm not mistaken in xul you can use list-style-image: url("image location");
Comment 23•23 years ago
|
||
What basic said. Also, see the print preview toolbar changes I made. We now
have a class for pg-portrait.gif and pg-landscape.gif in
chrome://communicator/content/communicator.css. So if your radio buttons were:
<radio src="chrome://communicator/skin/icons/pg-portait.gif" .../> <radio
src="chrome://communicator/skin/icons/pg-landscape.gif" .../>
they now become:
<radio class="portait-page" .../>
<radio class="landscape-page" .../>
Of course, you have to include chrome://communicator/content/communicator.css in
your xul.
I've found the following CSS tutorial a useful reference:
<http://www.westciv.com/style_master/academy/css_tutorial/properties/index.html>
Assignee | ||
Comment 24•23 years ago
|
||
Thanks, guys. I'll try list-style-image. Of course, the connection between
that style attribute and the display for <radio> buttons is pretty obtuse, no?
I just hope the radio button doesn't use that attribute to draw the little
button thingy instead.
BTW, this fix is blocked due to the tab-panel-textbox-focus problem. I'm going
to try some workarounds while others try to fix that problem. This will land
as soon as one or the other is ready.
Comment 25•23 years ago
|
||
law:
Can't we use the menulist widget for the "orientation" stuff, please ?
Assignee | ||
Comment 26•23 years ago
|
||
If sufficient consensus says to use menulist, sure. I'm just implementing the
spec (at
http://www.mozilla.org/projects/ui/communicator/framework/pagesetup/). I
prefer the radio buttons, myself.
If and when there are more than two options available, then changing the .xul
to use a <menulist> is a small part of the work that is necessary (compared to
the underlying JS code).
Assignee | ||
Comment 27•23 years ago
|
||
Updated patch with portrait/landscape images properly styled. This patch also
modifies some of the print preview toolbar style stuff to match.
Attachment #70415 -
Attachment is obsolete: true
Comment 28•23 years ago
|
||
Comment on attachment 71000 [details] [diff] [review]
patch, v2.0
Cool. You forgot to change the printPreviewBindings.xml portrait and landscape
classes to page-*-small from page-*. Change that and r=sgehani.
Attachment #71000 -
Flags: review+
Comment 29•23 years ago
|
||
Errr, I meant from page-{potrait,landscape} to toolbar-page-{portrait,landscape}.
Assignee | ||
Comment 30•23 years ago
|
||
Oops. I missed that since I don't actually have "big" images yet, so using the
"big" ones in the toolbar worked fine for me.
I'll update the patch Monday. How about you whip up some 32x32 versions of
those snazzy .gifs?
Comment 31•23 years ago
|
||
Comment 32•23 years ago
|
||
Assignee | ||
Comment 33•23 years ago
|
||
Updated patch with fix to printPreviewBindings.xml and tweak to
printPageSetup.js to ensure dialog is sized tall enough for the portrait mode
margin "page." I also added tabindex= attributes to fix the tabbing. That
still doesn't quite work correctly due to residual bugs elsewhere.
Attachment #71000 -
Attachment is obsolete: true
Assignee | ||
Comment 34•23 years ago
|
||
See bug 127915 for why the tabbing order doesn't work properly on the second
panel.
Comment 35•23 years ago
|
||
This looks good in general.
+function setFocus( node )
+{
+ node.setSelectionRange( 0, -1 );
+}
Not sure I understand the body of this function...? Okay, now that I look at
the xul, the point of it seems to be not to set focus (as the name would imply),
but to reset the selection, or something? Can you explain this?
+ <!-- Localizable strings manipulatd at run-time. -->
+ <data>
+ <string id="marginUnits.inches">&marginUnits.inches;</string>
+ <string id="marginUnits.metric">&marginUnits.metric;</string>
+ <string id="customPrompt.title">&customPrompt.title;</string>
+ <string id="customPrompt.prompt">&customPrompt.prompt;</string>
+ </data>
(Typo in that comment.)
Both <data> and <string> are, to an extent, figments of the xul author's
imagination, but <data> has become a bit more standard and it's set to
display:none in xul.css. So I think each of those <string>'s should be a <data>.
+ <tabpanel id="basic" orient="vertical">
+ <tabpanel id="advanced" orient="vertical">
The default orientation for tabpanel is vertical; there's no need to specify.
Also, do these need ids? (I assume so, but I couldn't see why in the patch.)
+<!-- This invisible label (with same content as the visible one!) is used
+ to ensure that the <textbox> is centered above the page. The same
+ technique is deployed for the bottom/left/right input fields, below. -->
+ <label value="&marginTop.label;" style="visibility: hidden;"/>
It's hard to visualize the need for this looking at all this ascii. Can you
post a screenshot of this dialog in modern and classic?
Also, what's special about this dialog that we need to specify the tabindex?
(Again, a screenshot would probably make it obvious.)
Comment 36•23 years ago
|
||
+ <!-- Localizable strings manipulatd at run-time. -->
+ <data>
+ <string id="marginUnits.inches">&marginUnits.inches;</string>
+ <string id="marginUnits.metric">&marginUnits.metric;</string>
+ <string id="customPrompt.title">&customPrompt.title;</string>
+ <string id="customPrompt.prompt">&customPrompt.prompt;</string>
+ </data>
I'm no reviewer but shouldn't these be in a <stringbundle> ?
Assignee | ||
Comment 37•23 years ago
|
||
Here's a pic of the dialog in question.
Note above the "page" that there is "Top: <textbox>". Without the extra
invisible "Top:" to the right of the text box, then the <textbox> would not be
centered above the "page."
The tabbing must be specified so that the tab order goes across the 3 header
<menulist>s. The natural tab order is to proceed through the leftmost <vbox>,
then the center <vbox>, then the rightmost <vbox>. We have to use <vbox>s here
so that the "Left:", "Center:", and "Right:" labels are centered.
Assignee | ||
Comment 38•23 years ago
|
||
Here's the dialog with classic theme, with the orient="vertical" attributes
removed from the <tabpanel>s.
Needless to say, I put those back in. I dunno about the default orientation
but I had to resort to this to make it work.
Assignee | ||
Comment 39•23 years ago
|
||
Revised, with changes suggested by Blake.
I changed setFocus() to onFocus(). This intent is for the entire field
contents to be selected when the <textbox>s get focus (e.g., the user tabs from
one to the next). That simplifies typing in new values. I just chose a goofy
name for the function.
Removed the id= attributes from the <tabpanel>s. Spelt "manipulated" right.
And changed the <string>s to <data>s.
Attachment #71546 -
Attachment is obsolete: true
Comment 40•23 years ago
|
||
Comment on attachment 71635 [details] [diff] [review]
patch, v2.2
Sorry, you're right -- I was thinking tabbox, whose default orientation is
vertical.
You could remove onFocus() altogether and just have onfocus="this.select();".
sr=blake
Attachment #71635 -
Flags: superreview+
Assignee | ||
Comment 41•23 years ago
|
||
I like the simple onfocus="this.select();" so I've made that change. I'm not
going to re-attach the patch, though. Thanks.
Comment 42•23 years ago
|
||
Comment on attachment 71635 [details] [diff] [review]
patch, v2.2
Ship it. r=sgehani
Attachment #71635 -
Flags: review+
Comment 43•23 years ago
|
||
Comment on attachment 71635 [details] [diff] [review]
patch, v2.2
a=asa (on behalf of drivers) for checkin to 0.9.9
Attachment #71635 -
Flags: approval+
Assignee | ||
Comment 44•23 years ago
|
||
new dialog checked in
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 46•23 years ago
|
||
Okay, so when are these changes going to come to the Mac OS? Are these
available on platforms other than Windows? I don't think it's "fixed" until
it's fixed XP. I had a heck of a time finding the lines to add to prefs.js to
remove headers.
You need to log in
before you can comment on or make changes to this bug.
Description
•