Created attachment 73060 [details] paste special dialog When importing a visio image with paste special, all seems OK. But when scrolling after pasting, or changing size of image, the image itself disappears, although the frame remains and the link still is intact. It doesn't print either. I will attach 3 screenshots: 1. the paste special dialog 2. the pasted image 3. the disappeared image It did function properly in previous version (3.5). O/S: Windows7-64 Visio 2007
Created attachment 73061 [details] pasted image
Created attachment 73062 [details] disappeared image
Created attachment 73433 [details] completer import problem description Attached file describes and shows 3 methods to import visio object, all with problems.
Created attachment 73434 [details] the visio drawing used Attached visio file is the file used in the writer document with the 3 problematic methods.
Created attachment 73446 [details] completer import problem description (version2) Corrected and extended step by step descriptions of the three methods. Also, tested it with version 4.0.0.1 on Windows XP: Method 1: the second dialog does not appear. Instead an error is shown "object other objects can not be imported" Method 2: works good; that is there is no longer distortion of the image. method 3: nothing seems to happens after chosing that a Visio object is to be pasted. Nothing is inserted in the document.
Nominated as MAB 4.0 as the current performance is less than version 3.5 was and seriously hampers users who incorporate visio objects in their documents.
Tested with version 4.0.0.2: same behaviour as with version 4.0.0.1. Effectively, it seems no longer possible to insert a visio object and keep that a visio-object (i.e. not becoming a draw-object). I am willing to help solving this/these bug(s), but cannot build windows version, only Linux. @Fridrich: I apologise for bothering you, but as I understand you are the libvisio expert and I hope you can help.
Additional information: The cause seems to be in the import-code: When opening a document in version 3.6.4 created with version 3.5 (or earlier), the visio object can be edited with visio without the visible image disappearing.
So far, we have been able to perform method 1 (see comment#5) _without_ problem on two Win7-32 machines. All (including the Win7-64 machines) have the same Microsoft Visio2007 installation.
Any thoughts Fridrich ? :-)
Comment on attachment 73060 [details] paste special dialog mimetype fixed
Comment on attachment 73061 [details] pasted image mimetype fixed
Comment on attachment 73062 [details] disappeared image mimetype fixed
Did another test with LibO version 3.6.5.2 and 4.0.0.3 on Windows XP without MS Visio installed: version 3.6.5.2: -method 1: the second dialog does appear. MS Visio is not mentioned in the picklist (probably because it i snot installed). -method 2: works good, but image has some distortion (as it had on earlier version); -method 3: not possible to test as there is no MS Visio. version 4.0.0.3: -method 1: the second dialog does not appear. Instead an error is shown "object other objects can not be imported" -method 2: works good; -method 3: not possible to test as there is no MS Visio.
No idea if RTF is involved - probably not; but including Miklos is always fun :-)
(In reply to comment #15) > No idea if RTF is involved - probably not; but including Miklos is always > fun :-) It's more likely that EMF is involved :-P I guess copying from MS Visio could offer VSD and EMF in the clipboard for receiver application to choose from.
"object other objects can not be imported" problem should be fixed in 4.0.1.1 (bug 60492); the method indeed requires the application that provides the OLE object to be installed.
Created attachment 75490 [details] screenshot of imported visio object With version 4.0.1.1 (Windows XP, no Visio installed) I 1. created a new writer document 2. Insert - object - OLE object 3. other object 4. select from file 5. I selected a visio file 6. The object is inserted, but its contents cannot be seen (see attachment), neither in edit, nor in print-preview 7. When double-clicking on the object, Draw opens and show the object correctly.
I fear that this is related to https://bugs.freedesktop.org/show_bug.cgi?id=60638, since the preview images of ole objects are EMF+ files.
Not being able to help on the coding side of this bug, I try to provide as much information as I can. I hope to be able to provide more feedback on 4.0.1.1 (with regard to this bug) soon.
(In reply to comment #18) Version 4.0.1.1: - The steps of comment #18 on a pc (Windows 7) on which MS Visio (2007) is installed, results in a correctly imported Visio-object. - direct copy from MS Visio and paste special still doesn't work. - insert-object-OLE-object-from file still results in a non-Visio object in the writer document, which looks OK, but can no longer be edited with Visio.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=0cf6433117477642897fb2d874a4353eff8a1f35 fdo#59405: initialize members of TransferableObjectDescriptor The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ec0d1440cf07008a220708535848567bcbb233ea fdo#59405: cppcanvas: fix infinite loop in processEMFPlus The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=bf8450cfa2e9e899c716fbddadd7d5485aefe520 fdo#59405 fdo#60638: EMFWriter::ImplWrite: write EMF_PLUS "comments" The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
trying this on master with Visio 2010: Method 1: Insert → object → OLE object → Other object (create new selected) → ok (new dialog opens)→ from file → browse –> select File → ok this worked fine at first, but after storing the file, loading it again and then editing the OLE the preview image disappears. the "new" preview image is an EMF which appears to consist mainly of "EMF_PLUS" comments, and the exporter in vcl drops these. this is fixed by bf8450cfa2e9e899c716fbddadd7d5485aefe520, which simply writes the comments into the file; no idea if that is a good idea in general though. this turned up the next problem, apparently the MTF renderer doesn't interpret some records correnctly, and goes into infinite loop. this is fixed by ec0d1440cf07008a220708535848567bcbb233ea. Method 2: Insert → object → OLE object → create from file → find → select file → ok this appears to work already (comment #17). Method 3: Copy to clipboard in Visio → paste special in libreoffice → Microsoft visio drawing → ok this was working after fixing Method 1. only problem was that the object had a default square size, not the size of the "source" object. this is due to uninitialized variables, fixed with 0cf6433117477642897fb2d874a4353eff8a1f35. now i've got the problem that backporting the commit bf8450cfa2e9e899c716fbddadd7d5485aefe520 fails because it depends on the commit f1fee2a65c8c1968798e1246a4b455d9160d8eb9 "n#780748: Basic EMF+ implementation" which is only on master. is it a good idea to backport that or not? how this ever worked in older versions that apparently didn't understand this newfangled EMFPlus at all is a mystery to met.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=4536979e19d6a9a913f677225a122c13a51da1fa&h=libreoffice-4-0 fdo#59405 fdo#60638: EMFWriter::ImplWrite: write EMF_PLUS "comments" It will be available in LibreOffice 4.0.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=6cf68eab5eb77b7e081ef5f8d59d196411e86567&h=libreoffice-4-0 fdo#59405: cppcanvas: fix infinite loop in processEMFPlus It will be available in LibreOffice 4.0.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a724fb43d8540687e33d75c90660250e5308585d&h=libreoffice-4-0 fdo#59405: initialize members of TransferableObjectDescriptor It will be available in LibreOffice 4.0.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-4-0-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=83707a8b8a47efd074b7f03df0da779870efa687&h=libreoffice-4-0-1 fdo#59405: cppcanvas: fix infinite loop in processEMFPlus It will be available already in LibreOffice 4.0.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-4-0-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=7c5b8e0d5c1af03270a29d6144e192d69cb06de5&h=libreoffice-4-0-1 fdo#59405 fdo#60638: EMFWriter::ImplWrite: write EMF_PLUS "comments" It will be available already in LibreOffice 4.0.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-4-0-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=7da28b1cc0953e8d67248235f0eeac2abf140fe3&h=libreoffice-4-0-1 fdo#59405: initialize members of TransferableObjectDescriptor It will be available already in LibreOffice 4.0.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Created attachment 76007 [details] two visio imports that differ We tested the visio-import possibilities with version 4.0.1.2 on Windows 7 with Visio 2007. The second import (paste special) has a strange behaviour: the first second or so, all seems perfect, but the the contents shrink. The frame keeps its size. The attachment shows what I mean. I haven't reopened this bug, as I don't know the cause. It might have a completely different cause. Michael, please let me know if you want additional information/action from me.
(In reply to comment #32) > Michael, please let me know if you want additional information/action from > me. I meant Michael Stahl, but of course Michael Meeks is free to react as well :-)
Hello everybody We have used Visio import extensively with older (3.5) versions and import via clipbaord was always fine. Testing on 4.0.1.2 on Win7-32 the problems of this bug persists: 1. Copy direct: - take a Visio drawing - select all (CtrlA) - copy (CtrlC) - open LibO docuemnt - paste (CtrlC) -> drawing seems ok, but: - close document - reopen document -> the drawing has disappeared, only a whit frame remains (not always reproducible: the drawing appears at zoom levels > 250% (but still cannot be e.g. printed) 2. Copy special - take a Visio drawing - select all (CtrlA) - copy (CtrlC) - open LibO docuemnt - paste special - select Visio drawing -> drawing seems ok, but after a short time, it resizes to about 50% while retaining the frame size If needed I can provide the sample LibO & Visio files.
Some more feed back from version 4.0.1.2: When a visio object has been imported from a visio file, the object is converted and cannot be opened with visio later for editing. (insert object - OLE object - from file) I expected the object to remain a visio object.
(In reply to comment #35) > Some more feed back from version 4.0.1.2: > When a visio object has been imported from a visio file, the object is > converted and cannot be opened with visio later for editing. > (insert object - OLE object - from file) > > I expected the object to remain a visio object. Technically it should be possible to store original object and display conversion result. But what you are going to do if user change displayed object? libvisio doesn't support saving back to VSD.
(In reply to comment #36) > Technically it should be possible to store original object and display > conversion result. > But what you are going to do if user change displayed object? > libvisio doesn't support saving back to VSD. When a user wants to edit the object, the object will be edited by visio and not by draw. This was the case with version 3.5 and before and has been partly fixed since version 4.0.1.2.
(In reply to comment #37) > When a user wants to edit the object, the object will be edited by visio and > not by draw. This was the case with version 3.5 and before and has been > partly fixed since version 4.0.1.2. Do you know that Visio is only available for windows?
(In reply to comment #38) > Do you know that Visio is only available for windows? Yes, I do. My company uses a.o. MS Windows, MS Visio and LibreOffice. We have used visio objects in writer documents since we started using LibreOffice. Only since version 3.6 the problems began. Before that, a visio object imported in writer could be edited with visio (provided the machine has visio installed). FYI, I do some coding for LibreOffice and try to give bugs as much usefull information as I can. I may miss the point, but I don't see the relevance of your questions to this bug.
> Technically it should be possible to store original object and > display conversion result. Which sounds like the right way to go in general. Unfortunately, how achievable that is in terms of our current code structure, I don't know. Do we need another of those MS Compatibility option nightmares in the interoperability options around Visio ? Tools->Options->Load Save->Microsoft Office ? just for Visio/Load of course. Ideally we'd defer converting / rendering all embedded OLE2 objects until that was really genuinely necessary: that would help us wrt. interop. a lot, but ... that requires quite some work. Oh - and Winfried, meet Frob (Valek) - who did all the hard reverse engineering of the file format, and Valek - meet Winfried: much appreciated, prolific LibreOffice hacker :-)
(In reply to comment #40) Michael, thank you for your explanations, I was a bit lost with Valek's questions. I know very little of the internals of the visio/MS import actions and can only speak on behalf of our company that partly downgraded to version 3.5 because the usual method of making writer documents is to make all illustrations (schematics) with MS Visio, import them in the writer document and edit these imported objects (they even don't exist as an vsd file) if necessary with visio. The people who have this habit state that draw does offer enough functionality and that they need visio. The fixes sofar go a long way to the functionality that version 3.5 (and earlier) offered, the new libvisio library is wonderful, but IMHO there still some issues left to fix. I put any information that could be regarded as useful feedback into this bug, hoping to help the developer. And yes, all contributors together have produced and keep improving a marvellous product:)
Options: 1. Implement export to VSD in libvisio Game Level: nightmare Drawbacks: even if implemented most likely will be very brittle and not 100% compatible; requires way more extended import support and a lot of reverse engineering (or MS finally publish format specification). Chances: near 0 2. Implement export to VDX or VSDX Game Level: veteran Drawbacks: a) VDX is not compressed, files probably will explode 3-5 times in size. b) VSDX is only supported in the latest version of MS Visio. Both #1 and #2 are also not very good from "political" PoV (meaning RMS/FSF), if anybody cares. 3. Instead of ODG convert to SVG if VSD is embedded into another document. Visio is able to open SVG, hence ppl will be able to do something with a file. mime-association probably would need to be added/changed to open SVGs in Visio. I have no idea how good LO could handle such "open object in external application, update once it's closed" cases. Game Level: ?? Drawbacks: SVG support in LO and Visio could be below "production grade" for customer cases. If customer uses "advanced" features of Visio (eg. formula in ShapeSheet etc), this information will be lost. 4. Keep embedded VSD together with conversion result, provide configuration options and autodetection to let customer to use Visio to open/update embedded Visio file with re-import ODG (or SVG) copy after update. People who do not have Visio should be able to open converted part in Draw/Calligra/Inkscape/etc, after update they should be warned that original embedded Visio file will be discarded and should be able to chose what to do: - ignore changes keep original Visio/ODG (+save changed ODG/SVG in a separate file) -- similar to "read/delete only" state for embedded Visio files; - update ODG, discard Visio file -- current state, but with warning; - update ODG, replace Visio file with SVG -- mix of both, Visio still could be used by another user with drawbacks from #3. #4 looks not very easy, but doable (DISCLAIMER: I'm not a programmer). Michael, do you think it could fit into GSoC?
Created attachment 76512 [details] import problem demonstrated with 4.0.1.2 (In reply to comment #42) I think there are some misunderstandings, possibly one of the challenges when non-English people use English to express themselves ;) I attached a writer document, created with version 4.0.1.2 on a Windows7 machine that has MS Visio 2007 installed. I used 3 different methods to import a Visio drawing and described how i did it and how the imported object behaves when I want to edit it. In two of the methods, the object is opened for editing in Visio. So there must already be some magic in writer that handles that. The method that does not open for editing in Visio is also the only available method for machines that do not have Visio installed. IMO there are two issues to be fixed: -the scaling of the object in case of paste special -the 'missing link' to visio in case of insert object from file It seems as if the 4 options, of which No.4 looks the most proper to me, may not be necessary after all?
Attachment #73446 [details]. There are 3 embedded VSD files (Obj1, Obj3, Obj4) and one XML (Obj2), which seems to be a result of libvisio conversion. Corresponding "object replacements" are: - WMF, - SVM, - "empty" WMF, - "empty" WMF. SVM seems to be the one with text shifted up. Somehow libvisio kicks in only once ("method 2"). What I don't understand is where LO takes those WMFs (all VSDs have EMF "preview" in "SummaryInformation"). Wrong text' vertical position is a libvisio problem. (2 Fridrich: each digit is a separate shape, there is no "TextBlock", hence VAlign is not set. Do we use wrong default for it?) "Method 1" and "Method 3" seems to end-up on the same path. Assuming it worked in 3.5, I would say regression happened in the way LO handles update of the embedded object by its 'native' application.
(In reply to comment #44) > Attachment #73446 [details]. > This attachment was produced with version 3.6.4. Attachment #76512 [details] is produced with version 4.0.1.2 and so with the fix from Michael Stahl. I'm willing to produce other/more documents with visio imports, if that helps. I have versions 3.5.7, 3.6.4, 3.6.5 and 4.0.1 available on machines that have Visio installed.
I am not sure whether this is off topic, but when we use Visio (sorry, Draw does not have enough functionality), we always keep the original files. So if the import and then printing (to paper or export to PDF) would work again, this would be appreciated a lot. Maybe the editing from within LO can be postponed?
(In reply to comment #46) > I am not sure whether this is off topic, but when we use Visio (sorry, Draw > does not have enough functionality), we always keep the original files. > So if the import and then printing (to paper or export to PDF) would work > again, this would be appreciated a lot. Maybe the editing from within LO can > be postponed? When the visio object is imported by insert-object-etc. and you do not want to edit it from within Lo the bug is fixed since version 4.0.1, so your company can use version 4 ;) The remaining issues are scaling when importing via paste special and editing from within LO in the case of insert object from file, neither of which effect your way of working.
(In reply to comment #47) > (In reply to comment #46) > > I am not sure whether this is off topic, but when we use Visio (sorry, Draw > > does not have enough functionality), we always keep the original files. > > So if the import and then printing (to paper or export to PDF) would work > > again, this would be appreciated a lot. Maybe the editing from within LO can > > be postponed? > > When the visio object is imported by insert-object-etc. and you do not want > to edit it from within Lo the bug is fixed since version 4.0.1, so your > company can use version 4 ;) > > The remaining issues are scaling when importing via paste special and > editing from within LO in the case of insert object from file, neither of > which effect your way of working. Hi Winfried Sorry, but as documented in my comment 34 of 2013-03-07, case 1, it does not work in 4.0.1.2 (i.e. the imported image disappears after changing the document zoom factor or when the document is stored...)
(In reply to comment #48) > Hi Winfried > Sorry, but as documented in my comment 34 of 2013-03-07, case 1, it does not > work in 4.0.1.2 (i.e. the imported image disappears after changing the > document zoom factor or when the document is stored...) Sorry, I overlooked that when summarizing the open issues! Thank you for notifying. So the issues to be solved are (in order of importance) -unexpected and unwanted scaling after import, either directly after import or after resizing/saving document; -not possible to edit an imported visio object with visio. The bug is still a 'most annoying bug' and has the attention of several experts. We cannot but hope they will soon have the time to solve the issues.
Can someone test this with 3.6.0.4? I hate to ask to downgrade but we want to find out if it was introduced during the major release or in between the minor releases. If you can confirm on 3.6.0.4 please change the version to reflect this. Thanks!
Just tried with LO 3.6.0.4 and MS Visio 2010 on Win7 Pro: copy-paste standard does not work: Vision drawing is inserted, but disappears after save and reopen copy-paste special neither works: drawing disappears after about 2 s
BTW: The copy-paste operation works/ worked with LO 3.5.5.3
Created attachment 78800 [details] import methods tested with version 4.0.3 I just tested the 3 methods as described in attachment 76512 [details] with version 4.0.3.2 on Windows 7 with MS Visio 2007 installed: -All 3 import methods work, there is no longer a scaling problem; -With method 1 and 3 the object is edited with Visio when double-clicking it, but with method 2 it is still edited with LibreOffice instead of Visio. Conclusion, the remaining problem is minor and the result seems suitable for company use. Because of the remaining issue, I leave the bug status at reopened. Thank you all for your efforts!
> Conclusion, the remaining problem is minor and the result seems > suitable for company use. Wonderful news; thanks for that - I will close this bug - it is a MAB, and that will help get our tracking of these issues right. If there is a remaining minor issue - please can you split it out into it's own (hopefully much shorter ;-) issue that references this. Thanks again to all who helped file / test / debug this !
Hello everybody Just tested on Win7-64/ Visio 2010, LO 4.0.0.3: 1. select all in Visio 2. paste OR paste special in LO does not work, same behavior as before: - paste: the image is inserted, but disappears after save-reopen (white frame remains) - paste special: the image resizes after 1..2 sec to approx 60% I can provide the files, screenshots look the same as already attached IMHO: not fixed Or shall I generate a new bug for this?
Yes, please do open a new bug, feel free to refer to this one in its description.
(In reply to comment #55) > Hello everybody > > Just tested on Win7-64/ Visio 2010, LO 4.0.0.3: > 1. select all in Visio > 2. paste OR paste special in LO > > does not work, same behavior as before: > - paste: the image is inserted, but disappears after save-reopen (white > frame remains) > - paste special: the image resizes after 1..2 sec to approx 60% > > I can provide the files, screenshots look the same as already attached > > IMHO: not fixed > Or shall I generate a new bug for this? Is the version on which you tested 4.0.0.3? The bug has been fixed with version 4.0.3, so will be present in version 4.0.0, 4.0.1 and 4.0.2. Or is it a typing error and you mean version 4.0.3? I just checked with Win7-32/Visio 2007, LO 4.0.3.3 and cannot reproduce your problem with paste special. I can reproduce the problem with paste. Could you relate this bug number to the new bug you create for your problem? Thank you for your help.
(In reply to comment #57) > Is the version on which you tested 4.0.0.3? The bug has been fixed with > version 4.0.3, so will be present in version 4.0.0, 4.0.1 and 4.0.2. > Or is it a typing error and you mean version 4.0.3? > I just checked with Win7-32/Visio 2007, LO 4.0.3.3 and cannot reproduce your > problem with paste special. > I can reproduce the problem with paste. > Could you relate this bug number to the new bug you create for your problem? > Thank you for your help. Sorry, typo: 4.0.3.3 I did not generate a new bug, but added to Bug 63799 (maybe a Visio 2010 related problem?) Sorry again!!!