Open Bug 231068 Opened 21 years ago Updated 2 years ago

new Page Header or Footer Option -- just Date (no Time)

Categories

(Core :: Printing: Output, enhancement)

enhancement

Tracking

()

People

(Reporter: kimj90, Unassigned)

References

Details

(Whiteboard: [print2020][old-ui+])

Attachments

(1 file, 2 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007

Page Header/Footer margin print option has "Date/Time"
There should be an option for "Date" only.

Sometimes I want only the Date on the page header, NOT the time.
it is no one else's concern when I work outside regular business hours.


Reproducible: Always

Steps to Reproduce:
1.
2.
3.
This is a nice RFE. I am always concerned of what other people might think when
they see the time I print my pages. :-)
Blocks: dateandtime
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee: core.printing → cnst.bmo
Thank you for agreeing it is a nice enhancement.

It should also be easy to implement, an option to just suppress the time field.

Any progress?  What happens next?
(In reply to comment #2)
> Any progress?  What happens next?

My finals are over now -- I have started working on it today. We need to change
a lot of files for this enhancement to happen (not as easy as it sounds). I'll
try to post some patch soon. 
Finally, I have found some time to do the patch. :-) Sorry for the wait. 

This patch introduces a new option into the "File" -- "Page Info" -- "Margins
and Header/Footer" dialogue. The option allows to print only date. I renamed
the code of the old option (Date/Time) into &DT, and the code of the new option
(Date) is &D. 

By default, mozilla will print Date/Time, just as it did before. 

If the user customised Header/Footer before this patch, and if in the
customisation he changed where Date/Time is printed, then after the patch the
user may have Date, not Date/Time printed on his pages. This has a simple
workaround of changing the settings back to Date/Time if there is a need. 

The patch was tested in App Suite on FreeBSD. 

Does anyone know if I should touch files in mozilla/embedding/ directory?
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.8alpha2
Attachment #150680 - Attachment description: the patch for App Suite and Browser → the patch for App Suite and the toolkit as of 2004-06-13
AssignWithConversion got changed to AssignLiteral. Updating the patch.
Attachment #150680 - Attachment is obsolete: true
Attachment #153471 - Flags: review?(cbiesinger)
Comment on attachment 153471 [details] [diff] [review]
the patch for App Suite and the toolkit as of 2004-07-16

I don't know this code. Also, I can't do toolkit/ or browser/ frontend reviews.

try a layout reviewer for the backend part, neil@p for the xpfe part, mconnor
for the toolkit/browser part

however, I'm not sure that giving &D a new meaning is a good idea... it breaks
backwards compat when people had used it to get date&time
Attachment #153471 - Flags: review?(cbiesinger) → review?
Attachment #153471 - Flags: review? → review?(neil.parkwaycc.co.uk)
minor update to correct line numbers against the trunk, no !/-/+ lines changed
Attachment #153471 - Attachment is obsolete: true
Adam, could you clarify if I should touch files in mozilla/embedding/ directory?
Comment on attachment 153471 [details] [diff] [review]
the patch for App Suite and the toolkit as of 2004-07-16

clearing review request on obsolete patch, attach new patch and request review
again if you want (or on the latest patch, don't know if it still applys to
code)
Attachment #153471 - Flags: review?(neil.parkwaycc.co.uk)
Constantine, you have been working on the patch some years ago. Have you stopped your contribution or could you imagine to update the patch?
Target Milestone: mozilla1.8alpha2 → ---
(In reply to comment #10)
> Constantine, you have been working on the patch some years ago. Have you
> stopped your contribution or could you imagine to update the patch?

Sorry, I don't have time to work on this anymore, I'd imagine the patch would require a significant update before it is going to cover the whole tree again.
Thanks for your quick response. So lets un-assign this bug for now. Perhaps someone else has interest to fix this bug.
Assignee: cnst+bmo → nobody
Status: ASSIGNED → NEW
QA Contact: printing
Whiteboard: [print2020_v88][old-ui+]
Whiteboard: [print2020_v88][old-ui+] → [print2020][old-ui+]
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: