Description: 1. Create foo.odg. 2. Export foo directly to foo.pdf. 3. Open foo.pdf with firefox. 4. File name is shown as "landscape - foo.pdf" instead of just "foo.pdf". 5. Similar name corruption with acrobat. Steps to Reproduce: 1. Create foo.odg. 2. Export foo directly to foo.pdf. 3. Open foo.pdf with firefox. 4. File name is shown as "landscape - foo.pdf" instead of just "foo.pdf". 5. Similar name corruption with acrobat. Actual Results: Name shown is "landscape - foo.pdf". Expected Results: Name shown is "foo.pdf" Reproducible: Always User Profile Reset: No Additional Info: Cannot copy and paste information from menu Help - About LibreOffice. I love Draw!
*Likely* you are using some template to create Draw documents, named "Landscape". And when a template is used, its name gets set in File->Properties->Description. If there is some text in the title, it naturally gets into the PDF as the document title. To workaround, you can clear the mentioned property in your created documents. The question is - why the template name should get to the document title at all? I'd suppose it confusing, unexpected and wrong for most cases. Asking UX input.
It probably comes from the wish to propose a file name based on the content of the document on first save (bug 58685). The same happens also in other modules, eg. Writer, and File > Properties > Description: Title is used on the PDF (in any reader; <rdf:Description... <dc:title> <rdf:Alt> <rdf:li xml:lang="x-default">Test</rdf:li>). Not sure but maybe Miklos implemented it for epub.
I'd close this as WF.
(In reply to Timur from comment #3) I'd suggest to discuss before WFing. I doubt it related to the initial file name - and the title metadata of the document does not get to the filenames proposed in the Save As dialog. Then: do users really need the *template name* as the filename suggestion? Do you expect your file named "Landscape" or "Blue and Red Gradient", just because such a template was used to create it? How could it relate to the document identity? I also doubt that it is related to epub work - it was implemented for 6.0 [1], while the discussed behavior is also present in OOo 3.2.0. So the question is - if there is *any* justification in this behavior at all? I mean, other than "nobody knows, and nobody cares to drop it". Possibly debugging and checking relevant code commit history could shed some light. [1] https://wiki.documentfoundation.org/ReleaseNotes/6.0#New_filters
The problem appears to happen at the "Save as Template" stage, when the name entered into the dialog gets written also as the template document's title: SfxDocTplService_Impl::storeTemplate [1] sets the "DocumentTitle" property; then it is used in TransformParameters [2] and then in SfxObjectShell::APISaveAs_Impl [3]. Setting the "DocumentTitle" in [1] was added in commit 72d6767bb2eafee703c429fd1b6fb562ebb43caa, and the need for that wasn't mentioned there. [1] https://opengrok.libreoffice.org/xref/core/sfx2/source/doc/doctemplates.cxx?r=0bfa6a18#1774 [2] https://opengrok.libreoffice.org/xref/core/sfx2/source/appl/appuno.cxx?r=e6de84d4#750 [3] https://opengrok.libreoffice.org/xref/core/sfx2/source/doc/objserv.cxx?r=28c31ba1#313
Adding the template name to the document title is nonsense. Let's remove it.
So, the document title is (ab)used in template management to name the templates, display them, rename, etc. - so that means that it's not possible to avoid *setting* the title in the templates themselves (unless we do a major reimplementation of the commit mentioned in comment 5). This means that to avoid the bogus title in the documents created from templates having titles, we must clear the title upon creation of the documents from templates. That would mean that not all the data from template gets into final documents - but I don't see a better way. Clearing can be done the same way that is used to set it - i.e., adding an explicit DocumentTitle property with an empty string value to the new document's media descriptor.
(In reply to Mike Kaganski from comment #7) > So, the document title is (ab)used in template management to name the > templates, display them, rename, etc. - so that means that it's not possible > to avoid *setting* the title in the templates themselves (unless we do a > major reimplementation of the commit mentioned in comment 5). My UX: - Created a template called "NAME". New files from this template has title "NAME". - Edited it, and deleted the title. New files from this template has no title. - I managed templates, and renamed it to "NAME_vert". New files from this template has title "NAME_vert". But file name still is "NAME.ott".
My workflow with template is different because built-in template management (at least in Writer) would _move_ the file from its present location to LO internal template folder (in user profile). This directory is usually hidden. So, it is a pain to update templates. I create my template in a user directory as .odt document for ease of update and maintenance, not having to care for .ott instantiation. I can also use File>Templates>Edit Template if the file is saved as .ott, at the expense of opening first LO instead of a double-click (which would instantiate the template). Thus my templates are all visible in my user directory. When I want to integrate a template, I copy it manually in one of the declared template directories. This manual copy _never_ causes any modification to template contents. From experimentation, it is only File>Templates>Manage Templates which causes a change in File>Properties, Description tab, Title field. I didn't check whether an existing Title is modified by template management. So, works for me. But at least a caveat should be documented either in built-in help or in documentation (best: both of them).
(In reply to ajlittoz from comment #9) > So, works for me. Rather, "a workaround exist". In the sense that there is another workflow that doesn't suffer from this problem, but the specific workflow discussed here - involving built-in template management - definitely has the problem.
I would like to add that I too think this should be dealt with. On the following version: Version: 7.5.7.1 (X86_64) / LibreOffice Community Build ID: 47eb0cf7efbacdee9b19ae25d6752381ede23126 CPU threads: 2; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-GB (en_GB); UI: en-GB Calc: threaded I have this 'bug' whereby if I export a document as PDF and open the PDF in my PDF editor then the name the PDF editor shows for the file is the whatever the Title is in document properties. In my case the title would be the name of the template used in creating the document. This definitely needs fixed. It is very tedious to have to try and remember to remove the Title information before exporting the document as PDF. And of course the knock-on effect of moving 'the problem' to an entirely other application: the PDF editor. Needs fixed with some urgency I would think.
When a document is created from hard-coded default or based on a template, it gets a provisional title like "Untitled 1" which is assigned to the models .Title property. (It then is also used for the titlebar of the framse's window, but may be modified by custom code for that position!) THIS is the moment to also assign that provisional title to the .Title property of the model. Actually there is either an empty string or the template name. This is part of the mess made up by inconsistent naming and by the counter-rational presentation of properties pretending a structure not actually supported by the API and using (in English!) different arbitrary names as compared to the API. The Title property (used for pdf export e.g.) is shown as if an element of 'Description', and what's shown there as 'Comment' is treated as 'Description' by the API interfacet XDocumentProperties. Actualöly the situation is messed up in a way that I only can recommend a workaround by custom code to get the title wanted for export where it belongs.