Closed Bug 113727 Opened 24 years ago Closed 23 years ago

Page Setup

Categories

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

defect

Tracking

()

VERIFIED FIXED
mozilla0.9.9

People

(Reporter: jaimejr, Assigned: law)

References

()

Details

(Keywords: l12y, meta)

Attachments

(5 files, 4 obsolete files)

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
Nominating for nsbeta1 as part of the MachV PRD requirements.
Keywords: nsbeta1
Summary: Page Setup → Page Setup
Keywords: meta
Blocks: 113701
This should be Paul's.
Assignee: law → pchen
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.
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
->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?
Keywords: l12y
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).
"a." is bug 66713, no?
Could be, but I decided to close that one and start fresh with this one.
Blocks: 118954
Keywords: nsbeta1nsbeta1+
Depends on: 123151
Blocks: 125824
Attached patch New .xul/.js/.dtd (obsolete) — Splinter Review
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).
Samir, please review.
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).
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 ?
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?
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... :)
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.
Attached patch patch, v1.1 (obsolete) — Splinter Review
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 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+
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.
If I'm not mistaken in xul you can use list-style-image: url("image location");
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>
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.
Depends on: 126850
law: Can't we use the menulist widget for the "orientation" stuff, please ?
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).
Attached patch patch, v2.0 (obsolete) — Splinter Review
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 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+
Errr, I meant from page-{potrait,landscape} to toolbar-page-{portrait,landscape}.
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?
Attached patch patch, v2.1 (obsolete) — Splinter Review
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
See bug 127915 for why the tabbing order doesn't work properly on the second panel.
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.)
+ <!-- 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> ?
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.
Attached image Classic theme
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.
Attached patch patch, v2.2Splinter Review
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 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+
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 on attachment 71635 [details] [diff] [review] patch, v2.2 Ship it. r=sgehani
Attachment #71635 - Flags: review+
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+
new dialog checked in
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
verified.
Status: RESOLVED → VERIFIED
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.

Attachment

General

Creator:
Created:
Updated:
Size: