Created attachment 62915 [details] Microsoft Visio sample file The Microsoft Visio example file 'IPD - System Center Virtual Machine Manager 2008 version 2.0 diagram.vsd' displays as a blanc page in LibreOffice.
Created attachment 62916 [details] Screenshot of file in LibreOffice 3.5.4.2
Created attachment 62917 [details] Screenshot of file in Microsoft Visio 2003
Created attachment 63121 [details] bt + console msgs on master On pc Debian x86-64, with master sources updated today, I had a crash. I attached the bt. By trying to follow the process, I had this : Breakpoint 1, GraphicManager::ImplCreateOutput (this=0x2c56320, pOut=0x42a8198, rPt=..., rSz=..., rBmpEx=..., rAttr=..., nFlags=3, pBmpEx=0x0) at /home/julien/compile-libreoffice/libo/svtools/source/graphic/grfmgr2.cxx:364 364 Point aOutPtPix; (gdb) n 365 Size aOutSzPix; (gdb) n 366 Size aUnrotatedSzPix( pOut->LogicToPixel( rSz ) ); (gdb) s [Thread 0x7f2cba155700 (LWP 21368) exited] OutputDevice::LogicToPixel (this=0x42a8198, rLogicSize=...) at /home/julien/compile-libreoffice/libo/vcl/source/gdi/outmap.cxx:1052 1052 DBG_CHKTHIS( OutputDevice, ImplDbgCheckOutputDevice ); (gdb) n 1054 if ( !mbMap ) (gdb) n 1055 return rLogicSize; (gdb) p mbMap $1 = 0 '\000' (gdb) p rLogicSize $2 = (const Size &) @0x7fff18dfb600: {<Pair> = {nA = 2147483648, nB = 2147483648}, <No data fields>} (gdb) bt #0 OutputDevice::LogicToPixel (this=0x42a8198, rLogicSize=...) at /home/julien/compile-libreoffice/libo/vcl/source/gdi/outmap.cxx:1055 #1 0x00007f2ceb0aa03c in GraphicManager::ImplCreateOutput (this=0x2c56320, pOut=0x42a8198, rPt=..., rSz=..., rBmpEx=..., rAttr=..., nFlags=3, pBmpEx=0x0) at /home/julien/compile-libreoffice/libo/svtools/source/graphic/grfmgr2.cxx:366 #2 0x00007f2ceb0a9c5d in GraphicManager::ImplDraw (this=0x2c56320, pOut=0x42a8198, rPt=..., rSz=..., rObj=..., rAttr=..., nFlags=3, rCached=@0x7fff18dfb76f: 0 '\000') at /home/julien/compile-libreoffice/libo/svtools/source/graphic/grfmgr2.cxx:306 #3 0x00007f2ceb0a9730 in GraphicManager::DrawObj (this=0x2c56320, pOut=0x42a8198, rPt=..., rSz=..., rObj=..., rAttr=..., nFlags=3, rCached=@0x7fff18dfb76f: 0 '\000') at /home/julien/compile-libreoffice/libo/svtools/source/graphic/grfmgr2.cxx:215 #4 0x00007f2ceb0a3867 in GraphicObject::Draw (this=0x7fff18dfb7f0, pOut=0x42a8198, rPt=..., rSz=..., pAttr=0x7fff18dfb8e0, nFlags=3) at /home/julien/compile-libreoffice/libo/svtools/source/graphic/grfmgr.cxx:573 Notice the value "2147483648". I just wonder : - Size type is defined at tools/inc/tools/gen.hxx with long variable - in drawinglayer/source/processor2d/vclhelperbitmaprender.cxx, we can read : 89 const Size aSize( 90 basegfx::fround(aOutlineRange.getWidth()), 91 basegfx::fround(aOutlineRange.getHeight())); aOutlineRange uses double type variables and I don't know if the function fround here basegfx/inc/basegfx/numeric/ftools.hxx is ok.
I don't have a blank page but a crash. Perhaps it's just a different treatment between Windows and Linux compilers. Anyway, there's a pb here
Re-tried this with master/daily build 'master~2012-06-20_04.39.07_LibO-Dev_3.7.0.0.alpha0_Win_x86_install_en-US.msi' today. The initial page is still blank. A crash does occur for me after loading the document (which displays as a blank page) when I right click anywhere in the 'Pages' panel.
Fridrich: one for you ?
@frob: this file is funny, the visible pages don't have the structure of pages that we normally know. With page pointer that after has chunks with page chunk first. In this document, the page looks more like a stencil page. The page pointer with again pointers for pageSheet, shape=shape, ... that themselves point to chunks. The problem is that how can we know that we should expect this kind of layout? Oletoy handles it well, but I did not get completely how it arbiters which parsing to use. Please advise.
@John: We are working on it. But if we fix it, this will be such an intrusive change that nobody ever will agree to have it in 3.5.x line. So the target might be 3.6 at best :( The document looks different from what we saw before and an additional reverse-engineering and understanding of how it actually works will be needed.
John, do you know what version of Visio made this file? It uses known types of structures in unusual way, so r.e. part is minimal, but it could require significant changes in parser code of libvisio.
Fridrich, Valek: Since it's not trivial to fix this bug, would it be possible/useful for 3.5 branch to detect that this file can't be opened and use a popup message like "This Visio file can't be opened" ?
@All: I do not know which version of Viso created the file; I just downloaded it from the public Microsoft website. When I open and 'Save As' the file in Visio 2003 first, the 'saved-as-2003' document does display correctly in LibreOffice master. I have no desires about which LibreOffice version this will be fixed in ; just knowing that it will be worked on and will have a target somewhere in the future is good enough for me.
(In reply to comment #11) > @All: I do not know which version of Viso created the file; I just downloaded > it from the public Microsoft website. When I open and 'Save As' the file in > Visio 2003 first, the 'saved-as-2003' document does display correctly in > LibreOffice master. I have no desires about which LibreOffice version this will > be fixed in ; just knowing that it will be worked on and will have a target > somewhere in the future is good enough for me. John, for sure we work on it. The problem we have that when reverse-engineering the format, we did never see this kind of structure. We are able to understand it though, only the parser is assuming something and this file makes the assumption be broken in pieces :). We are now trying to understand how to restructure the parser so that it is not too much of an unmaintainable mess but that handles this kind of situation in a robust way. I can imagine that 3.6 could be the right target, since I will have in July a contiguous week with a possibility to work on this thing.
(In reply to comment #9) > do you know what version of Visio made this file? Valek, my guts feeling is that it is generated by the SDK using the API. I did never see Visio itself generating that. And the fact that Save As is saving it in the layout we assumed, ....
Created attachment 64734 [details] Conversion with git version of libvisio OK, as a good news, I refactored a bit the libvisio parser and with this last commit http://cgit.freedesktop.org/libreoffice/contrib/libvisio/commit/?id=6c3dbc359f03eebe5f81d90a2f77cad295b14fe6, we get the attached conversion
Thanks! Could you give a rough estimate of which LibreOffice version you expect to use this version of libvisio ?
Fridrich Štrba committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=46f61ff87098dad62e32aa162c4ccfa71850550a Uploading libvisio 0.0.19, fixes fdo#50990
Fridrich Å trba committed a patch related to this issue. It has been pushed to "libreoffice-3-5": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ef99e34b2ab0807417b7fad2c9016ede2d10aee5&g=libreoffice-3-5 Uploading libvisio 0.0.19, fixes fdo#50990 It will be available in LibreOffice 3.5.6.
Fridrich Å trba committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=2d843d507cda891568eb2c55c05d1fdaa0929dd9&g=libreoffice-3-6 Uploading libvisio 0.0.19, fixes fdo#50990 It will be available in LibreOffice 3.6.1.
Created attachment 66197 [details] Blade - Visio source If you guys want to test visio....try this
Created attachment 66198 [details] Blade - It should look like this
Not matching parts on the right side seems to be embedded EMF/EMF+ images.