Bug 58424 - : Management of vector images remains inconsistent in LibO 4.0 beta 1
Summary: : Management of vector images remains inconsistent in LibO 4.0 beta 1
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
4.0.0.0.beta1
Hardware: Other All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks: Images UX
  Show dependency treegraph
 
Reported: 2012-12-17 16:57 UTC by sergio.callegari
Modified: 2018-11-01 19:09 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description sergio.callegari 2012-12-17 16:57:37 UTC
This is more the expression of a wish than a real bug report. But sort of bug report too, if poor usability is a bug.

LibO behaviour with respect to images in vector format remains is quite inconsistent. I was hoping to see improvements in Libo4, but apparently the inconsistencies remain.

In the past staroffice and openoffice could only open wmf, emf and their own metafile format as vector image format. In write, such images would simply display. In draw and impress, they could be made editable by right clicking them and asking for the image to be split into its elements, as if it was a group image. Making the image editable by dividing it in elements could at time result in some minor artifact or image change. Printing the file (or exporting to ps/pdf) the image used to remain vector type.

Would have been great if adding support for other image formats, this behaviour had been retained. However, now LibO supports eps, pdf, svg and all of them are handled differently:

1) eps: only a low quality image is display. Image cannot be edited in any way.

would be great if eps files could be inserted in writer/draw/impress, having the software render a good bitmap version for the screen and presentations (there are many libs for rasterizing ps, which alternatively can be easily converted to pdf and be managed as such). Furthermore, would be great if eps could be made editable, by converting them to the LibO object format by 'ungrouping' them.

2) pdf: writer cannot open the format. Similarly draw/impress cannot insert an image of this type. However, draw can 'open' a pdf image and in this case an automatic conversion of the pdf to the internal object format of LibO is perfomed, with some loss of the original image formatting.

Would be great if pdf file could be inserted in writer/draw/impress, having the software render a good bitmap version for the screen and presentations (there are many libs for rasterizing pdf). Furthermore, would be great if eps could be made editable, by converting them to the LibO object format by 'ungrouping' them.

3) svg: writer, draw and impress can all insert images of this type. Furthermore, by 'dividing' them, they become editable in draw/impress. Good.  However, their management is very slow in LibO 4. In LibO 3 on the other hand, writer is uncapable of 'printing' them as vector images (a bitmap is sent to the printer at a low res). In LibO3, svg.gz files cannot be inserted. Furthermore if svg files are inserted, they get stored uncompressed in the opendocument file, taking a lot of space. Being xml files, they should be compressed. 
              
Operating System: All
Comment 1 Joel Madero 2013-01-11 17:55:23 UTC
Looks like a good set of enhancement requests all about vector images. 

I'm marking as such.
Comment 2 Roeland 2017-05-09 13:43:54 UTC
Shouldn't these points be broken up in different bug reports?

About the 3rd one, maybe this will change when the SVG tender gets in effect? (https://blog.documentfoundation.org/blog/2017/05/03/tender-deprecate-libreoffices-svg-filter-favour-svgio-201705-02/)
Comment 3 Roeland 2017-05-09 13:47:42 UTC
Bug 67464 seems like a bug report concerning the first issue