Created attachment 163179 [details] DOCX sample The PRINTDATE field type (17.16.5.47 of ISO/IEC 29500-1) seems not to be supported at all. When opening a DOCX file with such a field the following things should happen in my opinion: - When updating all fields in the document the current value of the core properties (docProps/core.xml,cp:lastPrinted) of the document should be placed in the field result. - When printing the document the lastPrinted value of the document should be updated to the local date/time as is done with the DATE/TIME-fields. This value should also be placed in the field-results of all PRINTDATE-fields (if not locked) with the correct format. - When exporting the docuemnt as PDF (which has pretty much replaced printing and is thus even more important than the original printing use case) there should be an option to update the PRINTDATE field which should be set by default. Instead the field remains completely untouched all the way. All these things are done by MS Word. A coded work around would be to treat the PRINTDATE field as it was a DATE field. This would suffice for most use cases (at lest for my use cases). There could also be a compatibility flag for opting into that behavior. I do not know if there is such a concept in ODT as well and if the concepts translate to ODT and the meta-format of writer in any way. I have attached a DOCX file with a PRINTDATE field that is set to somewhen in 2011 in the document but to 2019 in the core properties to verify the behavior.
I see it is a Form Control field in your test document. Should the feature you have mentioned be: Insert > Field > More Field > DocInformation > Type: Last printed, Select: Date ?
Hi Kevin, this looks pretty much like it. The way I see it, the PRINTDATE-Field of DOCX should behave like the field you described. The funny thing is, that when inserting the field via Insert > Field > More Field > DocInformation > Type: Last printed, Select: Date in writer and save the document as DOCX then it is exported as PRINTDATE field as I would expect. It seems like only the import of DOCX does not work correctly. Kind regards, Roman
I see FILEOPEN the field in your attached docx works fine in version 7.0.3 release. Would you please check? Mark as WORKSFORME per your comments above.
Reopening, this docx-imported field does not work in: Version: 7.2.0.0.alpha0+ (x64) Build ID: 4e63ec27b69fa01ff610c894c9fbf05c377a6179 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win Locale: en-US (hu_HU); UI: en-US Calc: CL
Created attachment 167760 [details] The example file with a manually inserted Last printed field Before printing a newly inserted field displays the same 2019-11-25 date as File - Properties shows. Tools - Update - Fields does not update the original fields value to this, but Word 2013 the Update fields command in the right click menu does.
Created attachment 167761 [details] The example file with a manually inserted Last printed field after printing the document Printing the document updates the manually inserted Last printed field to todays date and also File - Properties. The docx-imported field does not change, but it should.
Setting status to NEW per confirmation above.
I have notes about fixing the import of the "last printed" date field in bug 132475. Since this report has multiple issues reported in it, let's focus this one on the enhancement request to tie a PDF export to the DocInfo.PrintDateTime and DocInfo.PrintAuthor.