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]
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
--->> attachment 91407 [details] from bug 73215
Same behaviour with attachment 69953 [details] from bug 56950
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.
Created attachment 136399 [details] Shape anchored as character with top vertical positioning
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.
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
Regression introduced in range https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=43c7830b03d141ae11d8617c0fdabefa32dd243c..ce97851773a06103504972eb2771eecd7dd81e36&ofs=50
(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?
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.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
(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).
Dear Xisco Faulí, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Created attachment 181472 [details] character_anchor_top_vert_alignINLINE2003.rtf: modified by MS Word 2003 "As Character" is termed "In line with text" in MS Word. LO currently imports this inline image as "To Character" in RTF. So some import work needs to be done as well. (No related bug reports found.)
http://www.biblioscape.com/rtf15_spec.htm has lots of information regarding RTF shapes, but nothing indicates in-line. There is a {\sp{\sn fPseudoInline}{\sv 1}} that controls this - which looks borrowed from the .doc format and so is probably a custom extension to RTF.