Created attachment 99125 [details]
DOC file as example
Open the attached file using programs LibreOfficeDev-4.3.0 (or LibreOffice-4.1.6\4.2.4) and LibreOffice-4.0.6. The second table is placed on the page incorrectly.
It’s the regression to the LibreOffice-4.0.6.
Created attachment 99126 [details]
The screenshot shows an error
It seems to me that there is an error in parsing file.
Please read my message (bug 78745 comment 3) and look at the contents (content.xml) of this file (attachment 99152 [details]).
Created attachment 107001 [details]
DOC re-saved with frame set to "no wrap" LOv4322
Originally provided DOC opened under GNU/Linux using:
- v188.8.131.52 OOO330m19 Build: 401
- v184.108.40.206 OOO340m1 Build: 602
- v220.127.116.11 Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b
- v18.104.22.168 Build ID: e183d5b
- v22.214.171.124 Build ID: 2e2573268451a50806fcd60ae2d9fe01dd0ce24
- v126.96.36.199 Build ID: 40ff705089295be5be0aae9b15123f687c05b0a
- v188.8.131.52 Build ID: 3fd416d4c6db7d3204c17ce57a1d70f6e531ee21
- v184.108.40.206 Build ID: edfb5295ba211bd31ad47d0bad0118690f76407d
- v220.127.116.11.alpha0+ Build ID: df73f4115cfe4d07e4159adf087571687eb173ec TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2014-09-25_23:06:16
Rendering under v3.3-4.0 are all OK. Rendering under v4.1-4.4 show the same problem: the frame (blue graphic) at top-left is anchored "to character" with wrap set to "through/in background". In older versions of LO this evidently was not being handled correctly and so was pushing the small table at top-right to the right and the larger table down the page, keeping positioning as expected.
This is not correct behaviour for wrap "through/in background" i.e., other objects should flow over the top / in the foreground. Evidently under later versions this frame is now being treated in the correct manner, thus causing the other tables to appear in front. Changing the wrap of this frame to "no wrap" fixes the display as expected. Refer attached.
Bug was originally self-confirmed. I am confirming that in older versions there appears to have been a problem, but recent versions have fixed this issue. If my findings can be confirmed I think this report can be RESOLVED as NOTABUG. Severity set to normal. Summary amended for clarity.
Confirmed in Version: 18.104.22.168.alpha0+
Build ID: f33002aa5de7e88960e7c21286a661c89fd478c7
TinderBox: Win-x86@39, Branch:master, Time: 2014-10-04_03:31:18
Owen, if you open blank_edit.doc in Word and look at the properties of the TextBox, you'll see that it's set to "Wrap text behind image". So Writer's importer should no be setting Wrap to "No Wrap" as in your attached solution. The problem is likely similar to Bug 82824, where the importer is not setting the anchor position of the table on the right side correctly.
Sorry, but reduce the level of this bug, which is a regression, not right. So I returned the status to critical. Lowering the error status will lead to the fact that about her forget.
(In reply to Luke from comment #5)
> Owen, if you open blank_edit.doc in Word and look at the properties of the
> TextBox, you'll see that it's set to "Wrap text behind image". So Writer's
> importer should no be setting Wrap to "No Wrap" as in your attached
Which version of Word are you using? In Word 2007 the layout for the top-left AutoShape is "Behind text" and has "Allow overlap" checked. To be clear, I am suggesting that Writer (since v4.1) may be rendering correctly i.e., "Behind text"+"Allow overlap" == "through/in background". The suggestion/example of "No wrap" was a workaround.
> The problem is likely similar to Bug 82824, where the importer is
> not setting the anchor position of the table on the right side correctly.
The example in that bug has columns. I am not clear whether the /anchoring/ reference here refers to the linked bug or this one (there does not appear to be any anchoring issue in this bug). In any case, the top-right table does have text wrapping set to "Around" while the main table has text wrapping set to "None". It may be the handling of these settings by Word that prevents overlap of the tables (as the summary now implies). Thanks for helping clear this up.
(In reply to ape from comment #6)
> Sorry, but reduce the level of this bug, which is a regression, not right.
> So I returned the status to critical. Lowering the error status will lead to
> the fact that about her forget.
Setting this level too high will cause the bug to be ignored. The guidelines for setting this field are here:
This is not a critical issue (although it may be important to you) as critical means data loss / crash. This is formatting issue, thus Severity = normal.
Please ignore my statement about this not being a bug in comment 4.
Yes, it's not an anchor issue with the table. This can be verified by toggling the "Wrap Around" property of the upper right table in Word(I used 2013). When it is off, Word renders the document like current versions of LO. In writer turning the wrapping on for the table will also fix the import.
(In reply to Owen Genat from comment #7)
> (In reply to Luke from comment #5)
> Which version of Word are you using? In Word 2007 the layout for the
> top-left AutoShape is "Behind text" and has "Allow overlap" checked. To be
> clear, I am suggesting that Writer (since v4.1) may be rendering correctly
> i.e., "Behind text"+"Allow overlap" == "through/in background". The
> suggestion/example of "No wrap" was a workaround.
> (In reply to ape from comment #6)
WinWord-2007sp3 (last update)
There are only 'skip'ped commits left to test.
The first bad commit could be any of:
We cannot bisect more
Thanks to Kevin's bibisects, I was able to manually further narrow it down to
id=578d3476f0c1bc13ac08cc111f5d758226f4d07b - BAD
id=1591194a5fc45cbd44c0f4cb022d8ff8c88e0a24 - GOOD
this leave a rage of
With only http://cgit.freedesktop.org/libreoffice/core/commit/?id=4e07258cbd1f4fb16d6ce2174fb5c74c3b36da33
#i119466# Doc file loaded by AOO, table with incorrect text wrapping property.
as the most likely cause.
Before this commit
Text box wrap - in background
table wrap - optimal page wrap
Text box wrap - in background
table wrap - page wrap
We need to be careful that the fix for this does not break the test cases in
Miklos, can you please take a look at this?
It seems that the commit that caused this regression was identified. (Or at
least a commit is suspected as the offending one.)
Thus setting keyword "bisected".
Thanks dev-list and this post
I was able to narrow the range further down to:
4e07258cbd1f4fb16d6ce2174fb5c74c3b36da33 is the source of this regression.
So it seems Word's "Wrap Around" is being mapped to LO's "Page Wrap". In LO "Page Wrap" allows tables to overlap, while Word's does not.
Page's wrap's description is "Wraps text on all four sides of the border frame of the object." By this definition, a table with text should not be overlapping.
Miklos, would it be possible to fix page wrap or would we need to add a new more compatible wrap type?
I confirm the regression Libre Writer 22.214.171.124
Locale ru-RU (ru_RU)
OS: Windows XP sp2 64-bit Edition
*** Bug 60342 has been marked as a duplicate of this bug. ***
Similar problem with attachment 121124 [details] from Bug 96325.
Migrating Whiteboard tags to Keywords: (bibisected)
comparing screen shots in
that should provide evidence for the applied patch,
I can hardly see any difference so wonder if that's all worth the trouble it causes..
*** Bug 96307 has been marked as a duplicate of this bug. ***
*** Bug 88950 has been marked as a duplicate of this bug. ***
*** Bug 74915 has been marked as a duplicate of this bug. ***
*** Bug 75958 has been marked as a duplicate of this bug. ***
*** Bug 81498 has been marked as a duplicate of this bug. ***
@justin: something you have an idea of maybe? thanks, Cor
if bug 96307 is a duplicate, then this comment points to the commit that caused the regression
> 4e07258cbd1f4fb16d6ce2174fb5c74c3b36da33 is the commit introducing the
> See https://bz.apache.org/ooo/show_bug.cgi?id=119466 for details.
Could you please take a look at this?
Created attachment 128804 [details]
test case for i119466.doc: Aoo testcase used for regression patch from https://bz.apache.org/ooo/show_bug.cgi?id=119466#c7
Based on this test case, I conclude that the current code properly imports Word's wrapping (SURROUND_PARALLEL - wrap text on both sides of the table) instead of before the regression (SURROUND_IDEAL - the computer decides whether to wrap right or left, but not both).
(P.S. Frames ALSO ought to wrap parallel as seen in Word if you move the test case's frame more towards the center. Word's frame seems to have a greater demand for empty space than the table for some reason. Both are considered frames in LO btw.)
All of these broken documents "just happened" to work properly when set to _IDEAL wrapping, some because that triggers enabling "First Paragraph" ( aSurround.SetAnchorOnly(true) which means that the following paragraph starts below the current frame and is not included in the wrapping).
These documents work with EITHER _IDEAL OR “First Paragraph” (or both)
-attachment 112390 [details] (Fee Schedule 01-04-10.doc) from Bug 81498
-attachment 112963 [details] (exemple.doc) from bug 88950
-attachment 121103 [details] (kissaliitto_ilmo_141.doc) from Bug 96307
This document depends on _IDEAL and is not "fixed" by "First Paragraph".
-attachment 95428 [details] (Sea Launch plus image.doc) from Bug 75958
This bug's document depends on “First Paragraph” being set and doesn’t care whether it is wrapped _PARALLEL or _IDEAL:
-attachment 99125 [details] (blank_edit.doc) from this bug. (note: also affected by bug 103967)
Ironically enough, the original Aoo bug (1277__FSODC250FFCSW_TABLE0010.doc) from comment 19 looks best with _IDEAL wrapping and NO “First paragraph”
Before 2002, frames were imported as _PARALLEL (and changing back to this does not cause any unit test failures... make check runs successfully, but likely
in the real world it would invite many regressions).
author Caolán McNamara <email@example.com> 2002-10-11 13:16:56 (GMT)
#i4173# wrapping for old word frames is really optimal wrap, not parallel
- eSurround = ( rWW.nSp37 > 1 ) ? SURROUND_PARALLEL : SURROUND_NONE;
+ eSurround = ( rWW.nSp37 > 1 ) ? SURROUND_IDEAL : SURROUND_NONE;
The "First Paragraph" part was added by
author Cédric Bosdonnat <firstname.lastname@example.org> 2010-10-12 08:08:27
n#617593 Fixed the frame surrounding in ww8 import
*** Bug 108095 has been marked as a duplicate of this bug. ***
I confirm this bug.
Build ID: 3cc1cdd8ee50f144e5514da51800a08119754d8f
CPU threads: 8; OS: Windows 5.2; UI render: default;
Locale: ru-RU (ru_RU); Calc: group
Still reproducible in
Build ID: 34e8fd7e99489e9f50a512b07c6f3923b358b4d3
CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk3;
Locale: ca-ES (ca_ES.UTF-8); Calc: group
thinking about comment #28 and comment #29, one might conclude that reverting to the old behavior, would cause at least as much, but prolly more problems ?
If so, I suggest to close as WONTFIX ..
@justin, pls what is your though on this?
(In reply to Cor Nouws from comment #33)
> thinking about comment #28 and comment #29, one might conclude that
> reverting to the old behavior, would cause at least as much, but prolly more
> problems ?
But the amount of 'see also' bugs and duplicates, seem to indicate different..
(In reply to Cor Nouws from comment #33)
> @justin, pls what is your though on this?
I have no insight into the details of how LO or MSWord handle wrapping, but based on the number of problems, there is probably some fundamental difference that LO tries to emulate on import/export. If true, then having lots of bug reports would be expected regardless of the implementation.
I know that when I heavily use this feature for something like a newsletter, I would tweak the positioning/sizing of the pictures or even the content of the text itself to get it to flow exactly how I want it. Obviously the slightest difference in rendering (when taking the document to a different program) could then throw off all of my tweaking (and lead me to write a bug report about the terrible compatibility).
1.) Definitely do not revert - regressions are worse than unfixed bugs.
2.) Very likely there ARE real bugs here that need to be fixed. But if I remember correctly all of these examples are very complex documents. Someone will need to tease out the essence of the problem(s) and create a minimal reproducer document.
3.) Don't close a bug report with lots of duplicates. Obviously there are severe compatibility challenges here.
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!
Problem is still there with the latest LibreOffice
Version: 126.96.36.199 (x64)
Build ID: 98b30e735bda24bc04ab42594c85f7fd8be07b9c
CPU threads: 8; OS: Windows 10.0; UI render: default; VCL: win;
Locale: fi-FI (fi_FI); UI-Language: en-US
Still reproducible in
Build ID: abea0d6647c7f1f7e76c73c26cb80e6a67dc5111
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
I removed regression, because these seem to be "just happened to look better before" examples and none of them clearly show an error was made.
I'm also reducing the importance - again because these are very complex documents - not simple files that clearly demonstrate one problem. Also, DOC format has isn't getting much attention any more, and used less often.