Bug 101650 - Different wrapping space allowance between LO and Word: now a character is placed beside the table, in stead if below it.
Summary: Different wrapping space allowance between LO and Word: now a character is pl...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.3 all versions
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, filter:docx, regression
: 90553 101651 (view as bug list)
Depends on:
Blocks: DOCX-Frames
  Show dependency treegraph
 
Reported: 2016-08-22 08:17 UTC by Oliver Sander
Modified: 2023-03-15 18:51 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
The docx file in question (14.98 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2016-08-22 08:17 UTC, Oliver Sander
Details
The file as shown by MS Office (8.49 KB, application/pdf)
2016-08-22 08:19 UTC, Oliver Sander
Details
The file as rendered by LO 5.2.0.4 (88.19 KB, application/pdf)
2016-08-22 08:20 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-22 08:17:57 UTC
Created attachment 126951 [details]
The docx file in question

I have docx file which contains an asterisk.  It is used as a footnote mark, but it doesn't seem to technically be one.  When opening the file in Writer 5.2.0.4, the asterisk appears in the wrong location.
Comment 1 Oliver Sander 2016-08-22 08:19:06 UTC
Created attachment 126952 [details]
The file as shown by MS Office
Comment 2 Oliver Sander 2016-08-22 08:20:44 UTC
Created attachment 126953 [details]
The file as rendered by LO 5.2.0.4
Comment 3 Johnny_M 2016-09-17 22:57:48 UTC
I don't know if the issue here is separate to bug 101651 or not (the latter refers to space after table, while this one refers to the asterisk position). But anyway, confirmed together with it:

Confirmed with:
- 64-bit Linux Mint 17.1:
Version: 5.1.5.2
Build ID: 1:5.1.5~rc2-0ubuntu1~trusty1
CPU Threads: 2; OS Version: Linux 3.13; UI Render: default; 
Locale: de-DE (en_GB.UTF-8); Calc: group

- 32-bit Windows Vista:
Version: 5.2.1.2
Build-ID: 31dd62db80d4e60af04904455ec9c9219178d620
CPU-Threads: 2; BS-Version: Windows 6.0; UI-Render: Standard; 
Gebietsschema: de-DE (de_DE); Calc: group

- 32-bit Window Vista (as portable release):
LO 5.0.5.2 (de-DE)

With LO 4.0.4.2 (de-DE) (portable release on Vista): Issue does not occur. ==> regression

MS Office Word 2003 shows the file correctly.
Comment 4 Xisco Faulí 2016-09-18 17:09:14 UTC
*** Bug 101651 has been marked as a duplicate of this bug. ***
Comment 5 Xisco Faulí 2016-09-18 17:21:17 UTC
*** Bug 90553 has been marked as a duplicate of this bug. ***
Comment 6 Xisco Faulí 2016-09-18 17:24:02 UTC
Regression introduced by f4ae06c6b558628457f3abdade1f2a705bf8b886
Comment 7 Xisco Faulí 2016-09-18 17:52:14 UTC
it looks like if this change is reverted:

-    pFrameProperties[17].Value <<= m_nY;
+    pFrameProperties[17].Value <<= ConversionHelper::convertTwipToMM100(m_nY);

then, the table is rendered correctly, however, the test in f4ae06c6b558628457f3abdade1f2a705bf8b886 fails, so it needs some investigation.
Comment 8 Tamás Zolnai 2016-09-18 18:58:57 UTC
Hi,

I checked this problem. That's true it comes up with my commit (f4ae06c6b558628457f3abdade1f2a705bf8b886), but not this commit is the problem.
If you check the table positions you will see.
1) Open the document in MS Word and go to Table Properties -> Positioning. You can see table is positioned with 2,27" vertically, relative to page.
2) Open the document in Writer and open Frame dialog. In Writer a floating table is a simple table inside a frame. The floating table position is defined by the frame. So try to select the frame containing the table. In Frame dialog select Type tab which shows the positioning.
2.1) Now you can see 2,27" vertical positioning relative to entire page (the same as in MS Word)
2.2) After reverting the commit f4ae06c6b558628457f3abdade1f2a705bf8b886, this positioning value will be 1,29", which is wrong.
That wrong positioning was corrected by the bisected commit. Since the imported position value seems good, there can be some problem with the rendering (not precise enough?) or with the wrapping behavior.
Comment 9 Xisco Faulí 2016-09-26 15:09:39 UTC
Adding Cc: to Tomaž Vajngerl
Comment 10 Oliver Sander 2016-10-21 18:27:14 UTC
Reproduced in

LibreOfficeDev 5.3.0.0.alpha1 f4ca1573fcf445164c068c1046ab5d084e1b005f
Comment 11 Patrick Jaap 2017-02-22 13:55:16 UTC
Hi, I investigated this bug for a while now and I can say the position of the table is completely correct. The next thing I noticed: The asterisk is per definition at the right location (in LO): There are 5 empty lines above.

In the XML files there is no wrap information given, so following the docx documentation, the wrapping is "around" per default. Furthermore, there is a 0.25cm (141 twips) area on the left and on the right of the table where no text is allowed, MSO and LO read this correctly. 

Following this, there is still enough space for the asterisk on the left. So is this maybe a MS Office bug? Otherwise I would be glad about some kind of documentation links for this issue. For me, the behavior of LO is is more logical.
Comment 12 Patrick Jaap 2017-02-23 08:43:06 UTC
correction: the asterisk is in the 5th line with four empty lines above.
Comment 13 Tamás Zolnai 2018-01-15 13:24:36 UTC
*** Bug 101651 has been marked as a duplicate of this bug. ***
Comment 14 QA Administrators 2019-01-18 03:59:19 UTC Comment hidden (obsolete)
Comment 15 Cor Nouws 2019-01-18 21:52:36 UTC
still the same in Version: 6.3.0.0.alpha0+
Build ID: b8e450a54936560cdac00ab4c70ef80c20cfaf99
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-01-18_06:04:42
Locale: nl-NL (nl_NL.UTF-8); UI-Language: en-US
Calc: threaded
Comment 16 Cor Nouws 2019-01-18 21:55:39 UTC
(In reply to Tamás Zolnai from comment #8)
> Hi,
> 
> I checked this problem. That's true it comes up with my commit
> (f4ae06c6b558628457f3abdade1f2a705bf8b886), but not this commit is the
> problem.
> If you check the table positions you will see.
> 1) Open the document in MS Word and go to Table Properties -> Positioning.
> You can see table is positioned with 2,27" vertically, relative to page.
> 2) Open the document in Writer and open Frame dialog. In Writer a floating
> table is a simple table inside a frame. The floating table position is
> defined by the frame. So try to select the frame containing the table. In
> Frame dialog select Type tab which shows the positioning.

The problem is the wrapping of the frame aroudn the table - changing summary accordingly
Comment 17 QA Administrators 2021-08-30 03:55:57 UTC Comment hidden (obsolete, spam)
Comment 18 Justin L 2023-03-13 18:39:34 UTC
repro 7.6+

Modified the title since wrapping in MS Word is set to AROUND, not OFF. So the distinction must be the amount of empty space required before the text is allowed to fit into the wrap space.

(In Word I set the frame to be "right" instead of "center" and then with all that extra space available, the asterisk moved into the wrap space.)
Comment 19 Justin L 2023-03-15 18:51:04 UTC
probably a duplicate of bug 112313