Bug 94135 - FILEOPEN: added 20 empty rows in .doc table (status in comment 14)
Summary: FILEOPEN: added 20 empty rows in .doc table (status in comment 14)
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: interoperability
Keywords: bibisected, filter:doc
Depends on:
Blocks: DOC-Frames DOC-Tables
  Show dependency treegraph
 
Reported: 2015-09-11 16:23 UTC by Christian Lohmaier
Modified: 2019-10-03 07:39 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
the sample document (66.50 KB, application/msword)
2015-09-11 16:23 UTC, Christian Lohmaier
Details
as it should look - exported with word viewer on windows (241.91 KB, application/pdf)
2015-09-11 16:26 UTC, Christian Lohmaier
Details
the somewhat-okish import prior to LO 4.1 (36.91 KB, application/pdf)
2015-09-11 16:27 UTC, Christian Lohmaier
Details
the bad, overlapping import since 4.1 (36.16 KB, application/pdf)
2015-09-11 16:28 UTC, Christian Lohmaier
Details
screenshot comparing the import results (the attached/exported PDFs) using evince (194.50 KB, image/png)
2015-09-11 16:30 UTC, Christian Lohmaier
Details
the sample document - text wrapping in table set to "None" in MSO (65.50 KB, application/vnd.ms-word)
2015-09-14 07:30 UTC, Timur
Details
the sample document compared in MSO and LO (118.41 KB, image/png)
2019-10-03 07:37 UTC, Timur
Details
the sample document resaved in MSO with enter before table (112.00 KB, application/msword)
2019-10-03 07:37 UTC, Timur
Details
the sample document resaved in MSO with enter before table (123.64 KB, image/png)
2019-10-03 07:38 UTC, Timur
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Lohmaier 2015-09-11 16:23:46 UTC
Created attachment 118608 [details]
the sample document

it's kind of a regression compared to LO 3.3.0, although formatting wasn't perfect in LO 3.3.0 either. But at least the first page doesn't have overlapping tables.

Much worse in LO 4.4 or LO 5.0 where the individual tables of the document are all overlapping on the first page of the document.

Even when not relying on Carlito (metric-equivalent to the Calibri font used in the document) as when trying on windows, the same formatting probelm occurs (so not related to different fontmetrics)

4.0.6.2 (i.e. 4.0.6 final) has the halfway-OK rendering, while
4.1.0.0.beta1 already has the completely messed-up rendering

So regression introduced between 4.0 and 4.1 codeline.

Bibisect result (starting with last41onmaster and last40onmaster of the 42all repo)

$ git bisect log
git bisect start
# bad: [315d45609b25edb26f80e4164c6bc9c948143bfc] source-hash-f160e4935c474a5293b3d3c11b3d538efb4767a0
git bisect bad 315d45609b25edb26f80e4164c6bc9c948143bfc
# good: [eb01a04acbb7373331312a2ee3d9d90d20548fca] source-hash-ce90f99a2d66c2b998ad3f9f028e2ea623a757f5
git bisect good eb01a04acbb7373331312a2ee3d9d90d20548fca
# good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932
git bisect good 65fd30f5cb4cdd37995a33420ed8273c0a29bf00
# good: [ace4dfc87d82ad4b9cb49c168cff587c0204adaa] source-hash-20d4cd5e08c1400fcc5ae5eb45861f429b914969
git bisect good ace4dfc87d82ad4b9cb49c168cff587c0204adaa
# good: [f62189a524a3b90b7325ac9d363a31ea4000923f] source-hash-f6b4d0313dbaf1089254a1bfae9ccfbc3f413eb3
git bisect good f62189a524a3b90b7325ac9d363a31ea4000923f
# good: [81e344d05dcb87f620a3e207e8707ee55da6a60b] source-hash-66a63c1608cfd5e755fb141b636e4a84c118179a
git bisect good 81e344d05dcb87f620a3e207e8707ee55da6a60b
# bad: [3424f6f8a0e53bba75da67c3b2a83e385884f94c] source-hash-fe46fc0f27ad5dac188517ff3f76bb1604aeeac1
git bisect bad 3424f6f8a0e53bba75da67c3b2a83e385884f94c
# good: [e49c08bb9dd94d979ea4a4f37745a56b0e99078b] source-hash-001da6553adfcb160a08225fdd6aea478bd7dea9
git bisect good e49c08bb9dd94d979ea4a4f37745a56b0e99078b
# bad: [f3d59858f60b320f7351e560b3b72ade8a5657ac] source-hash-86fd1240bbbb8ee72899abc24daf5e4402a61add
git bisect bad f3d59858f60b320f7351e560b3b72ade8a5657ac
# good: [aedcb9e93c73792e6d4f6bc5d74050efbe5af7c1] source-hash-358b60b3b172968a7605b428af01df456d7669b2
git bisect good aedcb9e93c73792e6d4f6bc5d74050efbe5af7c1
# bad: [d0234a72b2d4d1c6e1a54d5afb64fbd17df10cc2] source-hash-d74ba0c4147f33abd9d0c03883cc88f15e160ee5
git bisect bad d0234a72b2d4d1c6e1a54d5afb64fbd17df10cc2
# good: [7be68a718d3dbd2254fe62c0af8b4f0b5d602e4b] source-hash-bd7b2c7befbd10bebaba3a9b6ea491969ac1dcb0
git bisect good 7be68a718d3dbd2254fe62c0af8b4f0b5d602e4b
# first bad commit: [d0234a72b2d4d1c6e1a54d5afb64fbd17df10cc2] source-hash-d74ba0c4147f33abd9d0c03883cc88f15e160ee5


(note: last good (7be68 - source-hash-bd7b2c7befbd10bebaba3a9b6ea491969ac1dcb0 ) has bug that requires creating symlinks for libreg, libjvmfwk, libstore and libjvmaccess for LO to run (link the .so to .so.3 for each)

256 possible commits to blame.
$ git log --oneline bd7b2c7befb..d74ba0c41 |wc -l
256
Comment 1 Christian Lohmaier 2015-09-11 16:26:22 UTC
Created attachment 118609 [details]
as it should look - exported with word viewer on windows
Comment 2 Christian Lohmaier 2015-09-11 16:27:34 UTC
Created attachment 118610 [details]
the somewhat-okish import prior to LO 4.1

note that the text next to the frame at the top-right moves the table down (adding newlines above the table in current Version of LO also reduces the overlap effect)
Comment 3 Christian Lohmaier 2015-09-11 16:28:29 UTC
Created attachment 118611 [details]
the bad, overlapping import since 4.1
Comment 4 Christian Lohmaier 2015-09-11 16:30:18 UTC
Created attachment 118612 [details]
screenshot comparing the import results (the attached/exported PDFs) using evince
Comment 5 Timur 2015-09-11 16:59:12 UTC Comment hidden (obsolete)
Comment 6 Cor Nouws 2015-09-11 20:27:49 UTC
(In reply to Timur from comment #5)
> Not a regression, as you said, never worked fine. 
> Looks like a duplicate of Bug 78756. If you agree, please mark as such.
> Please also take a look at Bug 53816.

I don't see Wrap around, nor a row that breaks over a page-break in the bug file.
So ...

However I do see four tables and four frames.
Possibly floating tables in Word and imported as tables within a frame and wrapping-disaster..
Comment 7 Timur 2015-09-14 07:30:34 UTC
Created attachment 118690 [details]
the sample document - text wrapping in table set to "None" in MSO

(In reply to Cor Nouws from comment #6)
> (In reply to Timur from comment #5)
> > Looks like a duplicate of Bug 78756. If you agree, please mark as such.
> 
> I don't see Wrap around, nor a row that breaks over a page-break in the bug
> file.
> However I do see four tables and four frames.
> Possibly floating tables in Word and imported as tables within a frame and
> wrapping-disaster..
The same sample document with text wrapping in table set to "None" in MSO opens fine in LO. So, to me looks related or a duplicate of Bug 78756 or Bug 61594.
Comment 8 Cor Nouws 2016-09-20 17:22:51 UTC Comment hidden (no-value)
Comment 9 Timur 2017-09-13 15:30:17 UTC
No wrapping with libo-master~2017-09-12_23.06.27_LibreOfficeDev_6.0.0.0.alpha0_Win_x86. I guess due to Mike's Bug 112346. 
But document is again wrong on it's own. And it also has many additional empty pages that's probably another regression.
Comment 10 Xisco Faulí 2017-09-14 10:25:00 UTC
(In reply to Timur from comment #9)
> No wrapping with
> libo-master~2017-09-12_23.06.27_LibreOfficeDev_6.0.0.0.alpha0_Win_x86. I
> guess due to Mike's Bug 112346. 
> But document is again wrong on it's own. And it also has many additional
> empty pages that's probably another regression.

Since this bug is about the wrapping, should it be closed and a follow-up bug be created?
Comment 11 Timur 2017-09-14 10:56:23 UTC
I didn't do it because there's nothing done here, and I wouldn't do it until we are clear what this mess is related to and where empty pages are coming from.
Comment 12 Timur 2017-09-15 13:36:14 UTC
Created attachment 136265 [details]
Artikelliste exported as PDF in master 6.0+ has 9 pages

Artikelliste - Attachment 118608 [details] from Bug 94135 as seen and exported as PDF in master 6.0+ has 9 pages. Shown at attachment 136265 [details]. Not Export blank pages dependant.
master~2017-09-15_05.47.07_LibreOfficeDev_6.0.0.0.alpha0_Win_x86
Comment 13 QA Administrators 2018-10-02 02:52:19 UTC Comment hidden (obsolete)
Comment 14 Timur 2018-10-02 08:33:44 UTC
Empty pages is fixed. In LO 6.2+ we have 3 pages instead of MSO 2. 
We are back to wrong import of tables, similar to "prior to 4.1" (with some other small improvements). So I remove "regression" and add "inherited".
Reason are additional empty table rows after "Hier ist Schluss bei Modebasar" (between numbers 30 and 31). 
This bug was renamed to "covering/overlapping" but it's not the case anymore so I rename it again to "FILEOPEN: added 20 empty rows in .doc table".

Calibri fontmetrics is not in the scope of this bug, as Christian wrote.

Another issue is with reduced table width, but that's regression from LO 6.0. I'll report separately.
Comment 15 QA Administrators 2019-10-03 03:00:52 UTC Comment hidden (obsolete)
Comment 16 Timur 2019-10-03 07:37:10 UTC
Created attachment 154719 [details]
the sample document compared in MSO and LO

Again change. 
Now in 6.4+ there's no empty rows. 

First page table is of wrong width but I guess that's related to bug 120262.
Comment 17 Timur 2019-10-03 07:37:56 UTC
Created attachment 154720 [details]
the sample document resaved in MSO with enter before table
Comment 18 Timur 2019-10-03 07:38:53 UTC
Created attachment 154721 [details]
the sample document resaved in MSO with enter before table

The sample document resaved in MSO with enter before table opens fine in LO.
I'll close this one as WFM. 
We still have bug 120262.