Bug 99822 - FILEOPEN: Floating table objects in tables horizontal position relative to margin is wrong in Writer
Summary: FILEOPEN: Floating table objects in tables horizontal position relative to ma...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.1 all versions
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: compatibilityMode14
Keywords: bibisected, bisected, filter:docx, regression
Depends on:
Blocks: DOCX-Floatingtable
  Show dependency treegraph
 
Reported: 2016-05-13 07:45 UTC by RomaNick
Modified: 2021-01-11 08:27 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
page 4-7 (62.17 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2016-05-13 07:45 UTC, RomaNick
Details
WPS Office, analogously to MS (467.42 KB, image/jpeg)
2016-05-17 10:43 UTC, RomaNick
Details

Note You need to log in before you can comment on or make changes to this bug.
Description RomaNick 2016-05-13 07:45:15 UTC
Created attachment 125030 [details]
page 4-7

Hello.
It does not fix the correct location of objects. In MS Office & WPS office opens correctly. The LO 4.4.7.2 do not see pictures of the objects
Comment 1 Cor Nouws 2016-05-13 20:55:35 UTC
Hi RomaNIck,

Thanks for reporting.

Confirmed in Version: 5.2.0.0.alpha1+
Build ID: 52871b360c73efd59bfbc811b8b89a02b6375b29

that the objects on page 4-7 are positioned in the wrong table cell.
Can you maybe provide a screen shot of the correct situation?
Ciao - Cor
Comment 2 RomaNick 2016-05-17 10:43:19 UTC
Created attachment 125109 [details]
WPS Office, analogously to MS
Comment 3 Telesto 2016-12-11 14:11:29 UTC
Relating frame position: 

Repro with:
Version: 5.4.0.0.alpha0+
Build ID: 84f2ff67a7e404febf710b1dc7f66d06745c503f
CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2016-12-09_23:20:01
Locale: nl-NL (nl_NL); Calc: CL

Position of frame with the table seems quite good in:
LibreOffice 3.5.7.2 
Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b

I also created a new bug report related to the inconsistent pie chart color (bug 104579)
Comment 4 Xisco Faulí 2017-03-10 14:25:41 UTC
tables position regression introduced by:

author	Cédric Bosdonnat <cedric.bosdonnat@free.fr>	2013-02-20 10:04:16 (GMT)
committer	Cédric Bosdonnat <cedric.bosdonnat@free.fr>	2013-02-20 10:17:00 (GMT)
commit	d0cde9640b52ccfbb28ed1f65bba0927afd7b69b (patch)
tree	18c6342798d98ff8559a3cf26dac4994a2f82998
parent	a633a96c3a50d803e5fa43b603edc0b8e2e34b6e (diff)
n#779642: Fixed floating tables import in writerfilter
Comment 5 Xisco Faulí 2017-07-19 20:56:01 UTC
Still reproducible in

Version: 6.0.0.0.alpha0+
Build ID: bde72cdae1e7e001d5089c5284672c976b8e43df
CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group
Comment 6 Xisco Faulí 2017-07-19 21:00:31 UTC Comment hidden (obsolete)
Comment 7 Tamás Zolnai 2017-07-20 10:36:30 UTC
(In reply to Xisco Faulí from comment #6)
> Hi Tamás,
> This issue was introduced by the same commit that introduced bug 109053,
> which was recently fixed by you in commit
> fc55711f01af172eb3a034454405fa941454c781. Would you mind taking a look at it
> when you have some spare time ?
> Regards

Hi Xisco,

There is an ugly hack in the code related to tables. Sometimes tables are imported as simple Writer tables, sometimes as a table inside a text frame (called floating table). The second one is used to workaround the missing features of Writer tables compared to Word tables. It's not something I can fix easily. For bug 109053 it was easy to avoid this floating table stuff and import the table as simple a Writer table, but otherwise it's hard to handle this kind of bugs. So I would not dig myself in this problem now.
Comment 8 QA Administrators 2018-07-21 02:40:03 UTC Comment hidden (obsolete)
Comment 9 Timur 2018-11-19 10:01:19 UTC
Repro 6.3+. Can be a duplicate of Bug 80869.
Comment 10 Xisco Faulí 2020-03-30 16:34:24 UTC
The issue is still reproducible in

Version: 7.0.0.0.alpha0+
Build ID: 11e6582b23b983fde4b04ece5b37c546bcd98a43
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded

but it improved after https://cgit.freedesktop.org/libreoffice/core/commit/?id=4d5c0eaf3e0d3d3bcd9e691fffee19b75f3d6631

@László Németh, I thought you might be interested in this issue...
Comment 11 Justin L 2020-06-03 09:39:56 UTC
It looks to me like this is simply using the wrong anchoring. It should be relative to the cell margins, but it is being positioned relative to the page. NISZ guys have been going some work in this area, but this document isn't fixed yet in 7.1+.
Comment 12 NISZ LibreOffice Team 2020-06-03 10:40:35 UTC
(In reply to Justin L from comment #11)
> It looks to me like this is simply using the wrong anchoring. It should be
> relative to the cell margins, but it is being positioned relative to the
> page. NISZ guys have been going some work in this area, but this document
> isn't fixed yet in 7.1+.

Those are floating tables inside non-floating ones and the automatically added frame has wrong anchoring. We did not dare to touch such... yet.