Created attachment 80723 [details] Zip with Visio Source, Visio screenshot, Writer screenshot When inserting drawing via clipboard from Visio (2010) to Writer (this worked before 3.6!), strange effects occur, both via copy and copy special. I attached the original and result as screenshots (LO master-2013-06-11), also the Visio file. Any Writer file will produce the error, but I can add one one request. Andy
Any chance of the resulting writer document too save as ODF ? ultimately this will be an EMF+ meta-file rendering bug of the preview of the OLE object that is stored there, and that's the file we'll end up fixing :-) Thanks ! ( and confirming it looks plausible ;-)
Created attachment 80782 [details] ODT file w/ Visio drawing inserted Writer odt with Visio copied: note that after saving, the inserted image is an empty frame (see screenshot for how it looked before reopening)
Created attachment 117942 [details] OPs Visio .VSD drawing OLE inserted into Writer Draw opens the Visio .VSD with good fidelity, minor font and style issues--but legible. Likewise Insert OLE object renders with good fidelity, so libvisio is handling things correclty. However, copy paste -> special looks to be an issue. When the .VSD is opened in Draw, while it shows good fidelity, the Copy and Paste Special -> More Options -> "Draw 8" paste is truncating the bottom edge of the converted Visio object. The Visio object is otherwise legible. Don't have Viso to work with so not sure about filter for Copy -> Paste Special there. Attached .ODT from current 5.0.1.1 release, on Windows 10 Pro 64-bit. Would say resolved fixed. Changing component from Draw to libvisio filter.
Added a needsVisio whiteboard item. This needs to be checked with Visio drawing open in a Visio instance, and use LibreOffice Paste Special -> More options to judge fidelity of the filter import directly from Visio. OLE linking of the .VSD Drawing with libvisio is otherwise pretty good.
This has nothing to do with how the visio filter operates. What Writer is rendering if you don't click on the OLE object is a replacement EMF+ image of this object. So, any problem with that rendering is actually problem of the EMF+ renderer. Nevertheless, the last attached file looks like the issue is fixed. Closing it then.