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
Created attachment 118609 [details] as it should look - exported with word viewer on windows
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)
Created attachment 118611 [details] the bad, overlapping import since 4.1
Created attachment 118612 [details] screenshot comparing the import results (the attached/exported PDFs) using evince
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.
(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..
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.
there must be more issues with frames overlapping..
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.
(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?
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.
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
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
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.
Dear Christian Lohmaier, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
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.
Created attachment 154720 [details] the sample document resaved in MSO with enter before table
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.