Bug 112519 - FILESAVE: RTF: Shape changes position after RT
Summary: FILESAVE: RTF: Shape changes position after RT
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.6.0.4 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: filter:rtf, notBibisectable, regression
Depends on:
Blocks: RTF-Shapes
  Show dependency treegraph
 
Reported: 2017-09-20 11:43 UTC by Xisco Faulí
Modified: 2020-04-05 06:00 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Shape anchored as character with top vertical positioning (8.92 KB, application/vnd.oasis.opendocument.text)
2017-09-20 12:16 UTC, Tamás Zolnai
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Xisco Faulí 2017-09-20 11:43:57 UTC
Steps to reproduce:
1. Open attachment from bug 73215
2. Save it as .RTF
3. Open the new file

Observed behaviour: Autoshape is on top of the document now.

Reproduced in

Version: 6.0.0.0.alpha0+
Build ID: 8abc7ba9784f7898576fbdd7a48f0ff9e4445a68
CPU threads: 4; OS: Linux 4.10; UI render: GL; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group

[Bug found by office-interoperability-tools]
Comment 1 Xisco Faulí 2017-09-20 11:45:09 UTC
Regression introduced by:

author	Tamás Zolnai <tamas.zolnai@collabora.com>	2017-08-22 00:02:07 (GMT)
committer	Tamás Zolnai <tamas.zolnai@collabora.com>	2017-08-22 05:53:36 (GMT)
commit	2d1fe7fb67ec1ff1b96912c0945d17d54aecb12e (patch)
tree	6d783d7a89d3613544b6de64245f7e9ae147bc75
parent	508957dbf49be577188fb4c112405717957b2734 (diff)
Fix two issues in ActiveX DOCX import / export code
* Inline anchored VML shape had wrong vertical position
** In MSO inline shapes are positioned to the top of the baseline
* During export all shape ids were the same (shape_0)
** VML shapes used to be exported only as fallback,
   I guess that's why it did not cause any issue before.
** Override the shapeid generator with a new one, which
   actually generates unique shapeids.

Bisected with: bibisect-linux64-6.0

Adding Cc: to Tamás Zolnai
Comment 2 Xisco Faulí 2017-09-20 11:46:47 UTC
--->> attachment 91407 [details] from bug 73215
Comment 3 Xisco Faulí 2017-09-20 12:12:54 UTC
Same behaviour with attachment 69953 [details] from bug 56950
Comment 4 Tamás Zolnai 2017-09-20 12:15:25 UTC
I checked what the issue here. The behavior change is caused by the code change in oox/source/vml/vmlshape.cxx file. I changed the inline shapes import (DOCX) to have top vertical position instead of the default one, because this kind of alignment is closer to MSO inline alignment behavior.
The issue is that RTF export seem to not handle top vertical positioning of shapes anchored as character. I'll attach an ODS test document showing the same issue.
So the root of the problem is not in the code change I added (DOCX import), but in RTF export which is untoched by the referenced commit.
Comment 5 Tamás Zolnai 2017-09-20 12:16:33 UTC
Created attachment 136399 [details]
Shape anchored as character with top vertical positioning
Comment 6 Tamás Zolnai 2017-09-20 12:21:02 UTC
Hi Xisco,

Can you check with the attached ODT whether there is a regression in RTF export causing this issue. It might be easier to find out a solution.
Comment 7 Xisco Faulí 2017-09-20 12:49:57 UTC
it seems to be an old regression.

The blue rectangle is shifted to the top on

Version 4.1.0.0.alpha0+ (Build ID: 8669ad398a2971706ce22b6e5fe316991977452)

but not in

LibreOffice 3.5.0 
Build ID: d6cde02

Updating the info. Thanks for taking a look at it
Comment 8 Xisco Faulí 2017-09-20 19:53:33 UTC Comment hidden (obsolete)
Comment 9 Xisco Faulí 2017-09-20 20:14:11 UTC
(In reply to Xisco Faulí from comment #8)
> Regression introduced in range
> https://cgit.freedesktop.org/libreoffice/core/log/
> ?qt=range&q=43c7830b03d141ae11d8617c0fdabefa32dd243c..
> ce97851773a06103504972eb2771eecd7dd81e36&ofs=50

ahhh, this is weird, the behaviour is different when using the --convert-to from command line or when doing it from the UI. The issue in Tamás' attachment is not reproduced using the command line if 83fbebfea32b27cd722466607aa978244ac53575 is reverted, but not from the UI.

@Miklos, could you please shed some light on this issue?
Comment 10 Miklos Vajna 2017-12-13 08:55:51 UTC
Commandline does not wait for idle jobs (layout, word count, etc), while typically by the time you manage to get to File -> Save as, they are completed. That might be a difference. At least for the layout, the Word export filters explicitly calc the layout for a long time; the ODT export started to do that just recently.

So such behavior difference can happen, but the intention is that these differences are eliminated.
Comment 11 QA Administrators 2019-03-16 03:56:32 UTC Comment hidden (obsolete)
Comment 12 Aron Budea 2020-04-05 06:00:18 UTC
(In reply to Xisco Faulí from comment #8)
> Regression introduced in range
> https://cgit.freedesktop.org/libreoffice/core/log/
> ?qt=range&q=43c7830b03d141ae11d8617c0fdabefa32dd243c..
> ce97851773a06103504972eb2771eecd7dd81e36&ofs=50
The range covers two months, from 2011-12-13 to 2013-02-06, keyword notBibisectable seems more appropriate.

Bug still in LO 7.0.0.0.alpha0+ (aa191f35978ea48bbacc0e613ae8f0e6536ebcfc).