Bug 123337 - LO Writer opens .doc files containing section breaks wrong.
Summary: LO Writer opens .doc files containing section breaks wrong.
Status: RESOLVED DUPLICATE of bug 87764
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.2 all versions
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, filter:doc, regression
Depends on:
Blocks: DOC-Paragraph
  Show dependency treegraph
 
Reported: 2019-02-11 11:10 UTC by jogszaby
Modified: 2019-11-05 12:19 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
example .doc file (44.00 KB, application/msword)
2019-02-11 12:17 UTC, jogszaby
Details
example image file (50.18 KB, image/png)
2019-02-12 07:06 UTC, jogszaby
Details

Note You need to log in before you can comment on or make changes to this bug.
Description jogszaby 2019-02-11 11:10:46 UTC
Description:
I often have to open .doc files made by various versions of MS Word. In many of these documents are applied section brakes, right on the top of the first page, below the header. No I am using LO Writer 6.0.4.2 but newer versions like 6.1.5 and 6.2.0 do the same. The problem is, that the LO Writer handles and displays these section breaks like page breaks. 

Steps to Reproduce:
1. Open the .doc file containing section breaks made by MS Word.
2.
3.

Actual Results:
The section brakes are displaying like page breaks.

Expected Results:
Not displaying section breakes like page breaks. :)


Reproducible: Always


User Profile Reset: No



Additional Info:
Comment 1 Xisco Faulí 2019-02-11 11:20:47 UTC
Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. 
(Please note that the attachment will be public, remove any sensitive information before attaching it. 
See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.)

I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided.
Comment 2 jogszaby 2019-02-11 12:17:40 UTC
Created attachment 149117 [details]
example .doc file
Comment 3 jogszaby 2019-02-12 07:06:50 UTC
Created attachment 149177 [details]
example image file

This image shows the right way the document should be displayed.
Comment 4 Roman Kuznetsov 2019-03-15 19:47:53 UTC
confirm wrong layout in example.doc in

Version: 6.3.0.0.alpha0+ (x64)
Build ID: 13a260f59e421f3e67845f8f2eb22b8f0f8fcaf0
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-03-11_02:46:09
Locale: ru-RU (ru_RU); UI-Language: en-US
Calc: threaded
Comment 5 Xisco Faulí 2019-03-22 15:00:39 UTC
Reproduced in

Version: 5.2.0.0.alpha0+
Build ID: 3ca42d8d51174010d5e8a32b96e9b4c0b3730a53
Threads 4; Ver: 4.15; Render: default; 

but not in

Version: 4.3.0.0.alpha1+
Build ID: c15927f20d4727c3b8de68497b6949e72f9e6e9e
Comment 6 raal 2019-04-20 08:38:59 UTC
This seems to have begun at the below commit.
Adding Cc: to Luboš Luňák ; Could you possibly take a look at this one?
Thanks
 2eb63500efafca6bacf547876546d1bdba451590 is the first bad commit
commit 2eb63500efafca6bacf547876546d1bdba451590
Author: Matthew Francis <mjay.francis@gmail.com>
Date:   Sat Mar 14 23:33:59 2015 +0800

    source-hash-c5ed52b1cd6f22787c94bec035ceecf9e1da3271
    
    commit c5ed52b1cd6f22787c94bec035ceecf9e1da3271
    Author:     Luboš Luňák <l.lunak@collabora.com>
    AuthorDate: Mon Jul 21 10:56:52 2014 +0200
    Commit:     Luboš Luňák <l.lunak@collabora.com>
    CommitDate: Mon Jul 21 11:02:04 2014 +0200
    
        ww8import create a pagedesc if continuous section changes margins (bnc#875383)
    
        This is similar to what writerfilter does. MSWord can have one page with several
        different margins, which are saved using continuous sections, which causes all
        kinds of trouble, because either we treat them as Writer sections, which means
        we lose some of the data, or we treat them as Writer page styles, which causes
        spurious page breaks if in the wrong place. Either option has its problems, but
        here it seems slightly better to go for keeping the data and hoping the page
        break will be in a place where a break will be anyway.
    
        Change-Id: I8f52aa820750da6788ea04180a15ac334f6bf87b
Comment 7 Xisco Faulí 2019-11-05 12:19:02 UTC
Closing as a dupe of bug 87764

*** This bug has been marked as a duplicate of bug 87764 ***