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.
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 22.214.171.124 and 4.3.0alplha1 too... (or is the listed version wrong ;) )
tested under Win7x64
loads correctly in LibO 126.96.36.199 --> 188.8.131.52
loads incorrectly in LibO 184.108.40.206 --> 220.127.116.11alpha1+ (*)
(*) 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.
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.
(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.
(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. :)
(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.
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 ;)
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
Author: Bjoern Michaelsen <email@example.com>
Date: Thu Oct 17 15:09:24 2013 +0000
Author: Julien Nabet <firstname.lastname@example.org>
AuthorDate: Sat Jun 29 07:58:10 2013 +0200
Commit: Julien Nabet <email@example.com>
CommitDate: Sat Jun 29 07:58:10 2013 +0200
Fix some idl descriptions
: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
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?
unfortunately bibisect doesn't go by version # is goes by commits so I can't confirm what release it was introduced - sorry!
(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.
yep this changed in 4.1.3
Author: Adam Co <firstname.lastname@example.org>
AuthorDate: Wed Jun 26 11:08:56 2013 +0300
Commit: Miklos Vajna <email@example.com>
CommitDate: Fri Jun 28 11:43:48 2013 +0200
DOCX import fix for table with auto size
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 !
Another example document of it going out of the margins is attachment 102480 [details] of bug 81100.
(This is an automated message.)
It seems that the commit that caused this regression was identified. (Or at least a commit is suspected as the offending one.)
Thus setting keyword "bisected".
(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
Build ID: 81898c9f5c0d43f3473ba111d7b351050be20261
Locale: es-ES (es_ES)
and Office Word 2010
on Windows 7 (64-bit)
Thus, I close this as RESOLVED WORKSFORME
Migrating Whiteboard tags to Keywords: (bibisected)
Was fixed in 4.4.
Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600