https://bugs.freedesktop.org/show_bug.cgi?id=85569
--- Comment #6 from Jérôme Borme <[email protected]> --- Created attachment 108658 --> https://bugs.freedesktop.org/attachment.cgi?id=108658&action=edit pdf files opened in Draw, saved to odg and dropped into Impress (blue frame added for visibility) > not sure this is even a bug. >From the point of view of the user, I was expecting OLE to "just work" with all the format it advertises as supported. OLE does detect the boundaries of bitmap images, there is no obvious reason to the user why pdf would behave any different. You raise the point that I could use other formats. pdf has the advantage that virtually all software can produce it through printer emulation. It's a format that is fine to exchange with colleagues, fine to archive as a final document, fine to print on paper. svg performs worse in all the above criteria (my colleagues would have no clue what to do with an svg, it's not directly usable to print and screen rendering varies in quality, it's less nice to archive as it takes more space and embedded objects might be a problem), and also svg support in LO is not bug-free either. Bitmap images are not a solution for many reasons that are out of the scope of this bug (not editable, by default transparency is likely to not be used, changes in size damage quality, aliasing fixed at production, poor result when printing). > Draw remains the preferred work flow for filtering PDF for import to ODF. Drag-and-drop to Draw of the provided pdf files pruduces the same bug: boundaries are not correct. > Then saving the filter converted PDF to ODF .ODG drawing provides > the best handling within the program. The converted drawing can > be inserted as OLE (copied or linked), or dragged from system > file manager again OLE. I finally understood that you meant that using File/Open on the file would give a better result. This was not obvious as for me File/Open is just for native formats. Formats other than native are imported into a document, not "opened". But okay, I understood. Anyway, your suggestion does not always lead to good results. If the pdf is opened in Draw, saved in odg, then inserted again by OLE drag-and-drop, then an undesirable white space the size of a full page is added around the drawing (attached document). Also, it makes little sense from the perspective of the user that drag-and-drop would give worse results than File/Open. Drag-and-drop was invented in the first place because it is far more practical than opening one by one all the documents. That the implementation is not perfect is understandable, still the objective should be that it should perform well. To give an example, this is my use case: every Fridays morning, I am in a hurry to prepare a presentation for a meeting with my boss. Maybe I could do it the day before with more time, but we all know it's not going to happen. So I'm in a hurry, I create an empty document, drag and drop what I have to insert and try and arrange them into a meaningful presentation. It needs to be fast and it needs to work well at first try, because life is short and work is plenty. It is annoying for me the user if I have to give up on OLE and open the files one by one in a separate application (Draw), save them as odg, then open again in Impress. I might have many files to process this way, and I'm using an office suite to help me with my productivity needs, after all. -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
