Bug 79553 - FILEOPEN: Incorrect spacing between numbers and lines when opening a .doc file
Summary: FILEOPEN: Incorrect spacing between numbers and lines when opening a .doc file
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: Other All
: medium normal
Assignee: Justin L
URL:
Whiteboard: BSA target:7.0.0
Keywords:
: 79738 (view as bug list)
Depends on:
Blocks: DOC
  Show dependency treegraph
 
Reported: 2014-06-02 14:10 UTC by Frederic Parrenin
Modified: 2021-04-07 17:01 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
.doc file to reproduce the problem (75.50 KB, application/msword)
2014-06-02 14:10 UTC, Frederic Parrenin
Details
how the page looks in LibO 4.3 beta VS Word 2010 (209.91 KB, image/png)
2014-06-06 18:31 UTC, Yousuf Philips (jay) (retired)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Frederic Parrenin 2014-06-02 14:10:04 UTC
Created attachment 100315 [details]
.doc file to reproduce the problem

Problem description: 

Steps to reproduce:
1. open the attached .doc file in word
2. => there is a spacing between lines and numbers
3. open the same .doc file in LO
4. => there is no spacing between lines and numbers

Current behavior: no spacing between lines and numbers

Expected behavior: same spacing between lines and numbers than in word

              
Operating System: All
Version: 4.2.4.2 release
Comment 1 Yousuf Philips (jay) (retired) 2014-06-06 18:31:26 UTC
Created attachment 100526 [details]
how the page looks in LibO 4.3 beta VS Word 2010
Comment 2 Yousuf Philips (jay) (retired) 2014-06-06 18:39:54 UTC
Confirmed in Linux Mint in 3.3.0, 4.2.4 and 4.3 beta.
Comment 3 QA Administrators 2015-06-08 14:42:05 UTC Comment hidden (obsolete)
Comment 4 Frederic Parrenin 2015-06-18 02:02:45 UTC
This bug is still present on 4.4.4.2 on ubuntu 14.04.
Comment 5 Frederic Parrenin 2015-08-07 22:31:48 UTC
This bug is still present on 5.0.0.5.
Comment 6 Xisco Faulí 2016-08-11 16:11:13 UTC
This issue is still reproducible with

Version: 5.2.0.4
Build ID: 066b007f5ebcc236395c7d282ba488bca6720265
CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; 
Locale: es-ES (es_ES)

Change version back to 'Inherit from OOo'
Comment 7 QA Administrators 2017-12-10 16:44:11 UTC Comment hidden (obsolete)
Comment 8 Frederic Parrenin 2017-12-10 17:00:37 UTC
This bug is still present in 5.4.2.
Comment 9 QA Administrators 2018-12-11 03:43:59 UTC Comment hidden (obsolete)
Comment 10 Frederic Parrenin 2018-12-13 13:52:59 UTC
This bug is still present in 6.1.3.
Comment 11 Justin L 2020-04-13 17:30:04 UTC
The key here is that a zero indicates automatic position, not zero distance.

sprmSDxaLnn
An XAS_nonNeg that specifies the distance between line numbers and
the lines of text to which they apply. A value of 0 indicates that the
application MUST automatically determine positioning.
By default, the positioning of line numbers is automatically determined.

proposed fix at https://gerrit.libreoffice.org/c/core/+/92126
Comment 12 Commit Notification 2020-04-17 15:40:37 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/803b49a3776c98e2d435c328d39d0f71d259d9e5

tdf#79553 ww8import: line numbering distance is auto, not zero

It will be available in 7.0.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.
Comment 13 BogdanB 2020-05-10 13:46:10 UTC
Nice job!

Verified on
Version: 7.0.0.0.alpha1
Build ID: 6a03b2a54143a9bc0c6d4c7f1...
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3; 
Locale: ro-RO (ro_RO.UTF-8); UI: en-US
Calc: threaded
Comment 14 Justin L 2021-04-07 17:01:57 UTC
*** Bug 79738 has been marked as a duplicate of this bug. ***