Bug 78227 - FILEOPEN: DOCX - Table size goes over right margin
Summary: FILEOPEN: DOCX - Table size goes over right margin
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.1.3.2 release
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: DOCX-Tables
  Show dependency treegraph
 
Reported: 2014-05-03 18:27 UTC by Yousuf Philips (jay) (retired)
Modified: 2017-09-29 18:47 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
shows how the table looks in LibO and word 2013 (32.00 KB, image/jpeg)
2014-05-03 18:27 UTC, Yousuf Philips (jay) (retired)
Details
Optimized DOCX file that reproduces problem (17.76 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2014-07-07 15:03 UTC, Adam CloudOn
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yousuf Philips (jay) (retired) 2014-05-03 18:27:05 UTC
Created attachment 98381 [details]
shows how the table looks in LibO and word 2013

I download the .docx file found at < http://download.microsoft.com/documents/uk/partner/publicsector/DraftMicrosoftResponsetoGovernment.docx > and opened it in LibO and the table on page 14 crosses over the page's right margin. This is a regression since 4.1 and was tested from 4.0 to 4.3. I'm running Linux Mint.
Comment 1 Cor Nouws 2014-05-03 20:36:00 UTC
Hi Jay,

I didn't check your finding, but see that you report using 4.1.5
There are 4 versions in the 4.2 version and one in the 4.3 that have improvements..
Would I think it makes sense to check in 4.2.4.1 and 4.3.0alplha1 too... (or is the listed version wrong ;) )
Cheers,
Comment 2 tommy27 2014-05-03 22:12:50 UTC
tested under Win7x64

loads correctly in LibO 4.0.6.2 --> 4.1.2.3
loads incorrectly in LibO 4.1.3.2 --> 4.3.0.0alpha1+ (*)

(*) Build ID: 0b03f7ed575838f90e6b1ebec3538a3a214f81fb
TinderBox: Win-x86@42, Branch:master, Time: 2014-04-30_02:30:23

set status to NEW, changed version field

regression happened between 4.1.2 and 4.1.3 final releases.
that is a small range of committs that should make easier to identify the bug root.

I add Writer expert to CC list.
Comment 3 Yousuf Philips (jay) (retired) 2014-05-04 08:21:09 UTC
Hi Cor,

Yes i reported 4.1.5 as that is the last version package in the 4.1.x PPA. :) I run my tests on the last released version of each major release (3.6, 4.0, 4.1, 4.2) and as well as 4.3 alpha1.
Comment 4 tommy27 2014-05-04 08:35:44 UTC
(In reply to comment #3)
> Hi Cor,
> 
> Yes i reported 4.1.5 as that is the last version package in the 4.1.x PPA.
> :) I run my tests on the last released version of each major release (3.6,
> 4.0, 4.1, 4.2) and as well as 4.3 alpha1.

when you test with older release, please specify exactly which one you tested (i.e 4.0.6, 4.1.6 etc. etc) otherwise your words may be misleading

>... and was tested from 4.0 to 4.3. I'm running Linux Mint.

in this case it may look you tested from 4.0.0 to 4.3.0 which was not the real case.
Comment 5 Yousuf Philips (jay) (retired) 2014-05-04 10:09:55 UTC
(In reply to comment #4)
> 
> when you test with older release, please specify exactly which one you
> tested (i.e 4.0.6, 4.1.6 etc. etc) otherwise your words may be misleading

will add 'latest releases' to further reports

> 
> in this case it may look you tested from 4.0.0 to 4.3.0 which was not the
> real case.

Well i did test 4.3.0. :)
Comment 6 tommy27 2014-05-04 10:37:09 UTC
(In reply to comment #5)
> > 
> > in this case it may look you tested from 4.0.0 to 4.3.0 which was not the
> > real case.
> 
> Well i did test 4.3.0. :)

ok, but it sounded like your tests included all releases from 4.0.0 to 4.3.0, whilst you just tested 4.0.6 and 4.1.5 from the 4.0.x and 4.1.x branches

in this case the bug did not appear in all the 4.1.x version but just from 4.1.3 and following.
Comment 7 Joel Madero 2014-05-05 16:11:25 UTC
Couple points on this one:
(1) relatively sure it's a dupe but can't track down the duplicate bug
(2) Interestingly enough, I don't see the table on page 14 I see it on 16 (if this is wrong than we have other problems with this document)

Bibisecting now ;)
Comment 8 Joel Madero 2014-05-05 16:24:29 UTC
Note that there were a couple problems within the bibisect range BUT I focused exclusively on the margin issue.

d8e99c6c28c49f83bb630e4a175652dccc8c9883 is the first bad commit
commit d8e99c6c28c49f83bb630e4a175652dccc8c9883
Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
Date:   Thu Oct 17 15:09:24 2013 +0000

    source-hash-704292996a3731a61339b1a4a5c90c9403aa095f
    
    commit 704292996a3731a61339b1a4a5c90c9403aa095f
    Author:     Julien Nabet <serval2412@yahoo.fr>
    AuthorDate: Sat Jun 29 07:58:10 2013 +0200
    Commit:     Julien Nabet <serval2412@yahoo.fr>
    CommitDate: Sat Jun 29 07:58:10 2013 +0200
    
        Fix some idl descriptions
    
        Change-Id: Icd8aedbe66943bb06720af3fb572f7acce96c05e

:100644 100644 c475a1ae770d5a937d7e9aa1bdc1bd755f4e72aa 1bb7ce773fc4b986e0e6977bef274e8a3659453e M	ccache.log
:100644 100644 bc5b3b06a0363b037fd7290759c06c8c07a994b4 ba6021a3451f3ae6d409b28994850232ffe7d0fc M	commitmsg
:100644 100644 035d86795f8689df9f651e3f4c2a76e932d1ccc6 afa5b7468a3f8c97a10c69f25e98005560967af1 M	dev-install.log
:100644 100644 5264e0cce58ad6f7c684bc1875a075b305751ed9 49c73586fe49bae5fc307b4de7f8dca5e397b0fb M	make.log
:040000 040000 ff3b02582b94ebee45c83a43e74498b8d66b04a5 53e2e025354bd880b66a325e57d3a2d005e53a23 M	opt



# bad: [793dbf6f80f497dfe587d560d6257f42a24273f6] source-hash-1581b1fc3ac82a7bd62df968226e98604a4ca52d
# good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932
git bisect start 'latest' 'oldest'
# good: [8092559c5013969ebda017d79200463b9b975038] source-hash-fd84daf696a368c2c7561b5253b32a63ecdeca4a
git bisect good 8092559c5013969ebda017d79200463b9b975038
# bad: [0270ef1b76a6de423b30f7927362cc01c1a0fc38] source-hash-b1f7dd66b898b03cb4bd8d434b6370310ea95946
git bisect bad 0270ef1b76a6de423b30f7927362cc01c1a0fc38
# good: [aedcb9e93c73792e6d4f6bc5d74050efbe5af7c1] source-hash-358b60b3b172968a7605b428af01df456d7669b2
git bisect good aedcb9e93c73792e6d4f6bc5d74050efbe5af7c1
# good: [63ac4ab9665db60fac1e1813c9c80da52b2e87c6] source-hash-66e39940d763586060c4bcc8c3cd213495c40b79
git bisect good 63ac4ab9665db60fac1e1813c9c80da52b2e87c6
# good: [318bcb373da01174e1947da5e3ce77e078a33a77] source-hash-4a143c44fe7ad266ab9ab7dca317b0099b1438d0
git bisect good 318bcb373da01174e1947da5e3ce77e078a33a77
# good: [ecefd44257608d071eee7dd4eb61aae6bfe8071c] source-hash-022c54742e7997bf46a608f1ab0b500f2537f7f5
git bisect good ecefd44257608d071eee7dd4eb61aae6bfe8071c
# bad: [b5ad09b039d04bcbaf45b6d09f6b8799fcdaa23b] source-hash-6bf79576aeca243db553ed3b5eade492dc35337b
git bisect bad b5ad09b039d04bcbaf45b6d09f6b8799fcdaa23b
# good: [ad6df926a3911c6bae22834823e9788621126554] source-hash-344d80ee1d3829b28c18135ac4f0500d4b69aedd
git bisect good ad6df926a3911c6bae22834823e9788621126554
# bad: [d8e99c6c28c49f83bb630e4a175652dccc8c9883] source-hash-704292996a3731a61339b1a4a5c90c9403aa095f
git bisect bad d8e99c6c28c49f83bb630e4a175652dccc8c9883
# first bad commit: [d8e99c6c28c49f83bb630e4a175652dccc8c9883] source-hash-704292996a3731a61339b1a4a5c90c9403aa095f
Comment 9 tommy27 2014-05-05 16:35:42 UTC
hi Joel, does your bibisect confirm that suspected regression happened between 4.1.2 and 4.1.3 final releases, like in my QA tests?
Comment 10 Joel Madero 2014-05-05 16:36:57 UTC
unfortunately bibisect doesn't go by version # is goes by commits so I can't confirm what release it was introduced - sorry!
Comment 11 Yousuf Philips (jay) (retired) 2014-05-05 21:27:33 UTC
(In reply to comment #7)
> (2) Interestingly enough, I don't see the table on page 14 I see it on 16
> (if this is wrong than we have other problems with this document)

Its possible you dont have the right font (the only one used in this file is Calibri) which might be increasing the file size as it should have 19 pages.
Comment 12 Michael Stahl (CIB) 2014-07-07 13:10:35 UTC
yep this changed in 4.1.3

regression from:

commit 74c5ed19f430327988194cdcd6bdff09591a93fa
Author:     Adam Co <rattles2013@gmail.com>
AuthorDate: Wed Jun 26 11:08:56 2013 +0300
Commit:     Miklos Vajna <vmiklos@suse.cz>
CommitDate: Fri Jun 28 11:43:48 2013 +0200

    DOCX import fix for table with auto size
Comment 13 Adam CloudOn 2014-07-07 15:03:58 UTC
Created attachment 102376 [details]
Optimized DOCX file that reproduces problem

I've added an optimized DOCX file that reproduces the problem.
Ha ! a regression from a year ago .. wow !
Comment 14 Yousuf Philips (jay) (retired) 2014-07-11 19:21:05 UTC
Another example document of it going out of the margins is attachment 102480 [details] of bug 81100.
Comment 15 Björn Michaelsen 2014-10-16 14:59:11 UTC Comment hidden (obsolete)
Comment 16 Xisco Faulí 2015-09-09 13:44:07 UTC
(In reply to Yousuf (Jay) Philips from comment #14)
> Another example document of it going out of the margins is attachment 102480 [details]
> [details] of bug 81100.

I can no longer reproduce this issue with

Version: 5.0.1.2
Build ID: 81898c9f5c0d43f3473ba111d7b351050be20261
Locale: es-ES (es_ES)

and Office Word 2010

on Windows 7 (64-bit)

Thus, I close this as RESOLVED WORKSFORME
Comment 17 Robinson Tryon (qubit) 2015-12-15 11:03:11 UTC Comment hidden (obsolete)
Comment 18 Yousuf Philips (jay) (retired) 2017-09-29 18:47:02 UTC
Was fixed in 4.4.

Version: 4.4.7.2
Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600
Locale: en_US.UTF-8