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.
OP - thanks for the clear description. At first I implemented by updating the time AFTER a successful export, but revised it to be before the export based on your clear use case requirement. NICE: by default, when printing the document is NOT marked as modified. That was my biggest worry about implementing this. With that nuisance avoided, the pool of users who will object to having the print statistics "erased" by pdf exports will be very small indeed. The fact that MS Word does this as well should erase all concern (on my part). Proposed fix at https://gerrit.libreoffice.org/c/core/+/151682 The example PDF from comment 0 works nicely AFAICS. The fixes for importing that were in LO 7.4.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/99a88c9e55872214ce01d89447d18708e47e956b tdf#134901: update print statistics on PDF export It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Working well in Version: 7.6.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: ca3bfa9bded6103d4d172ace486b697beeb191be CPU threads: 16; OS: Linux 5.19; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded The message that the document was changed only appears if in Tools - Options - General - "Printing sets document modified status" is checked.