Created attachment 46651 [details] formulier1ond.doc Downstream bug may be found at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/38569 OOo bug may be found at: http://openoffice.org/bugzilla/show_bug.cgi?id=100379 1) lsb_release -rd Description: Ubuntu 11.04 Release: 11.04 2) apt-cache policy libreoffice-writer libreoffice-writer: Installed: 1:3.3.2-1ubuntu5 Candidate: 1:3.3.2-1ubuntu5 Version table: *** 1:3.3.2-1ubuntu5 0 500 http://us.archive.ubuntu.com/ubuntu/ natty-proposed/main i386 Packages 100 /var/lib/dpkg/status 1:3.3.2-1ubuntu4 0 500 http://us.archive.ubuntu.com/ubuntu/ natty/main i386 Packages 3) What is expected to happen in LibreOffice Writer via the Terminal: cd ~/Desktop && wget https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/38569/+attachment/8966/+files/formulier1ond.doc && lowriter -nologo formulier1ond.doc and one Page 1, Ondernemingen rectangle text frame is shifted not shifted down. 4) What happens instead is it is shifted down.
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Problem reproducible in: LOdev 3.5.0beta2 Build ID: 8589e48-760cc4d-f39cf3d-1b2857e-60db978 Microsoft Windows Vista Business 6.0.6002 Service Pack 2 Build 6002
reproducible with LO 3.6.4.3. (Win7 Home, 64bit)
It's still present in: - Libreoffice 4.1.4.2 Build ID: 0a0440ccc0227ad9829de5f46be37cfb6edcf72 - Libreoffice 4.2.1.1 Build ID: d7dbbd7842e6a58b0f521599204e827654e1fb8b - Libreoffice 4.3.0.0.alpha0 ID: 95700a2d7d09893fe16aadb406e93bf7164f7422
** 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 on a currently supported version of LibreOffice (4.4.2 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-05-02
Confirmed. Win 7 Pro 64-bit Version: 5.1.0.0.alpha1+ Build ID: 3ecef8cedb215e49237a11607197edc91639bfcd TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-06-19_23:16:58 Locale: fi-FI (fi_FI)
** 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 on a currently supported version of LibreOffice (5.1.5 or 5.2.1 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20160920
Repro with Version: 5.4.0.0.alpha1+ Build ID: 9d320ec4d818f86e58a15fd46248026502b1cc94 CPU threads: 4; OS: Windows 6.2; UI render: default; TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2017-05-09_01:27:12 Locale: en-US (nl_NL); Calc: single
Created attachment 135890 [details] unlocked file - the protection password was removed. There are two "floating" tables here. -Federale Overheidsdienst Justitie -Ondernemingen Currently, the cell they are anchored in is vertically centered (table properties-Text flow-Vertical alignment=centered). Change this to "top" in Writer, and those two floating tables will be properly placed.
(In reply to Justin L from comment #9) > Created attachment 135890 [details] > unlocked file - the protection password was removed. To unlock the form, go to Tools - Options - LibreOffice Writer - Compatibility - and disable Protect Form
Created attachment 135891 [details] textbox_anchorToChar.doc: simple unit test In MSO, the cell vertical alignment doesn't affect the anchored object's placement, but in LO the object shifts as the vertical alignment is changed. ODT files act the same way, so this is just a fundamental difference between LO and MSO. Not easily resolved - although images/frames FORCE the anchor to the top. However, doing the same with textboxes would cause regressions in ODT. Perhaps a compat setting candidate?
Created attachment 135958 [details] textbox_anchorToChar2.docx: simple unit test - this time DOCX format with contentframe proposed fix for wrap-through objects: https://gerrit.libreoffice.org/41795 Textboxes - or any content frames - are still not working. A similar fix should enable that.
(In reply to Justin L from comment #12) > Textboxes - or any content frames - are still not working. A similar fix > should enable that. Wrong diagnosis. Instead, the problem was related to the fly's location compared to the cell frame. See proposed fix https://gerrit.libreoffice.org/#/c/41821/
Justin Luth committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=7a9fb40cb07de8c2ea33f92735be5008d30d6704 tdf#37153 ConsiderWrapOnObjPos: also affect wrap-thru objs It will be available in 6.0.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: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Justin Luth committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e56f61c4637c09afbf125fa02f131b0c49e36351 tdf#37153 ConsiderWrapOnObjPos: always affect anchoring cell It will be available in 6.0.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: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Justin L from comment #11) > In MSO, the cell vertical alignment doesn't affect the anchored object's > placement, but in LO the object shifts as the vertical alignment is changed. It isn't MSO per se, but whether or not a compat setting is enabled. doNotVertAlignCellWithSp. So I need to revert these commits and instead base it on the compat flag.
For DOC format: fDontVertAlignCellWithSp (1 bit): Specifies whether to not vertically align cells containing floating objects. Specified in [ECMA-376] Part 4, 2.15.3.23 (doNotVertAlignCellWithSp). MAY be ignored. Only supported in Office Word 2007 and Word 2010. DOCX ECMA spec says: doNotVertAlignCellWithSp (Don't Vertically Align Cells Containing Floating Objects) This element specifies whether applications shall vertically align the contents of a table cell, even when the contents of that table cell include one or more floating objects. Note that the floating object shall be part of the cell, and simply not displayed over the cell due to its anchoring relative to another part of the document. Typically, if the alignment of a table cell in a WordprocessingML document is specified, then the entire contents of that cell are aligned as specified [Example: The entire contents of the cell are centered vertically and moved right-aligned horizontally at that point. end example]. This element, when present with a val attribute value of true (or equivalent), specifies that whenever a floating object is present in a table cell, that no vertical alignment shall be applied to the contents of that cell, and the contents of the cell shall instead always be top aligned to the cell's contents.
I tested and it is only floating objects that affect it, not inline (AS_CHAR) objects. From what I can see, LO works the same way.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/52648dbfa8ea57b164070326d9a3355b45b4e1d0 NFC tdf#37153 ww8import: replace 'unknown' with compatibility names It will be available in 25.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/10b9d5200e382db5affaefc035ebe4d6b35a92fb tdf#37153 tdf#165478 sw: add mso-compat flag doNotVertAlignCellWithSp It will be available in 25.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.