Problem description: This word file does not open correctly at all. Most information is missing. Steps to reproduce: 1. Just open the file2. .... 3. .... Current behavior: Expected behavior:
Created attachment 51988 [details] These are two documents in Word, 1 withprotection the other without protection
I don't know why 2 documents have been attached, I tested with "CONTRACT RISK REVIEW TEMPLATE UNPROTECTED.docx". [Reproducible] with "LibreOffice 3.4.3 RC2 - WIN7 Home Premium (64bit) German UI [OOO340m1 (Build:302)]", import result is completely unusable. Still a problem with Server installation of Master "LibO-dev 3.5.0 – WIN7 Home Premium (64bit) English UI [(Build ID: 81607ad-3dca5fd-da627d2)]". Worked find with "LibreOffice Portable 3.3.3 - WIN7 Home Premium (64bit) German UI [OOO330m19 (Build:301 Tag 3.3.3.1)]" @Cédric: Please feel free to reassign (or reset Assignee to default) if it’s not your area or if provided information is not sufficient. Please set Status to ASSIGNED if you accept this Bug. @Maarten Hennekam Your Operating System is? - Reported with Bug Submission Assistant -
I can confirm that only the first two lines of this 4 page DOCX document are visible when using LO 3.4.5RC2 Under LO 3.5.0Beta2 the whole document is loaded but the first table formatting is lost (which makes it unreadable)
Tested again with LibreOffice 3.5.2.2 (Build-ID: 281b639-6baa1d3-ef66a77-d866f25-f36d45f) running on MacOS X 10.6.8 German to see if there is any progress about this bug. Like Rainer Bielefeld, I tested with the file 'CONTRACT RISK REVIEW TEMPLATE UNPROTECTED.docx'. The situation is still similar to the one reported by Pedro (comment #3) for 3.5.0Beta2: The completed document is loaded and shown (a big progress!), but the formatting of the first (big) table containing the risk factors is not correct: both the whole table and the 1st column are far too wide, therefore the last (4th) column is outside of the page (in the right margin) and so not visible at all. So the remaining main problem is that table (column) widths are still not imported correctly from the DOCX file.
(In reply to comment #4) > So the remaining main problem is that table (column) widths are still not > imported correctly from the DOCX file. ^This is still true with LibreOffice 3.6.0beta1 (Build ID: 1f1cdd8), tested on MacOS X 10.6.8.
Setting the focus on the remaining problems in LibreOffice 3.5.x and 3.6 beta 1, I have updated Summary, Platform and Importance fields according to comment #3, comment #4 and comment #5. (I have lowered the importance because it is now rather easy to make the complete table visible again -- but it is still annoying, of course.) @Miklos: Given the fact that you are our RTF and dmapper expert, could you please take a look at this .docx import problem? To me (as a layman) it sounds similar to some bugs you have fixed in the last time, so maybe you can figure out rather easily what is going wrong here with the column widths ... Thank you very much!
the "cannot import anything" problem appears to be fixed. so... it appears that the table and the first column of the table have been excessively wide in all OOo/LO releases i've tried going back to OOo 3.0.1, so this is not a regression. current master improves over 3.6 branch because the first column is no longer excessively wide, however the table is still too wide to fit.
(In reply to comment #7) > the "cannot import anything" problem appears to be fixed. >... > current master improves over 3.6 branch because the first column > is no longer excessively wide, however the table is still too wide > to fit. In 4.1.1.2 the left RESPONSE STRATEGIES column of the table is still to wide to fit the document. Other stuff is fine. Alternative solution is, right click the left column and clict to "Column - Optimal Width" and it is identical to Word :) Best regards, Zeki
Sorry it should be the *right column :)
Bulk change: Bibisected bugs can be assumed to be regressions.
removing erroneously added "regression", see comment #7
Created attachment 102321 [details] screenshot in LibO 4.2.4.2 I took a screenshot of the .docx document as it looks opened in LibO 4.2.4.2 (the same look appears in end of june 4.4 master). please upload a screenshot of the same .docx opened in MS Word so we can better depict which are the residual inconsistencies apart from the obvious last column excessive width and out of bounds issues
According to comment 7 this isn't a regression, thus remove bibisected35 bibisected35older from whiteboard
Created attachment 114710 [details] PDF printed from Mac Word 2011
As also commented above, the behaviour of this has improved since 3.3, but the essential issue that the table is too wide dates back to before LO. -> Version: Inherited from OOo
*** Bug 60952 has been marked as a duplicate of this bug. ***
*** Bug 79722 has been marked as a duplicate of this bug. ***
*** Bug 62026 has been marked as a duplicate of this bug. ***
** 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.0.5 or 5.1.2 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: 2016-04-16
This Bug and Bug 60952 is still on Windows 10 - 64 bits with: Versão: 5.0.5.2 ID de compilação: 55b006a02d247b5f7215fc6ea0fde844b30035b3 Local: pt-BR (pt_BR) Versão: 5.1.2.2 ID de compilação: d3bf12ecb743fc0d20e0be0c58ca359301eb705f Threads da CPU:4; Versão do SO: Windows 6.2; Realizador da interface: padrão; Local: pt-BR (pt_BR)
*** Bug 101767 has been marked as a duplicate of this bug. ***
referencing Bug 62293 - RTF: Table going outside the page and dumping remaining cells (same issue for rtf)
In Version: 5.3.0.0.alpha0+ Build ID: c780c6726dca5e2fe33297e44f25ae3e00703294 the tables nicely show 5 columns as in the pdf attached in comment #14, but stil have a phantom column F and G (off page..)
** 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
Versión: 5.3.5.2 Id. de compilación: 30m0(Build:2) Subproc. CPU: 4; SO: Linux 4.4; Repres. IU: predet.; VCL: kde4; Layout Engine: new; Configuración regional: es-ES (es_ES.UTF-8); The issue is not appearing now, so is solved. THANK YOU
Created attachment 138323 [details] docx which contains a table which is not correctly displayed in LO 5.4
It seems that my comment disappeared. As my attachment shows the bug is still present in LO 5.4
I opened you docx, and can "see" (cause it have no line borders) the table and is out of bounds, but I openen the files attached by Marten Hennekam and tables are now just where it should. So, maybe your file example is related to another issue, IMHO.
Well when I submitted my bug report a while ago somebody Classified it as duplicate of this bug which is obviously is not true So in short LO still has issues with tables I am not sure what is best now. Leave that bug open? Open another one?
In your example, you didn't tell us if is an old document created with Word or a new one with Writer ... Even sometimes, when you save a document in native LO format, some issues dissapear. In my case, I'm interested in maintain compatibility with docx documents, so if saving the documento to odt the issue dissapear, I'm happy. But don't know if is your case and your tried what I suggest.
Why is this important how this file was generated??? If LO wants compatibility with docx, it must open all docx files without problems. The file in question can be opened without problem in MS word! But for your curiosity: this file was written in emacs, using its org mode and then converted via pandoc https://pandoc.org/ to docx. I presume that pandoc satisfies certain (ISO?) rules of the docx syntax.
Well, I think is important for multiple reasons. As you know, ANY program has bugs, so is important IMHO to trace the document workflow if it's not natively created with the application in which you find some issue. I have some (bad) experiencies about this bugs that make a supposedly well generated file (on distinct formats of data) that really is not well formed and it gave headaches till I discover that were bugs in the software that created the file. So it's not curiosity, it's simply information that can help developers to consider other variables in the issue (in this case, could be not Writer related really). Thank you for the info.
Tested in Version: 6.3.0.0.alpha0+ Build ID: b8e450a54936560cdac00ab4c70ef80c20cfaf99 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-01-18_06:04:42 Locale: nl-NL (nl_NL.UTF-8); UI-Language: en-US Calc: threaded (In reply to Matthew Francis from comment #14) > Created attachment 114710 [details] > PDF printed from Mac Word 2011 Files from comment #1 are OK now. :) ! (In reply to Cor Nouws from comment #22) > referencing Bug 62293 - RTF: Table going outside the page and dumping > remaining cells (same issue for rtf) The table from that bug is not displayed ok. (In reply to Uwe Brauer from comment #26) > Created attachment 138323 [details] > docx which contains a table which is not correctly displayed in LO 5.4 But this table is not displayed correctly. @oub.oub.oub@gmail.com : you may want to resurrect the orig bug report?
I upgraded to LO 6.1.4.2 and the table is *still* not displayed correctly
Created attachment 148521 [details] screenshot of how LO display incorrectly a table in a docx document screenshot of LO 6.1.4.2 still showing the bug
(In reply to Uwe Brauer from comment #35) > I upgraded to LO 6.1.4.2 and the table is *still* not displayed correctly For me. 6.1.x is downgrading ;) But serious: you may want to check a daily. And of course 6.2.0.1. Possibly if we know the fix/dev, a backport can be done?
6.1.4.2 is the official version, not something experimental. I would appreciate a link to the version you are using
I managed to download 6.2.0.2 it still does not work. I attach screenshots. I can send you the docx offline if you want.
Created attachment 148522 [details] table still not correctly displayed in 6.1.0.2 width needs to be set to automatic
(In reply to Uwe Brauer from comment #40) > Created attachment 148522 [details] > table still not correctly displayed in 6.1.0.2 width needs to be set to > automatic Hi Uwe, Thanks. But that is not the document from the bug report, isn't it? (not the title of this bug says "particular") I notice other documents too that still have the problem (see comment #34). There are many types of tables and shitty ;) (sorry) stuff out there.. Can you create a new report for your file? Thanks - Cor