Created attachment 80455 [details] Original file It seem the same issue than BUG ID 36791 , but with 4.0.3.3 and amd64 architecture. found attachment : original docx , pdf from word , and pdf produce from writer. Pierre
Created attachment 80456 [details] pdf of original docx
Created attachment 80457 [details] pdf of the import in writer
Hi, I can reproduce this behaviour using Linux Mint 15 x64 with Version: 4.2.0.0.alpha0+ Build ID: 3c8d419f4ba4ea9fa4d00b5691900dae091fd3a Bug 36791 indeed shows the same behaviour, but lets keep them separate (not as duplicate) due the fact it is about another document. If that bug is fixed, it might be worth it to retest this too. Kind regards, Joren
I can reproduce also with Debian Squeeze on a x86-32 platform. LO 4.0.3.3 become very slow with great CPU activity reading this file. I must kill LO and restart. So this bug is important.
Could you know why this document can't be open . workaround ? i can ask my collegue to modify the document. Pierre
I test with the 4.1.0.2 . same probleme. Please, How can i understand what in this document is a problem? picture ? header ? footer ? Pierre
Hi, This file docx is displayable with fewest problems in OOo 3.3.0. In LO 4.0.4.2, I can display the content of this file with View, Web Layout. But roll scrolling makes a lot of problems of displaying : Images that multiply themselves with several repeated pieces. Scrolling with page after page mode (Page down key) give better results. So it is the display layout of LO writer that failed. Also, styles manager does not work fine. Some style in this document are not listed in the styles dialogue but are listed in the toolbar. Last observation : the behaviour is worst with French menus against English menus (?!). This file is unusable in LO 4.0.4.2. Regards.
Confirmed buggy in 3.5.7 on ubuntu 12.04.3 Furthermore, strongly agree with comment#4 , there is a performance-bug here, simultaneous with the layout-corruption-bug. On my system, opening the original docx takes 33 seconds. Can somebody please test how long it takes to open in Aoo4, and in msftWord (please report office-version and OS-version). @Pierre, besides taking a pretty long time to load, when I did get it open, most pages looked good inside libreoffice 3.5.7 on ubuntu 12.04.3 LTS -- the worst broken were the first few pages (title page was missing some of the text and the table-of-contents was just outright blank). The 'real' content, the instructions on how to install the software and such, looked pretty decent. There was definitely some trouble with the font, however -- make sure you have installed the same fontfaces on both systems, which means, either have the msftWord system install the Libertine fonts, or install the msftTruetype fonts onto your Linux system. Somebody mentioned that your file looked best to them in OpenOffice 3.3.0 -- that is probably also still supported on Ubuntu 12.04.3 , but you might have difficulty getting it fully working -- something in the package seems to reference LibreOffice which seems incorrect. Another option you might consider is going really old-school, and downloading a copy of CentOS 5.5, which does support docx -- http://www.centos.org/docs/5/html/5.5/html-single/Release_Notes/#id543727 (CentOS is a free-as-in-beer clone of RHEL.) Unfortunately, there is not much immediate help I can offer, besides telling you of a distro which you might be able to try out (that still offers support for older versions of OpenOffice -- which means you can install the distro onto a usbkey with something like the tool found here -- http://www.pendrivelinux.com/yumi-multiboot-usb-creator/ -- and then boot into a distro that will work well with your particular problem-file. (You can also install one of these old-school distros as a guest-OS into some virtual machine software, if you have enough ram... which means no need to reboot in order to work with the problem-file.) I'd rather be able to say, hey, if the t-o-c is missing, that means you just need to change to heading-style-3 (or whatever). But if the corrupted-layout-bugs were that easy to work around, then they would already be fixed. Tracking down corruption-bugs is very hard, from what I can gather. Anyways, when you find documents that are buggy -- either ones that came from Word, and do not look right in LibreOffice, or ones that came from LibreOffice, and end up looking wrong when loaded into msftOffice, please keep filing bugs. It is appreciated, and it is the only way we can dig out of the compatibility hole. As for the future, besides filing bugs, it will help if you can get your coworkers to send you copies early and often. If they start out making a doc, and the first page looks terrible in LibreOffice, you can probably make a few trial-and-error changes, and figure out how to work around the trouble. But if they've already created all thirty pages, and gone through a week's worth of edits, who knows what particular edit(s) ended up breaking LibreOffice? That said, even if you find a workaround, please file a bug, so that the core app can be fixed so as not to *need* any workarounds. (Also, tell us what the workaround was, that might help somebody pinpoint the bug more quickly.) Thanks, and hope you find a way to make this particular problem-file work out.
Hello. I can not reproduce the issue with LibreOffice 4.3.3 and 4.4.0 beta2 on Debian x86-64. The document is being opened quickly and the content of the document is visible. As far as I do not know which patch solves the issue, I set bugstatus to RESOLVED WORKSFORME. Please, set it to UNCONFIRMED if you can reproduce the issue with LibreOffice 4.3 or later.
Migrating Whiteboard tags to Keywords: (filter:docx) [NinjaEdit]