Created attachment 107341 [details]
Comparison Textboxs in 4.4 vs 4.3
The margins of imported DOCX textboxes have been reduced and moved in 4.4. When a textbox is up against the margin, it's so bad that the text is outside of the box's border line. This issue occurs on the screen and when printed.
Step to reproduce:
1) Create a new doc with a textbox in Word2007+
2) Snap the textbox to the left margin
4) Open in Write 4.4
This is a regression in 4.4. Libreoffice 4.3 sets the margins of imported textboxs correctly, so the imported textbox looks like Word's.
Created attachment 107342 [details]
Simple DOCX file showing issue with reduced margins
confirmed under Win7x64 using 18.104.22.168.alpha0+
Build ID: 268b9c10c9ff27c74678ace99762f28d58d33012
TinderBox: Win-x86@42, Branch:master, Time: 2014-10-02_23:35:24
status NEW.works fine with 22.214.171.124 hence regression.
issue is limited to .DOCX format, .DOC and .ODT are unaffected.
please define the O/S where you reproduced the bug.
moreover when you report bugs against master is always a good thing to copy and paste Build ID info from the "Help/About LibO dev" textbox
Within the daily dbgutil bibisect repo, from `git bisect good`:
49ffb467231cc09d9e351aa2d37f2c0d99c3eb3d is the first bad commit
Author: Miklos Vajna <email@example.com>
Date: Thu Jun 19 08:24:47 2014 +0200
:100644 100644 426040151e25ab34608c1a48dcc8ce13f56cd591 7c0067294d629d902d426a1017494a199b13ddbe M build-info.txt
:040000 040000 48d4cbc2d07d98d0855650a07a3591184041f373 a0503b6bedcbb741ca300660091d132f8cf56bf6 M opt
and from `git bisect log`:
# bad: [3bd90766c05c07c4a39e36cb1d3106b0016983d4] 2014-10-05
# good: [b3130c846de5cf1b4be48b48dfc780bb369549fa] 2014-05-21
git bisect start 'origin/master' 'oldest'
# bad: [5ed7df78a02df9f716188ab12cc6f641f479b6d1] 2014-07-29
git bisect bad 5ed7df78a02df9f716188ab12cc6f641f479b6d1
# bad: [402ad27d59e542f8ff5fc88c4ffa74613a3cadfc] 2014-06-24
git bisect bad 402ad27d59e542f8ff5fc88c4ffa74613a3cadfc
# good: [5507b65dd2f68bdc720e23686e57269d46c16411] 2014-06-07
git bisect good 5507b65dd2f68bdc720e23686e57269d46c16411
# good: [8415e4b7f11bc7defc143883e5daf89e90643de7] 2014-06-15
git bisect good 8415e4b7f11bc7defc143883e5daf89e90643de7
# bad: [49ffb467231cc09d9e351aa2d37f2c0d99c3eb3d] 2014-06-19
git bisect bad 49ffb467231cc09d9e351aa2d37f2c0d99c3eb3d
# good: [35c0f684cef2fdbe270ff9d3b37169731ef61033] 2014-06-17
git bisect good 35c0f684cef2fdbe270ff9d3b37169731ef61033
# good: [2d5ec4b381617f69c8daf3f149f71425af0ce9e9] 2014-06-18
git bisect good 2d5ec4b381617f69c8daf3f149f71425af0ce9e9
# first bad commit: [49ffb467231cc09d9e351aa2d37f2c0d99c3eb3d] 2014-06-19
It's obviously a regression from d379d18666aa42031359ca8eb34b0021960347ae, I plan to look into this.
(This is an automated message.)
Setting priority to highest as this is a MAB. This is part of an effort to make the importance of MAB reflected in priority too.
Changes imported textboxes from text within frames to text within a TextBox shape. The TextBox's outer position and dimensions are correct, but the text inside is shifted up and to the left.
Created attachment 119178 [details]
Text Box ignores margins, Frames keeps them
To see the issue here compare this file in Writer 4.x with Writer 5.x.
I ran into a related issue with docx import, only this time the text was completely out of place. Upon further investigation, I discovered that we're now completely ignoring the margins of text boxes, whereas the old code was respecting them. The attached file clearly illustrates the issue. Should I file a new bug report or track it under this one?
Created attachment 120863 [details]
Second example showing LO 4.3 correctly importing margins
Left textbox should have the text vertically and horizontally centered, while the right textbox has no margins.
Migrating Whiteboard tags to Keywords: (bibisected)
I know you did this to enable shapes, but it seems to break more than it fixes. Do you think you could revert the old behavior in cases where no shapes are involved?
Created attachment 126525 [details]
Example of MSO document with text box not correctly shown by LO
Build ID: 1:5.1.4-0ubuntu1
CPU Threads: 2; OS Version: Linux 4.4; UI Render: default;
Locale: en-GB (en_GB.UTF-8)
Created attachment 126761 [details]
debug84678_patch.diff: to help a developer get started
comment 10: I tried to do a simple revert and LO crashes, so it has moved a long way in 2 years and there is simple reversion option.
I think the first place to start is focusing on the FRAME position, not the textbox. Try moving the frame around - it jumps all over the place and immediately gets out of sync with the textbox.
Created attachment 126771 [details]
zip with various word PDFs of Comment 11's August.docx
reply to comment 11: this is a different problem than the reported one. I tried opening it in Word 2007 (xp) and in Word Online (Firefox) and it looks bad even in both of those.
Created attachment 126778 [details]
Patch to re-enable Text Frames
This patch reverts d379d18666aa42031359ca8eb34b0021960347ae. As Justin pointed out it breaks a lot of Unit Tests. If we decide to go down this path, I can try to figure out additional code was added between 4.4 and now that's causing this issue.
I think 4.3's use of Text Frames aligns much better with MSO's Text Boxes. Our Text Frame's "Spacing to Content" maps perfectly to MSO's Text Box margins. Our Text Boxes don't have margins. And when you move them the text doesn't stay in the Text Box, which kind of defeats the whole point of Text Boxes.
What do you think of going back to Text frames?
Please refrain hijacking bug reports with your issues. attachment 126525 [details] renders better in LibreOffice than it does in MSO 2013. The frame is cut off in MSO 2013 and fully displayed in LibreOffice. The CONFIRMATION Text Box renders the same in LibreOffice as it does in Word 2013 and Word Online. Neither of these issue are related to this issue of "textbox margins".
*** Bug 98830 has been marked as a duplicate of this bug. ***
*** Bug 100921 has been marked as a duplicate of this bug. ***
Adding Cc: to Miklos Vajna
Miklos Vajna committed a patch related to this issue.
It has been pushed to "master":
tdf#84678 DOCX import: fix handling of textbox margins
It will be available in 5.3.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:
Affected users are encouraged to test the fix and report feedback.
I see the bad alignment fixed between commit cec94a4 (2016-10-14) and
commit 8175e30 (2016-10-25).
I used local-built LibreOffice, configured ...
built and running on debian-stretch.
Set it to VERIFIED FIXED as per comment 19
*** Bug 99002 has been marked as a duplicate of this bug. ***