Created attachment 142473 [details] Printing and PDF OS: Fedora Build ID: 6.0.4.2-2.fc28 CPU threads: 2; OS: Linux 4.16; UI render: default; VCL: gtk3; Locale: en-GB (en_GB.UTF-8); Calc: group Enhancements request: As noticeable in the context of creation of PDF documents Libreoffice (Canonical_Libreoffice_Writer_ 6.0.4.2.png) does not provide yet any mean for appropriate information regarding sections such as Title, Subject, Author, Keywords. It also lacks documentation regarding possible means involved in the optimization of such documents as Evince reveals it at section Optimized (Evince_3.28.2.png). While password is set for opening PDF document and consequently document is encrypted, in Libreoffice neither the protocol involved in encryption operation –e.g. AES– nor its key size –e.g. 256 bits– are mentioned or even documented. It appears that Evince is not aware of any kind of encryption as the Security field shows it (Evince_3.28.2.png). Therefore it seems that providing those features is a requirement in order to allow users to operate properly while creating new PDF documents.
PDF export uses properties filled in File > Properties. If you define the title, the subject and the keywords, then export as PDF: 1/ open the PDF in Evince, 2/ File > Properties => Evince shows the properties you filled in LibreOffice. So closing as WorksForMe. Please feel free to reopen if you disagree. Best regards. JBF
Created attachment 142498 [details] Printing and PDF - 2 PDF export appears to use at best some of the properties filled in Properties. Presently with the defaults set in section illustrated in Libreoffice_6.0.4.2_Properties_General.png, it currently uses only the ones illustrated in Libreoffice_6.0.4.2_Properties_Description, while the ones set as illustrated in Libreoffice_6.0.4.2_Properties_Custom-properties.png, and Libreoffice_6.0.4.2_Options.png, are ignored as illustrated in Evince_3.28.2.png.
–Comment 2–
So, let's try to avoid guessing: what is your concrete proposal? That it should pull Author information from User data First/last name/initials field?
Whose for did you believe Comment 4 to be? It could not be for any reporter for sure. I would just suggest you not guessing too much since there is no need for this here at Canonical and to stick to the very report description as I would have done as a developer and even as it was the case for Comment 1, despite of course answer to part of it was deliberately omitted. Proposal is for enhancement; regarding 'Author information from User data First/last name/initials field''it turned out that there is no less than two decent issues since Properties --> General, Reset Properties had to be invoked in order to get the application work as intended, and in Properties --> Custom-properties, properties added were just non-existent in PDF-information.
Version: 6.1.3.2 (x64) Build ID: 86daf60bf00efa86ad547e59e09d6bb77c699acb CPU threads: 4; OS: Windows 10.0; UI render: GL; Locale: da-DK (da_DK); Calc: CL 1. Tools/Options/User Data - fill in First / last name 2. Open Document (text is optional) and export as PDF. 3. Open exported pdf in (Microsoft) Adobe Reader, then Files / Properties Observed behavior: Author field in Document Properties is empty. Expected behavior: The First /Last name from User Data in Libreoffice should be in the Author Field that Adobe Reader shows.
*** Bug 76034 has been marked as a duplicate of this bug. ***
*** Bug 33307 has been marked as a duplicate of this bug. ***
OP (see comment 5) wants User Name (Alt-F12 - User Data - First / Last Name) to be automatically filled in as Author in exported PDF file properties. If "Apply User Data" is checked in File - Properties, then this happens in L0 6.3.6.2 ==> Closing as WORKSFORME
WFM is when there was a bug but not anymore - indicating we might find a fix via reverse bibisect. If something is not a bug upon explanation, that's NAB, indicating that check should be done if documentation is fine. https://bugs.documentfoundation.org/page.cgi?id=fields.html#bug_status As for Documentation, Comment 5 and Comment 9 are helpful. https://help.libreoffice.org/7.1/en-US/text/shared/01/01100100.html should add Note: information is exported to PDF if Apply User Data is used. https://help.libreoffice.org/7.1/en-US/text/shared/01/01100200.html should add Note: if used, user's name is exported to PDF as Author field. ricky.tigg: you may see that this was really a duplicate of previous bugs, search is advised before reporting.
(In reply to Timur from comment #10) > WFM is when there was a bug but not anymore - indicating we might find a fix > via reverse bibisect. > If something is not a bug upon explanation, that's NAB, indicating that > check should be done if documentation is fine. According to: > https://bugs.documentfoundation.org/page.cgi?id=fields.html#bug_status NOTABUG The problem described by the bug reporter is part of the expected behavior of LibreOffice. WORKSFORME The problem used to be reproducible, but it is not anymore with the latest version of LibreOffice. Unlike FIXED, exact fix commit is not known. As the one who chose WFM, I did so because it was a reproducible problem that is not a problem anymore. Whether the problem was "expected behavior of LO" as required for NAB is hard to say.
It is still sort of broken. REOPENING Three main problems. 1. MUST create document to get Author to appear in PDF properties. 2. Must NEVER save .odt document without "Apply User Data" checked. 3. Must have "Apply User Data" checked - when exporting to PDF Simple test illustration. 1. Open New Document 2. Be sure File - Properties - General - Apply User Data is checked (and First/Last name is filled in in Tools - Options - User Data) 3. Export PDF (see name as Author in PDF properties) 4. Uncheck Apply User Data 5. Export PDF (see no Author in PDF properties) 6. Check Apply User Data, Export PDF (see Author again) 7. Uncheck "Apply User Data", and notice also the "Created" field in the same dialog box, where your user name appears. 8. Save New Document 9. Notice that your user name disappears from "Created" in File - Properties - General 10. Export PDF with that document will no longer show username in Author of PDF properties, regardless of whether "Apply user data" is checked. Tested with master from today: Version: 7.1.0.0.alpha0+ (x64) Build ID: a883002d8e2fd77f80c43b7b2e6ac329d83d929d From comparing .fodt files, the critical issue is: <meta:initial-creator>USERNAME HERE</meta:initial-creator> Explanation a. When you create a new document, meta:initial-creator is created. b. I believe PDF uses <meta:initial-creator> to populate its author field. c. Saving to .odt or .fodt without "Apply User Data" checked loses that field, even if it was initially saved (because "Apply User Data" was checked). d. Once you save without "apply user data" checked, then the initial-creator field is lost, without any way at present to get it back. (beyond manual editing of .fodt file, as workaround) e. This analysis explains all the observations in the test sequence. In sum: If you want UserName to appear as Author in PDF files, then, at present, you (1) MUST create a new document, with Apply User Data checked, and then (2), then NEVER uncheck it (either when saving the file and/or exporting to PDF) Whether called a bug or an enhancement does not matter to me. If it was the intended design, then it is too fragile. I believe the report here identifies the problem clearly. Will not try to propose a design solution. Adding needsUXEval and cc: Timur
Seth Chaiklin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/help/commit/d3fd2f2d05f6b5a690012142dc414700379a58e9 tdf#117954 Add "tip" about exporting "Description" to PDF
(In reply to Timur from comment #10) > https://help.libreoffice.org/7.1/en-US/text/shared/01/01100100.html should > add > Note: information is exported to PDF if Apply User Data is used. Not necessary to have "Apply User Data" checked for Description export. Comment 13 has link to patch that provides "tip" about exporting Description data.
(In reply to Commit Notification from comment #13) > Seth Chaiklin committed a patch related to this issue. Not having read the request in detail, but is it fixed now? If so, please resolve as fixed.
(In reply to Heiko Tietze from comment #15) > Not having read the request in detail, but is it fixed now? If so, please > resolve as fixed. Not at all. Only a small documentation point was added (comment 13). Comment 12 describes the problem, which is likely to interact with bug 103212. Also bug 105702 comment 5 has important information in relation to comment 12 here.
Seth Chaiklin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/help/commit/d9a9b1f342cd9ecb0dc95636b62ebd8d456bfc0f Partially resolving tdf#117954 and tdf#107230 - help page updating
(In reply to Commit Notification from comment #17) > Partially resolving tdf#117954 Comment 17 is a patch that adds a note to the File - General - Properties help page about need to check Apply User data. (In reply to Timur from comment #10) > check should be done if documentation is fine. The two recent patches should resolve the documentation part of this bug. But critical problem, described in comment 12, remains.
(In reply to sdc.blanco from comment #16) > Not at all. Once you are done, please file a new ticket. I doubt we find a developer who reads through all the comments and patches. Plus, having a patch is not encouraging.
(In reply to Heiko Tietze from comment #19) > (In reply to sdc.blanco from comment #16) > > Not at all. > > Once you are done, please file a new ticket. I am done with making the documentation changes for this ticket. I am willing to file a new ticket, but comment 12 identifies 3 different issues. Not exactly a "bug report" (nor an enhancement request), because I do not know the design intention. Could you or Timur look at comment 12, and see if the whole description should be filed as one bug, or broken up into different bugs? (Also, Comment 12 is related to or interacts with the bugs about saving multiple authors, bug 103212, bug 105702, but I could not see any meaningful way to add comment 12 to those bugs). In short, seeking advice about the best way to communicate this complicated issue. (and what status should be given to this current bug?)
(In reply to sdc.blanco from comment #20) > because I do not know the design intention. @Heiko -- an additional thought. I think the "summary" for comment 12 is: "How can a user reliably control whether First/Last name in User Data is exported as Author in PDF Document Properties description?" That question seems to involve both UI/UX and code internals -- and as noted -- is likely to interact with the other bugs about multiple authors. I could use that question as bug summary and post comment 12 to illustrate the complexities. Do you think that would be a good way to go?
(In reply to sdc.blanco from comment #21) > "How can a user reliably control whether First/Last name in User Data is > exported as Author in PDF Document Properties description?" The user name is taken from tools > options > user data into the document properties and from there into the PDF, controlled by file > properties > apply user data. I don't see need for further enhancements specifically to PDF (yet the option in the pdf export dialog might be easy to implement, it clutters the dialog further). I bet there are tools to remove user data from a PDF.
(In reply to Heiko Tietze from comment #22) > The user name is taken from tools > options > user data into the document > properties and from there into the PDF, controlled by file > properties > > apply user data. But you are speaking here about the intention, no? If you have studied comment 12, then you will see some of the challenges (for the user) in achieving that intention (reliably). Or is your point that I should file a report that points out that this intention is not reliably realised (using comment 12 to illustrate the problem)?
Samuel, Thorsten, Tomaz: What do you think about a checkbox to omit the author's name when exporting to PDF? My take is c22.