Apache OpenOffice (AOO) Bugzilla – Issue 29754
MS Word import: document rendered wrong
Last modified: 2004-06-18 10:43:49 UTC
The following document renders wrong in OpenOffice.org 1.1.0. The document seems to incorporate all changes by the authors. If you insert it ("insert" -> "file" from the menu), you get to see all the changes. However, after merging all these changes, the layout is fundamentally different from import in MS Word (tested version '97 and 2000).
Created attachment 15611 [details] this file renders wrong in OpenOffice.org
Created attachment 15612 [details] Wrong rendering, see pages 5, 11, 12, 14, 15, 21 and others.
Created attachment 15613 [details] Using "insert -> file", this .doc will show all changes, as can be seen in this PDF
(PDF with rendering in MS Word will follow shortly)
Created attachment 15619 [details] This is how the .doc-file should be rendered, i.e. how it renders in MS Word. Only 11 pages and no cruft.
Is a conceptional problem in Writer. Writer handles tracked canges in tables and numberings quite differently from Word. See issue 9665 (and also 3460, 13116 and 17764) for further details. *** This issue has been marked as a duplicate of 9665 ***
Closed duplicate.
Re-opening. The issue is: "This document does not render correctly". Issue numbers 9665, 3460, 13116 and 17764 describe the internal handling of change tracking in OOo. My issue is about the filtering: this should IMHO mean that the MS-Word import-filter should remove these untrackable changes from the .doc before showing the document. In the current situation, these sorts of documents will simply make people (at least my girlfriend ;) say "See, you cannot use OpenOffice.org for .doc files". (Please note: I'm only trying to be helpful, so if this *really* can only be fixed in #9665, please close this issue again).
that's the problem here... the filter can't do better than the internal handling is... and even throwing away all changes by the filter will not be a good solution, because other people could interpret this as a "loss of information". Thus we prefer a full solution by enhancing our "Track changes" handling. Thanks for your patience.