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
Looks like a good set of enhancement requests all about vector images.
I'm marking as such.
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/)
Bug 67464 seems like a bug report concerning the first issue