Bug 128266 - FILESAVE: missing title in exported epsf
Summary: FILESAVE: missing title in exported epsf
Status: RESOLVED NOTOURBUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: filters and storage (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-10-20 10:57 UTC by Gerry Garvey
Modified: 2019-12-12 12:46 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
EPSF with "%%Tile: none" at line 5 (76.56 KB, image/x-eps)
2019-10-24 16:56 UTC, Gerry Garvey
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gerry Garvey 2019-10-20 10:57:17 UTC
When a drawing is exported as EPSF, the title is always set to "none". Could this field be taken from the document title instead, as happens for PDF files?
Comment 1 V Stuart Foote 2019-10-20 18:27:38 UTC
Can not confirm.

An export will pick up the name of the Draw ODG file being edited and exported--file extension will then match the export filter format.
Comment 2 Xisco Faulí 2019-10-22 09:46:26 UTC
Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. 
(Please note that the attachment will be public, remove any sensitive information before attaching it. 
See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.)

I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided.
Comment 3 Gerry Garvey 2019-10-24 16:56:00 UTC
Created attachment 155286 [details]
EPSF with "%%Tile: none" at line 5

This EPS file was generated from the same sample ODG file provided for bug 128265 which has "Test of mulit-line text box rotation" in the document title field in properties.
Comment 4 V Stuart Foote 2019-10-24 18:55:17 UTC
As implemented, those strings internal to the exported EPS image are hard coded in the export filter [1].

Not clear there is any advantage to adding a value internally--it is otherwise valid EPS.


=-ref-=

https://opengrok.libreoffice.org/xref/core/filter/source/graphicfilter/eps/eps.cxx?&r=241bee7e&h=455#455
Comment 5 Gerry Garvey 2019-10-24 19:32:44 UTC
I think the choice should be between having a valid value from the document properties or not include the %%Title: field at all.
Comment 6 V Stuart Foote 2019-10-24 20:10:46 UTC
(In reply to Gerry Garvey from comment #5)
> I think the choice should be between having a valid value from the document
> properties or not include the %%Title: field at all.

Why? The EPS File Format v3.0 compliant as is with the "recommended" Comments hard-coded. Some over zealous validation tools would likely complain if there is no entry. 

The useful comment of %%Creator is populated with the generator details.

The "%%Title: None", "%%CreationDate: None", "%%Pages: 0" comments can be directly edited in any text editor for those rare users that might need to see the comments in some external application--no significance to LibreOffice.
Comment 7 Xisco Faulí 2019-12-12 12:46:51 UTC
(In reply to V Stuart Foote from comment #6)
> (In reply to Gerry Garvey from comment #5)
> > I think the choice should be between having a valid value from the document
> > properties or not include the %%Title: field at all.
> 
> Why? The EPS File Format v3.0 compliant as is with the "recommended"
> Comments hard-coded. Some over zealous validation tools would likely
> complain if there is no entry. 
> 
> The useful comment of %%Creator is populated with the generator details.
> 
> The "%%Title: None", "%%CreationDate: None", "%%Pages: 0" comments can be
> directly edited in any text editor for those rare users that might need to
> see the comments in some external application--no significance to
> LibreOffice.

Closing as RESOLVED NOTOURBUG