Created attachment 75860 [details] The document in question Problem description: Text in imported .doc file does not render correctly. The document is public, freely obtainable at: [url]http://www.europass.si/europass_zivljenjepis.aspx[/url], direct link: [url]http://www.europass.si/files/userfiles/europass/dokumenti/Europass%20CV%20nov.doc[/url], also attached. Steps to reproduce: 1. Open attached .doc file 2. Se how text renders 3. .... Current behavior: The first table at the top of page 2 (table 10) does not render text correctly. Tested with release editions 4.0.0.3 (sl) and 3.6.5.2(en), each installed on separate PCs, both PCs are Windows 7 SP1 64bit. MS Office 2007 SP3 renders correctly. Expected behavior: Text should always render correctly Operating System: Windows 7 Version: 4.0.0.3 release
Created attachment 75862 [details] Screenshot of how LO-3.6.5.2 renders
Created attachment 75863 [details] Screenshot of how LO-4.0.0.3 renders
Created attachment 75864 [details] Screenshot of how Word 2007 renders
Created attachment 75866 [details] Screenshot of how Word 2007 renders Sorry, previous screenshot was attached as text.
I can confirm this behavior using Mac OSX 10.8.2 and LibreOffice Version 4.1.0.0.alpha0+ (Build ID: 5fcb553c862d407aadb0320925723d3c2f70bfe) TinderBox: MacOSX-Intel@1-built_no-moz_on_10.6.8, Branch:master, Time: 2013-02-26_22:56:53 I compare it using Word for Mac 2011 (see attached pdf's and screenshot which shows the erroneous rendering). It seems like the last rule of the first page is forced to be placed on the second page which result in 2 sentences on top of each other. Kind regards, Joren
@Bug reporter: the LibreOffice version of this bug report is the oldest version you can reproduce this behavior. Therefore I mark this as a bug of LibreOffice 3.6.5.2 because this is for now the oldest reproducible version. Kind regards, Joren
(In reply to comment #6) I agree. Note however, that I did not test in older versions simply because I have none older installed on my machines. Can anybody confirm this with older versions?
Already reproducible using LibreOffice 3.5.7.2 Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b (Mac OSX 10.8.2). This behavior is probably inherit from AOO.
Tested in OpenOffice.org 3.2.0 Portable (from portableapps.com), confirmed with same result. This confirms the issue to be inherited from OOo. As it is also confirmed in LibreOffice 4.1.0.0.alpha0+, it makes it relevant for all versions of LibreOffice.
A few tests, using Libreoffice 3.6.5.2 (Build ID: 5b93205) and MS Office 2007 SP3, Windows 7 SP1 64bit: - convert the document to .docx using MS Office, then open in LibreOffice - text in question is rendered correctly, but header on page 2 is missing (some other bug?) - convert the document to .docx using LibreOffice - LibreOffice crashes - convert the document to .odt using Libreoffice - incorrect rendering persists - open .odt document in MS Office - the document is opened correctly! (it does show error popups when opening .odt) Now, how come MS Office displays the .odt correctly but LibreOffice does not?
Created attachment 75959 [details] The document converted to .docx and .odt
(In reply to comment #10) > - convert the document to .docx using LibreOffice - LibreOffice crashes Thanks. Because this is another issue, I filed a new bug. Please see 61864. > - convert the document to .odt using Libreoffice - incorrect rendering > persists > - open .odt document in MS Office - the document is opened correctly! (it > does show error popups when opening .odt) > > Now, how come MS Office displays the .odt correctly but LibreOffice does not? @Michael: any thoughts?
@Jorendc: Thank you for filing the new bug. I see it is confirmed. Can I assume that you can also confirm other points in comment #10?
Comment on attachment 75864 [details] Screenshot of how Word 2007 renders Mimetype fixed
popins: On pc Debian x86-64 with master sources updated today, I reproduce the behaviour indicated in your initial description. About comment 10, it's too difficult to manage several bugs in 1 bugtracker so please create separate bugtrackers. Michael/Cédric: one for you?
Further tests using LibreOffice 3.6.5.2 (Build ID: 5b93205) and MS Office 2007 SP3, Windows 7 SP1 64bit: Test 1: Add paragraph between section break and table 1. Open the original file in MS Office 2. Add a Paragraph Break after the Section Break. Actually, you should add some Paragraph Breaks after the first table on page 2 and than move the table to anchor so that there is a paragraph break is between section break and the table. 3. Save the file (as .doc) 4. Open the file in LibreOffice The file now seems to open correctly. You can save it as .odt or .doc, while save as .docx still crashes. Test 2: Remove section break 1. Open the original file in MS Office 2. Remove (delete) section break 3. Save the file (as .doc) 4. Open the file in LibreOffice The file now seems to open correctly. You can save it as .odt, .doc or .docx, it will not crash. However, .docx is unusable: most content and formatting is lost. @Julien Nabet: I would love to create separate bugs, but it seems that every test I do converges to section break handling. Perhaps we should rename this bug? If you feel we should split this one into multiple more 'to the point' bugs I'd need some advice on which part of my findings is a new bug. Thank you.
popins: I don't know at all if there's a link between these buggy behaviours and so it(s better. So I let Writer experts who certainly know the answer :-)
Filed a bug regarding testcase 2 in comment 16 - see Bug 62126
(In reply to comment #17) Well, I hope somebody will definitely take a look. This one seems an interesting file, a real bug-catcher. That Section Break behaves buggy in MS Office too due to lack of Paragraph Breaks around it, but MS Office handles it and lets you work around it.
Caolán: I think you might be interested in this rendering issue.
Restricted my LibreOffice hacking area
Hi Popins, I retested this bug and the initial complaint is no longer happening (top of page 2 is shown as expected) in LO Version: 5.0.0.0.alpha1+ Build ID: 3a96d8ead86dc210085f09076fd270f247442f0a TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2015-04-26_02:00:38 Locale: de_ Attaching screenshot of fixed issue. If the original issue persists for you, please re-open this bug. There are various other bugs with the specific test file. But since only one issue per bug can be filed, I suggest filing separate bugs for the remaining issues and connecting them via the "see also:" field.
Created attachment 115109 [details] initial bug resolved