Bug 101627 - FILEOPEN: Height of text box in footer in DOCX imported wrong (thus hiding the page number)
Summary: FILEOPEN: Height of text box in footer in DOCX imported wrong (thus hiding th...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.0.0.5 release
Hardware: All All
: medium normal
Assignee: Not Assigned
QA Contact:
URL:
Whiteboard: target:5.4.0 target:5.2.7 target:5.3.3
Keywords: bibisected, bisected, filter:docx, regression
: 100073 106486 (view as bug list)
Depends on:
Blocks: DOCX-Textbox
  Show dependency treegraph
 
Reported: 2016-08-20 19:57 UTC by Oliver Sander
Modified: 2017-05-31 04:07 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Original docx document (44.70 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2016-08-20 19:57 UTC, Oliver Sander
Details
The file as shown by MS Office (12.67 KB, application/pdf)
2016-08-20 19:58 UTC, Oliver Sander
Details
pdf file exported from LibreOffice 5.2.0.4 (55.48 KB, application/pdf)
2016-08-20 19:58 UTC, Oliver Sander
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Oliver Sander 2016-08-20 19:57:30 UTC
Created attachment 126922 [details]
Original docx document

I have a one-page docx document, which contains a page number '1' at the bottom center of the page.  This number is not visible when opening the file.  There is a grey rectangle indicating that there is 'something' where the page number is supposed to be, but no number.

When exporting the file to pdf, the number is not visible at all.
Comment 1 Oliver Sander 2016-08-20 19:58:01 UTC
Created attachment 126923 [details]
The file as shown by MS Office
Comment 2 Oliver Sander 2016-08-20 19:58:42 UTC
Created attachment 126924 [details]
pdf file exported from LibreOffice 5.2.0.4
Comment 3 Cor Nouws 2016-08-22 09:50:10 UTC
Hi Oliver,

thanks for reporting. I confirm _a_ problem. And that is that the text box in the footer is too low, so the field page number is not visible.
(already a problem in 3.3.0.4, but that version didn't show the text box in the center, and no field at all)

ciao - Cor
Comment 4 Oliver Sander 2016-10-21 18:09:51 UTC
Reproduced in

LibreOfficeDev 5.3.0.0.alpha1 f4ca1573fcf445164c068c1046ab5d084e1b005f
Comment 5 Jan-Marek Glogowski 2017-02-22 09:15:35 UTC
I guess this feature was not implemented in older versions. I did an bibisect in the releases repository:

$ git bisect log
git bisect start 'latest' 'oldest'
# good: [cbcb5169c711a61f0771b3ad86aa50df236397fc] libreoffice-4.2.6.2
git bisect good cbcb5169c711a61f0771b3ad86aa50df236397fc
# bad: [f04ad09f107af87c9f66cbbb860e2a206c1a7784] libreoffice-5.0.0.5
git bisect bad f04ad09f107af87c9f66cbbb860e2a206c1a7784
# good: [6a61d90ebea0aa870c943ec2b975a0577ee7b38f] libreoffice-4.3.6.1
git bisect good 6a61d90ebea0aa870c943ec2b975a0577ee7b38f
# good: [0d500f42e3ce8160d13784d5869c2dd86f719b37] libreoffice-4.4.2.1
git bisect good 0d500f42e3ce8160d13784d5869c2dd86f719b37
# good: [afcf5d1fd08f48fb8b10cbdeae39db5658524d8c] libreoffice-4.4.6.3
git bisect good afcf5d1fd08f48fb8b10cbdeae39db5658524d8c
# bad: [a716e1f28f954b8e98b4c349d03748f1432464cf] libreoffice-5.0.0.2
git bisect bad a716e1f28f954b8e98b4c349d03748f1432464cf
# bad: [74fe407600b30673bc73b572df90f3101cd18b2d] libreoffice-5.0.0.1
git bisect bad 74fe407600b30673bc73b572df90f3101cd18b2d
# good: [e992b5c0217fbbfaed351e4898b8c751ae2fe90e] libreoffice-4.4.7.2
git bisect good e992b5c0217fbbfaed351e4898b8c751ae2fe90e
# first bad commit: [74fe407600b30673bc73b572df90f3101cd18b2d] libreoffice-5.0.0.1
Comment 6 Jan-Marek Glogowski 2017-02-22 11:35:44 UTC
Now I did I bibisect of bibisect-50max:

$ git bisect log
# bad: [dda106fd616b7c0b8dc2370f6f1184501b01a49e] source-hash-0db96caf0fcce09b87621c11b584a6d81cc7df86
# good: [5b9dd620df316345477f0b6e6c9ed8ada7b6c091] source-hash-2851ce5afd0f37764cbbc2c2a9a63c7adc844311
git bisect start 'latest' 'oldest'
# good: [0c30a2c797b249d0cd804cb71554946e2276b557] source-hash-45aaec8206182c16025cbcb20651ddbdf558b95d
git bisect good 0c30a2c797b249d0cd804cb71554946e2276b557
# good: [2ce02b2ce56f12b9fcb9efbd380596975a3a5686] source-hash-17d714eef491bda2512ba8012e5b3067ca19a5be
git bisect good 2ce02b2ce56f12b9fcb9efbd380596975a3a5686
# good: [40875247f0002056effdf6d2fbe43627691cd86c] source-hash-93f0b14458a618ad575cd446680e5c4aa7d87bdc
git bisect good 40875247f0002056effdf6d2fbe43627691cd86c
# skip: [61f66b1a251477193d796411ca95f50d606ead45] source-hash-3fd5f8919ec2256c70ff26c14cb9f8065c5cb2f1
git bisect skip 61f66b1a251477193d796411ca95f50d606ead45
# good: [e7374cd735af2344dae55be40946d96633d2f6ee] source-hash-8a91528a3e03fe6e2923c33327b687ecf57adb0b
git bisect good e7374cd735af2344dae55be40946d96633d2f6ee
# bad: [541837707e7b0c5f5335180de535043c43e78e8d] source-hash-0811de12ee6727bbb9d4265217833ba02301eed8
git bisect bad 541837707e7b0c5f5335180de535043c43e78e8d
# good: [2faf2a5126e3ccf78be3d6619b571358bb7af742] source-hash-2523972f6a066488c649ab97dcba4f458126f18b
git bisect good 2faf2a5126e3ccf78be3d6619b571358bb7af742
# good: [036709cec55938932b487542cdbace379c2651e2] source-hash-d8eee8e4d1a303044bf34b28c2e95bd6da23fd79
git bisect good 036709cec55938932b487542cdbace379c2651e2
# good: [1c13469c3e122da98a10fdf5df58a34a53980fc3] source-hash-02eff9d83734b99996b30cf65768f27bfc0e161b
git bisect good 1c13469c3e122da98a10fdf5df58a34a53980fc3
# good: [0117e1d734e216881e29e0fb5d7eef50ed84d554] source-hash-5db6da7c5d27c5b8be59fb9a4599d5c95d7f1bd7
git bisect good 0117e1d734e216881e29e0fb5d7eef50ed84d554
# good: [1a628f941bed58fcd10f8cbc076cefebb33690bd] source-hash-b1a9498a1415ca42e4d13f3e56daff0ebffc0ccf
git bisect good 1a628f941bed58fcd10f8cbc076cefebb33690bd
# good: [9fdcd68b3b9f7f927c9cd1135b6943ebbec4faf8] source-hash-2527a4d5a7cb1a7086129019a29dc063a3a28f63
git bisect good 9fdcd68b3b9f7f927c9cd1135b6943ebbec4faf8
# bad: [c21fc0c70e76c190e485a6a765e189a2f0e27006] source-hash-a4dee94afed9ade6ac50237c8d99a6e49d3bebc1
git bisect bad c21fc0c70e76c190e485a6a765e189a2f0e27006
# good: [14dead702d0e64559551b38001d273f96fa1cd3c] source-hash-de8afb9a2b461da4c81e45a7e185b553a5f4c3e7
git bisect good 14dead702d0e64559551b38001d273f96fa1cd3c
# good: [d3a0559de9451a09724a4af5c536377604bda18f] source-hash-02cc648dc068080d65b44ebd10d0940f6a097b8a
git bisect good d3a0559de9451a09724a4af5c536377604bda18f
# first bad commit: [c21fc0c70e76c190e485a6a765e189a2f0e27006] source-hash-a4dee94afed9ade6ac50237c8d99a6e49d3bebc1

which points to:

commit a4dee94afed9ade6ac50237c8d99a6e49d3bebc1
Author: László Németh <laszlo.nemeth@collabora.com>
Date:   Wed May 13 17:47:36 2015 +0200

    tdf#91260: allow textboxes extending beyond the page bottom
    
    This commit fixes layout problems of DOCX import, but also
    now it's possible to move a textbox beyond the page bottom
    using the arrow keys (this worked only for page-anchored
    shapes in Writer).
    
    Change-Id: Ie83d3202a2248d948348656aa26df20982f9675b

Reverting it fixes the problem.
Comment 7 Jan-Marek Glogowski 2017-02-22 17:37:26 UTC
I added the following line to the "shrink code" from bug 91260 (sw/source/core/objectpositioning/anchoredobjectposition.cxx:503):

SAL_DEBUG( "bCheckBottom: " << bCheckBottom << " => " << aSize.GetHeight() << " - ( " 
           << nProposedRelPosY << " - " << nAdjustedRelPosY << " ) => " << nShrinked );

For the attached document of bug 91260 it results in:

bCheckBottom: 1 => 6191 - ( 12442 - 8209 ) => 1958

For the attached document from this bug it results in:

bCheckBottom: 1 => 264 - ( 2 - -207 ) => 55

My guess it the code doesn't handle the negative "nAdjustedRelPosY" correctly. In relation to  bCheckBottom, negative nAdjustedRelPosY are probably just fine, as long as the top won't run out of the page top, which would shrink the frame from the top.

Now while it's now possible to load the document from bug 91260 correctly I can't move the frame correctly out of any other then the left border. So I couldn't create a test document with a text box frame outside the top to verify my guesswork.

Would be nice to have a test document with four frames, each overlapping one of the page borders at some point, but I guess that's an other bug / enhancement…
Comment 8 Patrick Jaap 2017-02-23 15:38:02 UTC
(In reply to Jan-Marek Glogowski from comment #7)
> bCheckBottom: 1 => 6191 - ( 12442 - 8209 ) => 1958
> bCheckBottom: 1 => 264 - ( 2 - -207 ) => 55
I got the same results. But I don't think that the negative number is the problem. The vertical position of the anchor "nTopOfAnch" (in Bsp1.docx: 17065 twip) is not right, because the whole document ends at 17122 twip. In contrast the rendered position is right, see MSO render. Since the textbox would fit on the page, the treatment with shrinking is not necessary at all. 

So there has to be an error in the value of "nTopOfAnch". I'm on it.
Comment 9 Xisco Faulí 2017-03-15 16:56:44 UTC
*** Bug 106486 has been marked as a duplicate of this bug. ***
Comment 10 Patrick Jaap 2017-03-22 11:24:12 UTC
Update:

The origin of the wrong measurement "nTopOfAnch" is still unclear. 
I can add a few observations: It has something to so with the footer. If I move the textbox from the footer to the standard body of the document (but keep the same position), the information will be stored in "document.xml" and instead of "footer2.xml".
Then, everything is rendered correctly. So there has to be some error in the footer offset.
Comment 11 Patrick Jaap 2017-03-28 09:25:33 UTC
The next Update:

# all numbers are in twip #

The attached document is vertically partitioned as follows:

Header margin: 720
Header text: 1418 - 720 = 698
Body: (later)
Footer text: 1418 - 709 = 709
Footer margin: 709

Since the whole document is of size A4, the total length is 16837, which leaves 14001 for the body.

All measures are taken from the docx (document.xml) file. 

The value nTopOfAnch in the shrinking is 17065. This value results from the footer text frame in SwFrame::MakePos(), which extents vertically from 16413 to 17121. The anchor is set 652 below the beginning of this frame, thus 17065. Since the position is a little strange, there has to be a vertical offset of 994 (no idea why). These observations are verified by variating the numbers in the docx file.

Ok, now the page alignment frame in  SwAnchoredObjectPosition::ImplAdjustVertRelPos extents from 284 to 17121. This is a range of 16387 (A4 page), but with an offset of 284 (?). Therefore, the shrinking thinks, that the page ends 17121-17065 = 56 below the anchor. This leads to the shrinking of the textbox, since it is 264 in height.

Now the question is, where the two different offsets (284 vs 994) are set.

Feedback is welcome!
Comment 12 Commit Notification 2017-03-29 12:42:12 UTC
Patrick Jaap committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=80b9b6761e8cb974e0cdc0c7be0eb95f8745d86f

tdf#101627 disable shrinking for footer textboxes

It will be available in 5.4.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 13 Commit Notification 2017-03-31 14:31:15 UTC
Patrick Jaap committed a patch related to this issue.
It has been pushed to "libreoffice-5-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=cbbe5c471cad37ab434a11b804c66e0b424af8a7&h=libreoffice-5-2

tdf#101627 disable shrinking for footer textboxes

It will be available in 5.2.7.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 14 Commit Notification 2017-03-31 14:31:23 UTC
Patrick Jaap committed a patch related to this issue.
It has been pushed to "libreoffice-5-3":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=da18188c359dee813fa1d4c7000490f1512c277b&h=libreoffice-5-3

tdf#101627 disable shrinking for footer textboxes

It will be available in 5.3.3.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 15 Patrick Jaap 2017-04-18 07:32:26 UTC
*** Bug 100073 has been marked as a duplicate of this bug. ***
Comment 16 Commit Notification 2017-04-20 18:42:54 UTC
Patrick Jaap committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=d862741423cdf0ef228d34b2a25b09c9401be584

tdf#101627 add unit test

It will be available in 5.4.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 17 Oliver Sander 2017-05-12 19:54:43 UTC
I confirm that this is fixed in

Version: 5.4.0.0.alpha0+
Build ID: 74ccd02eda2d6325a27266fd935aba29b3d75020

Thanks a lot!
Comment 18 krishna [:kr1shna] 2017-05-31 04:07:08 UTC
per comment 17, verified, hence status change.