Created attachment 98132 [details] Test document created using LibreOffice 4.2.4.1 Tested using Windows 8.1 with LibreOffice Version: 4.3.0.0.alpha1+ Build ID: a3c00ee3c7b3b0fbcde32baeb7023c7e8526b908 TinderBox: Win-x86@47-TDF, Branch:MASTER, Time: 2014-04-28_07:22:55 How to reproduce: * Open attached test document Behavior: empty table in document. Only a border is drawn where the content is supposed to be. If you double click on it, and deselect it again, content is visible. How to create document yourself: * Open new spreadsheet using LibreOffice 4.2 or older (not 4.3) * Type some numbers in column 1 (lets say just 1 to 5 from A1 to A5) * Select A1 to A5 and copy (CTRL + C) * Open new document using same LibreOffice version (4.2 or older) * Paste in document (CTRL + V) * Save document (as .odt). You can either close or save the spreadsheet (doesn't matter). * Open saved document using version 4.3 Regression against 4.2. This bug is not reproducible if you create the document using 4.3 itself. Kind regards, Joren
Confirmed with 4.2.3 and 4.3 master
OpenSuse => All OS
*** Bug 78134 has been marked as a duplicate of this bug. ***
looks like another EMF/WMF regression, on master; current 4.2 works
Ah WMF/EMF - one step forward, one step back...
It's not WMF/EMF regression.. it's a SVM (GDIMetafile) font rendering regression :) I think there is already a duplicate bug reported (I vaguely remember reading one).
(In reply to comment #6) > It's not WMF/EMF regression.. it's a SVM (GDIMetafile) font rendering > regression :) I think there is already a duplicate bug reported (I vaguely > remember reading one). I'm not a developer, but please try to find a consensus which kind of regression this is ;-). /me hides If this is a GDIMetafile regression, we can mark bug 79080 as a dupe. Please do so if that's the case. Kind regards, Joren
PS: if that's the case, in bug 79080 there is a bibisection attached.
This one is simple - There is no WMF/EMF in the document so it can't be a WMF/EMF regression (if the laws in this universe still apply). :) On the other hand there is a SVM file (object replacement) and SVM is just a serialized form of a GDIMetafile.
well i'm just a dumb writer developer, all i care about is it's not a writer bug :)
Caolan McNamara committed a patch related to this issue. It has been pushed to "libreoffice-4-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=86823db3412fc10ca75fa1e0b1900118582149c6&h=libreoffice-4-3 Resolves: fdo#78040 nAryLen is traditionally 32bit not 16bit It will be available in LibreOffice 4.3. 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.
Caolan McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=5326c563463a8682e0433c0badf39657446f1053 Resolves: fdo#78040 nAryLen is traditionally 32bit not 16bit 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.
*** Bug 79080 has been marked as a duplicate of this bug. ***
oops, looks like this one was actually my fault :) see that's why i usually try to stay away from graphics bugs :)