Created attachment 67101 [details] The sample Word .DOC file - Greek Libreoffice 3.6.1.2 - Deployment via GPO - Windows XP SP3 32-bit Greek systems - Greek locale We had a large number of client computers running LibO 3.5.2 via group policy. We updated to 3.6.1(.2) via gpo. After that, we are experiencing formatting problems in a number of computers. Specifically, various .DOC files open with formatting problems. If the .DOC is saved in ODT, and then the .ODT is opened instead, the last file opens just fine! Note that we did not have encounter this problem with libreoffice 3.5.2 Attached please find: - sampl.doc: The sample Word .DOC file - correct_libo3.5.2.png: The file as it looks like under both Microsoft Word 2003 and LibO 3.5.2. Formatting is exactly the same - faulty_libo3.6.1.2.png: The same .DOC file when viewed under LibO 3.6.1.2: notice the problematic right side where table lines have appeared. If user tries to edit the text there, the entire right side text might disappear.
This might be connected to bug #54862 btw.
Created attachment 67102 [details] File as opened by LibO 3.5.2 or MS Word, all ok
Created attachment 67103 [details] Problematic open in 3.6.1.2: formatting in the table is destroyed
Created attachment 67104 [details] The correct image
Created attachment 67105 [details] Incorrect formatting when opened with 3.6.1.2, problems at right side.
(In reply to comment #1) > This might be connected to bug #54862 btw. Please disregard this, hard time, no sleep. This might be connected to bug# 50869.
(In reply to comment #6) > This might be connected to bug# 50869. Maybe, but im not sure. You say that the issue described here (bug #54862) does not occur with LibO 3.5.2. But bug #50869 has been present even back in OpenOffice before the LibreOffice fork, so it also occurs in LibO 3.5.2.
(In reply to comment #7) > (In reply to comment #6) > > This might be connected to bug# 50869. > Maybe, but im not sure. You say that the issue described here (bug #54862) does > not occur with LibO 3.5.2. But bug #50869 has been present even back in > OpenOffice before the LibreOffice fork, so it also occurs in LibO 3.5.2. I see, then in this case let's deal this as a separate issue. The tests I did indicate that the file opens perfectly in 3.5.2 (which we are using heavily, some ~200 installations).
Created attachment 67754 [details] Case #2: original Word document (.DOC) It's puzzling to see that this bug has been not been assigned to someone yet. Its impact is rather large, especially on organizations with a large number of documents in Word format. No offense here, I know that is a for-free collaborative project. Perhaps there are other bugs related to this one, and work is being done for them (ergo for this one as well)? Poor man's workaround: save the original .doc to .odt, close the newly generated .odt (because it will still display with a wrong formatting), re-open it, formatting is ok now! I'm uploading a couple of files, the original doc and the save one as .odt. Notice the difference between the two (using 3.6.1).
Created attachment 67755 [details] Case #2: Same file exported to OpenDocument
Possibly related to bug# 50869.
*** Bug 54219 has been marked as a duplicate of this bug. ***
Dear Michael Pappas, thank you very much for your bug report! (In reply to comment #9) > It's puzzling to see that this bug has been not been assigned to someone > yet. Its impact is rather large, especially on organizations with a large > number of documents in Word format. I am sorry to say so, but please be patient. LibreOffice is a large project, and we have limited resources both in development and in QA, so we can’t process even important bugs as fast as we would like to do. To adumbrate the dimensions, let me quote some numbers: Right now, there are 3821 NEW/REOPENED/ASSIGNED bugs, i.e. bugs which are confirmed, but not yet fixed. Additionally, there are 1380 UNCONFIRMED bugs, waiting for confirmation and moderation by the QA team (which completely consists of volunteers like me). 645 bugs are in NEEDINFO status, i.e., we are waiting for the users to respond to necessary questions (they often don’t answer, or only after a long delay). But this does not mean that there is no progress. Not less than 7313 bugs are already RESOLVED/VERIFIED/CLOSED, i.e. have been fixed or processed completely. For a FLOSS project which consists of mere volunteers, this is IMHO an impressive result. By the way: these large numbers of bugs do not mean that LibreOffice is a buggy project with decreasing quality. Many (most?) of these bugs have been inherited from OpenOffice.org or even from StarOffice, and we have already fixed a good part of these old bugs, so that the quality of the software is increasing. But it is unavoidable that sometimes -- like in this case -- there are also new bugs introduced while implementing new or improving existing features. That’s a pitty, but it just happens in every complex software project. This is why I can just ask you (sorry again!): please be patient. > No offense here, I know that is a for-free collaborative project. Perhaps > there are other bugs related to this one, and work is being done for them > (ergo for this one as well)? Yes, that is true. It is very probable that the present bug is related or even identical to some other bug which is already worked on, and that therefore the fix of that other bug will fix the present issue, too. If I may add two additional hints: 1) This bug report is about a feature (merged table cells in .doc files?!) which worked in LibreOffice 3.5 but is broken in LibreOffic 3.6. Therefore it is what we call a “regression”. In cases like this, you can increase the likelihood that you report will get noticed early when you add the keyword “regression” (without the quotes) to the field “Keywords”. (But please do this only if you are sure that there is a regression!) 2) Our current workflow is (in most cases) as following: If you report a bug, it will first be reviewed by some QA volunteer(s), who checks for reproducibility, completeness, probable duplicates etc. Then the QA volunteer will CC some developer(s) who work in the area of the bug. As soon as one of these developers finds time, he will check the bug and, if he can handle it, assign it to himself, and fix it. This means that it is very important that a bug will catch the eyes of a QA volunteer, and that this “bug wrangler” (as we call it) can understand and reproduce the issue easily. Now the present bug has a general summary (“Formatting problems in Word … files”) which makes it look like a general report about unspecified (and many) problems. But general reports about many problems at once are very hard to handle (we need to identify the single issues first and then to separate them), and therefore bug reports which look like such general reports are not the favorite bug reports for us QA volunteers ;-) In short words: Your report is a good one, it is about a specific problem, and it is well documented with screenshots. The only problem is that the description of the specific problem comes at the end, and does not catch everybody’s eyes at once. So you can increase the likelihood that a bug report like this one will get reproduced soon if you give it a precise summary, something like “FORMATTING: Merged table cells from .doc file appear not merged in LibO (Regression)” or so. Thank you again!
REPRODUCIBLE with LibreOffice 3.6.2.2 (Build ID: da8c1e6), German langpack installed, on Mac OS X 10.6.8 (Intel). Table looks wrong like on reporter’s screenshot: * Cells in right column not merged * something very strange at the end of the right column: the last cell has no bottom border, looking “open”. This is really a regression, because on the same machine, LibreOffice 3.5.7.1 (Build-ID: 3fa2330-e49ffd2-90d118b-705e248-051e21c) opens the file correctly. Changed Platform to “All”, because not limited to Windows.
First, please let me say that I was overenjoyed to read such your comments; clarity and kindness especially striking to me! Thank you! (In reply to comment #13) > Dear Michael Pappas, > > thank you very much for your bug report! > > (In reply to comment #9) > > It's puzzling to see that this bug has been not been assigned to someone > > yet. Its impact is rather large, especially on organizations with a large > > number of documents in Word format. > > I am sorry to say so, but please be patient. LibreOffice is a large project, > and we have limited resources both in development and in QA, so we can’t > process even important bugs as fast as we would like to do. Fully understood, I've been employed in open source on and off for the last 12+ years. My comment above was more of a curious nature that is, how come there haven't been a ton of reports about this considering the (IMHO impact). > By the way: these large numbers of bugs do not mean that LibreOffice is a > buggy project with decreasing quality. More complexity brings more bugs and regressions. Trust me, I wouldn't deploy Libreoffice in my organization and I would neither evangelize use of it at hopes, if I *remotely* thought it was unfit for the purpose. > This is why I can just ask you (sorry again!): please be patient. No problem with that! > If I may add two additional hints: > > 1) This bug report is about a feature (merged table cells in .doc files?!) > which worked in LibreOffice 3.5 but is broken in LibreOffic 3.6. Therefore > it is what we call a “regression”. In cases like this, you can increase the > likelihood that you report will get noticed early when you add the keyword > “regression” (without the quotes) to the field “Keywords”. (But please do > this only if you are sure that there is a regression!) Will keep that in mind, thank you. > 2) Our current workflow is (in most cases) as following: > If you report a bug, it will first be reviewed by some QA volunteer(s), who > checks for reproducibility, completeness, probable duplicates etc. Then the > QA volunteer will CC some developer(s) who work in the area of the bug. As > soon as one of these developers finds time, he will check the bug and, if he > can handle it, assign it to himself, and fix it. Thanks again. What *I* can do is search around, find possible similarities, propose/close possible duplicates and basically do whatever it is needed to provide concentrated information for the developer in a *single* place. > In short words: Your report is a good one, it is about a specific problem, > and it is well documented with screenshots. The only problem is that the > description of the specific problem comes at the end, and does not catch > everybody’s eyes at once. So you can increase the likelihood that a bug > report like this one will get reproduced soon if you give it a precise > summary, something like “FORMATTING: Merged table cells from .doc file > appear not merged in LibO (Regression)” or so. > Thank you again! Thank YOU, for your kind words and time and effort for a non-profit project! :)
* Bug was already in LibreOffice 3.6.0.4 (Build ID: 932b512). → Adapted version (version field should contain the number of the FIRST version which is known to contain a bug). * Bug is still in master build: LOdev 3.7.0.0.alpha0+, build ID: 8baaff5, pull time: 2012-09-24 23:40:55 I propose a new (more precise) summary, adding some keywords; feel free to change.
* The bug was already in LOdev 3.6.0alpha0+ (Build ID: 2398b9c, pull time: 2012-05-24 00:07:5), so the regression was introduced before that date. However, I don’t have any older master builds anymore, so I can’t continue testing. What we now need is someone who bibisects the issue (I can’t do that because bibisection works only on Linux and, partially, Windows). @Michael Pappas: Thank you for your nice answer (comment #15)! > Thanks again. What *I* can do is search around, find possible similarities, > propose/close possible duplicates and basically do whatever it is needed to > provide concentrated information for the developer in a *single* place. Yes, I agree. -- We could CC the developers now about the bug, but first I want to try to find someone who can bibisect(*) the issue. When this succeeds, the developers will know more or less exactly which commit(s) have introduced the regression, and this will make the fix rather easy for them. I will ask on the QA list if somebody can take bibisecting ... (*) See https://wiki.documentfoundation.org/Bibisect
Comment on attachment 67754 [details] Case #2: original Word document (.DOC) Fix MIME type.
Comment on attachment 67755 [details] Case #2: Same file exported to OpenDocument Fix MIME type.
Bjoern's Bibisect's latest tag (Apr 28, 2012) still NOT reproducible. So I use downloaded daily builds instead. The result is: between 09008a2433cae77170de30bb5075f9280ff5086f (pull time 2012-05-02 13:14:13) and 32af02b32f1ab7f2683749e6c949470847175da0 (pull time 2012-05-06 12:21:22) http://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=09008a2433cae77170de30bb5075f9280ff5086f..32af02b32f1ab7f2683749e6c949470847175da0
@ Korrawit Pruegsanusak : Thank you very very much for bibisecting!
(In reply to comment #21) > Thank you very very much for bibisecting! Ehm, sorry, I mean: for searching and testing the daily builds!
@ Writer experts: hello Cédric, Michael, and Miklós, this bug report is about an interesting and annyoing regression in table import from .doc format; while LibO 3.5.x opens the document correctly, LibO 3.6.x damages the table. I know that there are more reports of this kind, this one is rather well-documented -- good sample file, screenshots, and even some research about the range of commits in which the regression was introduced (between 2012-05-02 13:14:13 and 2012-05-06 12:21:22; bibisecting was not possible). And I hope that from fixing this issue also many other documents will benefit ... So please take a look at this issue. Thank you very much!
Hello Caolan, Unfortunately, I've done further git bisect and found that your commit (that fixed bug 49342) introduced this problem: http://cgit.freedesktop.org/libreoffice/core/commit/?id=567c1db25bd705faac44203e4a3d01d0f5e1385c But what I don't understand is that, this commit also got into libreoffice-3-5 branch, but this bug doesn't appear in 3.5.7.1 (ref. comment 14). Please see: * http://nabble.documentfoundation.org/REVIEW-3-5-fdo-49342-crash-in-cell-merge-of-quot-old-school-quot-tables-td3963189.html * http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-3-5&id=217b62d6db67e102fb16cd15d80db790e2f3d331 Could you please have a look here? Thanks! :-)
(In reply to comment #24) > But what I don't understand is that, this commit also got into > libreoffice-3-5 branch, but this bug doesn't appear in 3.5.7.1 (ref. comment > 14). I have double-checked this and can confirm: the document opens correctly in 3.5.7.1, but incorrectly in 3.6.2.2, both installed in parallel.
(In reply to comment #25) > I have double-checked this and can confirm: the document opens correctly in > 3.5.7.1, but incorrectly in 3.6.2.2, both installed in parallel. Thanks Roman! :) I also checked on Windows XP. And because bug 49342 was fixed in 3.5.4, I checked the following official builds: * 3.5.3.2 * 3.5.4.2 * 3.5.5.3 * 3.5.7.1 All versions open correctly. But incorrectly in 3.6.2.2. Same result ;)
Does not persist on 3.5.6.2 (linux).
Reproducable with 3.6.6.2
The commit is not *exactly* the same on 3-5 and 3-6 because the code changed a bit, so the commit to revert the other breakage had to be adapted. Commit 567c1db25bd705faac44203e4a3d01d0f5e1385c was supposed to revert 858b5b4f36a357fe7192e7c2ed9cc3cdfc81fd8f but 858b5b4f36a357fe7192e7c2ed9cc3cdfc81fd8f added a ++n which 567c1db25bd705faac44203e4a3d01d0f5e1385c didn't.
which 567c1db25bd705faac44203e4a3d01d0f5e1385c didn't *remove* I mean. great bisecting Korrawit, the final hint is that it affected the .doc importer, and that's implemented in sw/source/filter/ww8 and only ww8par2.cxx is touched by that commit in that dir, so it jumps out on a side by side comparison of the broken master/3-6 vs the ok 3-5 of the affected WW8TabDesc::FinishSwTable method
Caolan McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=b966a09c2da9441961c93c44be556399575db849 Resolves: fdo#54862 extra ++n causing merged cells to be skipped 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 "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=55fe92fb396ebcfffe30831ebb460bfb3e6274aa&g=libreoffice-3-6 Resolves: fdo#54862 extra ++n causing merged cells to be skipped It will be available in LibreOffice 3.6.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.
@ Caolán: Thank you very much for fixing this issue! @ Korrawit Pruegsanusak: Thank you again for your important bibisecting! VERIFIED as FIXED with LOdev 3.7.0.0.alpha0+ (Build ID: dd11a1e; pull time: 2012-10-04 12:52:50) on Mac OS X 10.6.8 (Intel). The table, and therefore the complete 1-page document, looks correctly again, i.e. like in MS Office and LibO 3.5.x.
Thank YOU ALL, for having the rest of us happy with an awesome piece of software!
*** Bug 54259 has been marked as a duplicate of this bug. ***
Important for the record: The 1st version in which this bug is reproducible is 3.6.0.4. @ dE (and @ all): Please do not “update” the version field. The Version field should always contain the number of the FIRST version which is known to contain the bug, and NOT the last one; cf. http://wiki.documentfoundation.org/BugReport_Details#Version Thank you!
*** Bug 53334 has been marked as a duplicate of this bug. ***
*** Bug 49847 has been marked as a duplicate of this bug. ***
Adam Seskunas committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2bacf24d46350e451db444d72a88a3c407b419f3 tdf#54862 Add Unit test It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.