Bug 83309 - FILEOPEN: NUMBERING: text paragraph indentation/tab stops in .DOCX displayed incorrectly with tab
Summary: FILEOPEN: NUMBERING: text paragraph indentation/tab stops in .DOCX displayed ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.6.0.4 release
Hardware: Other All
: highest minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, filter:docx, regression
Depends on:
Blocks: DOCX-Bullet-Number-Lists
  Show dependency treegraph
 
Reported: 2014-08-31 19:17 UTC by Konstantin Svist
Modified: 2018-11-29 08:40 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
incorrectly rendered file (109.73 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2014-08-31 19:17 UTC, Konstantin Svist
Details
google docs rendering (34.08 KB, application/pdf)
2014-09-03 15:28 UTC, Konstantin Svist
Details
Comparison of PDF vs LO, lots of filter problems for sure. (256.08 KB, image/png)
2015-01-13 17:18 UTC, Dave Richards
Details
Screenshot from 4.5 master (60.91 KB, image/png)
2015-01-14 04:42 UTC, Matthew Francis
Details
PDF generated from Office for Mac 2011 (35.34 KB, application/pdf)
2015-01-14 05:16 UTC, Matthew Francis
Details
Screenshot from Office for Mac 2011 (447.96 KB, image/png)
2015-01-14 05:18 UTC, Matthew Francis
Details
incorrectly rendered file compared in MSO and LO (164.85 KB, image/jpeg)
2016-07-29 07:55 UTC, Timur
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Konstantin Svist 2014-08-31 19:17:27 UTC
Created attachment 105501 [details]
incorrectly rendered file

Fedora 20
Build ID: 4.2.6.2-1.fc20

Document renders incorrectly (running off to next line, showing some strange rectangles); looks much better in google docs
Comment 1 Joel Madero 2014-09-03 08:24:54 UTC
Please provide a pdf of what it should look like (ie. from MS Office). Marking as NEEDINFO.

FWIW this bug report isn't very actionable. I'll confirm it if you provide a pdf but saying "make this document look right" isn't nearly as good as identifying and reporting SEPARATELY every particular problem you see. Also the title of the bug isn't very informative - so if you want to help a bit you can report separate bugs with clear titles that are particular to a single issue. 

Else you can just provide the pdf and I'll mark as NEW but developers are less inclined to just take a bug report that's "this file looks wrong." 

Marking as NEEDINFO - once you provide a pdf please set to UNCONFIRMED. Thanks
Comment 2 Konstantin Svist 2014-09-03 15:28:58 UTC
Created attachment 105696 [details]
google docs rendering

I don't have MS Office, here's google docs rendering (looks a lot more reasonable)
Comment 3 Buovjaga 2014-11-27 07:21:05 UTC
The font rendering seems to take more space in LibO.
The date field doesn't display the time.
I don't see any strange rectangles, though.

Set to NEW and tweaked severity per https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg

Win 7 64-bit Version: 4.5.0.0.alpha0+
Build ID: b144f0ac8695dd62a2053b4e88212d0b109c9a41
TinderBox: Win-x86@51-TDF, Branch:MASTER, Time: 2014-11-25_00:14:54
Comment 4 Buovjaga 2015-01-10 18:31:31 UTC
3.3.0 looks quite ok, the date field only displays time. 3.5.0 has an extra blank page after pg 1 and the date field displays the date only.

I guess someone could do a bibisect and see, when this runs to a second line (bad):
Participant Name/Belt Size(Print)            Parent/Guardian Signature 

So I'll mark this as a regression and request a bibisect.  

Ubuntu 14.10 64-bit
LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-3.3.0.4

LibreOffice 3.5.0rc3 
Build ID: 7e68ba2-a744ebf-1f241b7-c506db1-7d53735
Comment 5 Dave Richards 2015-01-13 17:18:31 UTC
Created attachment 112174 [details]
Comparison of PDF vs LO, lots of filter problems for sure.
Comment 6 Dave Richards 2015-01-13 17:29:44 UTC
What I am seeing is that something in the front of each line is being viewed as a tab stop which is bumping the text out into the tab position.  Older versions of LO seem to handle this document better.  Newer versions of LO seem to get worse and worse in regards to this specific document.  I am closing in on a bibisect.
Comment 7 Dave Richards 2015-01-13 17:32:26 UTC
13312242b4c33dfbbf82238d6e47bbefdaf22f32 is the first bad commit
commit 13312242b4c33dfbbf82238d6e47bbefdaf22f32
Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
Date:   Wed May 2 19:15:24 2012 +0200

    source-hash-33f5acad371bcf838011b3629450e6dcd405a4e9
    
    commit 33f5acad371bcf838011b3629450e6dcd405a4e9
    Author:     Jesús Corrius <jesus@softcatala.org>
    AuthorDate: Wed Apr 25 17:46:26 2012 +0200
    Commit:     Jesús Corrius <jesus@softcatala.org>
    CommitDate: Wed Apr 25 17:46:26 2012 +0200
    
        Remove blank space introduced in previous patch

:100644 100644 660cb56bf1c16bfd2cabae508e0d417af16ee735 4b364d22d5fdd945ff74a38b14b10507b6cc7bef M	ccache.log
:100644 100644 66eeda0541e4612f2c10b5589373632d18282168 c8fa6358af0799d993b059b1bcddb303235dd53c M	commitmsg
:100644 100644 444e480fc8394f56fdfae6917f0661407b0247b8 2b0ae781a4dfeaa9676195700c004b78fb4717d6 M	dev-install.log
:100644 100644 9328f48a3231d91f50da06112b6a3abc05587f52 88f62105dad7c2c7c1603c19e3f5645273271293 M	make.log
:040000 040000 8a8d95fd0367932826c728a26fec3c639782548a 71e9fb5a6916a6eacd5d42ba99d35f21bea2a69e M	opt
:100644 100644 fae9744eac2d90d2474d2491a5475d1ab5a74ecf 5918afbd72326bd1187716203ebdb3f2a36639c6 M	patch.log

# bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e
# good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932
git bisect start 'latest' 'oldest'
# bad: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb
git bisect bad e02439a3d6297a1f5334fa558ddec5ef4212c574
# bad: [8f4aeaad2f65d656328a451154142bb82efa4327] source-hash-1885266f274575327cdeee9852945a3e91f32f15
git bisect bad 8f4aeaad2f65d656328a451154142bb82efa4327
# good: [369369915d3582924b3d01c9b01167268ed38f3b] source-hash-45295f3cdceb4c289553791071b5d7f4962d2ec4
git bisect good 369369915d3582924b3d01c9b01167268ed38f3b
# bad: [6fce03a944bf50e90cd31e2d559fe8705ccc993e] source-hash-47e4a33a6405eb1b5186027f55bd9cb99b0c1fe7
git bisect bad 6fce03a944bf50e90cd31e2d559fe8705ccc993e
# bad: [8a39227e344637eb7154a10ac825d211e64d584c] source-hash-f5080ebb7022c9f5d7d7fdca4fe9d19f9bb8cabf
git bisect bad 8a39227e344637eb7154a10ac825d211e64d584c
# good: [e8bc60acad752e284db73fc4d8ad383ac055361c] source-hash-7e6e16ba6de2d3ef2b130d1ad5ffeabfdb37918e
git bisect good e8bc60acad752e284db73fc4d8ad383ac055361c
# good: [e1ec404400a4c6531a5d49d89631d1acc599071d] source-hash-5708f2bfa70db0479ddbf9b454329cd81e0f509d
git bisect good e1ec404400a4c6531a5d49d89631d1acc599071d
# bad: [09b0c68ed3c0cb7a96ac98146a67e9540df994c8] source-hash-d50f02bec4a70bd26a518e4e76f4a876454ab937
git bisect bad 09b0c68ed3c0cb7a96ac98146a67e9540df994c8
# bad: [a0225eee14bbecc662d5e82894b0f7738c75ff23] source-hash-1aa91a2d8e7db5cebff5b47f3005f1acff64d25e
git bisect bad a0225eee14bbecc662d5e82894b0f7738c75ff23
# bad: [13312242b4c33dfbbf82238d6e47bbefdaf22f32] source-hash-33f5acad371bcf838011b3629450e6dcd405a4e9
git bisect bad 13312242b4c33dfbbf82238d6e47bbefdaf22f32
Comment 8 Matthew Francis 2015-01-14 04:42:55 UTC
Created attachment 112194 [details]
Screenshot from 4.5 master

Unfortunately this is in one of those mysterious ranges that don't work for me at all - either in bibisect or built from source.

However, I also don't see the random start-of-line characters in current 4.5 (see attached screenshot)

If there's any problem left here it's possibly the indentation, but we'd need a rendering from Office to compare to in order to determine that.
Comment 9 Matthew Francis 2015-01-14 05:16:23 UTC Comment hidden (obsolete)
Comment 10 Matthew Francis 2015-01-14 05:18:14 UTC
Created attachment 112196 [details]
Screenshot from Office for Mac 2011

There's also some funky on-screen formatting that LO seems to know nothing about

(this is from a Chinese edition of Office, so there is some localised Chinese text that's irrelevant to the actual document)
Comment 11 Timur 2015-01-19 17:26:40 UTC
(In reply to Beluga from comment #3)
> Set to NEW and tweaked severity 
Please do not confirm reports with multiple problems such as "file displayed incorrectly". Each problem should be reported separately.
I suggest this bug be only for indentation/tab stops (with title updated) and other problems searched and reported separately.

(In reply to Dave Richards from comment #6)
> What I am seeing is that something in the front of each line is being viewed
> as a tab stop which is bumping the text out into the tab position.  Older
> versions of LO seem to handle this document better.  Newer versions of LO
> seem to get worse and worse in regards to this specific document.  I am
> closing in on a bibisect.
Since 3.5.7.2 handles this document better, I'll change Version to 3.6.0.4 because tab stops started there.
Comment 12 Matthew Francis 2015-01-25 12:44:37 UTC
(Better luck building this on the second try)
A follow up source bisect revealed the following. After commit a9e16b168c7eb046c62d6d7d2669bdea944da279, the text paragraph indentation was wrong, and there were unwanted bullet points on each paragraph. Commit 71e1927c78e3873c377d87feb64b33286138756b later fixed the problem with the bullet points, but the issue with the indentation remains.

Adding Cc: to l.lunak@collabora.com; Any chance you could take a look at this? Thanks


commit a9e16b168c7eb046c62d6d7d2669bdea944da279
Author: Luboš Luňák <l.lunak@suse.cz>
Date:   Fri Apr 6 18:48:54 2012 +0200

    don't use properties that aren't valid for paragraphs (part of bnc#751028)


commit 71e1927c78e3873c377d87feb64b33286138756b
Author: Adam Co <rattles2013@gmail.com>
Date:   Wed Jul 10 19:12:45 2013 +0300

    fdo#66781 : fix bullets with level 0
    
    Conflicts:
        sw/qa/extras/ooxmlexport/ooxmlexport.cxx
    
    Change-Id: I14b0ce9ae096eae4759793a49865eefe16ec1afd
    Reviewed-on: https://gerrit.libreoffice.org/4818
Comment 13 Stephan Aßmus 2015-07-16 08:03:35 UTC
I was testing the Apache POI based DOCX export of my own software against LibreOffice Writer 4.4.4.3. I thought I was doing something wrong with exporting global styles, since LibreOffice was not picking up indentation or tab-stops of global styles at all. I confirmed that I stored the indentation and tab-stop information exactly like LibreOffice itself is storing this information in word/styles.xml when exporting to DOCX (OOXML).

Then I discovered, that LibreOffice Writer *itself* does not restore the indentation and tab-stops from global styles in documents that it has exported itself!

To reproduce:

1) In a fresh document in LibreOffice Writer, create a custom root style, not based on any other style.

2) Open format templates, edit this custom style and define an indentation (first, left, right). Define some tab-stops.

3) Observe that a paragraph set to this style in the text shows the expected indentation and tab-stop positions.

4) Export as .docx and close the document.

5) Re-open/import the file exported in step 4.

6) Observe that the indentation and tab-stop information is not restored on the global style. Notice that the text formatted with this style is now formatted differently (with default indentation and tab-stops).
Comment 14 Robinson Tryon (qubit) 2015-12-13 11:11:01 UTC Comment hidden (obsolete)
Comment 15 Timur 2016-07-29 07:55:49 UTC
Created attachment 126461 [details]
incorrectly rendered file compared in MSO and LO
Comment 16 QA Administrators 2018-06-26 02:42:37 UTC Comment hidden (obsolete)
Comment 17 Timur 2018-06-26 08:09:09 UTC
Repro in 6.2+.
Comment 18 Justin L 2018-07-25 09:47:34 UTC
This interestingly designed document is using a style that has numbering enabled, but doesn't actually use numbering. LO doesn't emulate Word's numbering well.
Comment 19 Chen-Ku 2018-11-29 08:40:02 UTC
Still exists in version:
Version: 6.3.0.0.alpha0+ (x64)
Build ID: 0f25a3c36f27fd51453b9a9115f236b83c143684
CPU threads: 12; OS: Windows 10.0; UI render: GL; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-11-27_20:06:55
Locale: zh-TW (zh_TW); UI-Language: en-US
Calc: threaded