Created attachment 96454 [details] MS Word Document (.docx) and MS Word screenshot Problem description: The attached MSO document opens in Writer without content (looks empty). Steps to reproduce: Open attached document in Writer. Current behavior: Document looks empty. Expected behavior: Document looks like it does in MS Word (reference screenshot attached). Operating System: Windows 7 Version: 4.2.3.1 rc
Confirmed in master.
Issue still existing in 4.4.1.2 release.
Issue still existing in 5.5.0.2 release.
Still reproducible in Version: 5.4.0.0.alpha0+ Build ID: d3b5bd4a07a619db6bee1c39c32280ac3c620532 CPU threads: 4; OS: Linux 4.8; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group and LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4
DOCX has 2 columns, but not properly created: 1st column has width 16,59 cm and spacing is empty. LO reads TextSection with 1 column, where 1st has width 0,01 cm and spacing 16,00 cm (or 56,00 cm) Workaround 1: If TextSection is removed, content is there. Workaround 2: save DOCX in MSO with some spacing.
Created attachment 131963 [details] Problem DOCX - original with 2 columns and empy spacing XML validation shows 2 errors: main:space - attribute invalid, value -1 not valid main:w - attribute invalid, value -1 not valid
Created attachment 131964 [details] Problem DOCX - original screenshot
Created attachment 131965 [details] Problem DOCX - resaved with 2 columns and some spacing
** 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
Repro 6.1+
Columns width and space: The possible values for this attribute are defined by the ST_TwipsMeasure simple type (§2.17.104). This simple type specifies that its contents will contain a positive whole number, whose contents consist of a measurement in twentieths of a point (equivalent to 1/1440th of an inch). However <w:cols w:num="2" w:space="794" w:equalWidth="0"> <w:col w:w="9406" w:space="-1"/> <w:col w:w="-1"/> </w:cols>
Hmm, more than that. Also appears that the function calculating column width is wrong since inception at https://cgit.freedesktop.org/libreoffice/core/commit/?id=d462a3470c7fc61fcb53fde82fd8fe5489376483 particularly with these lines pColumn[nCol].Width = sal_Int32((double( m_aColWidth[nCol] + pColumn[nCol].RightMargin + pColumn[nCol].LeftMargin ) + 0.5 ) * fRel ); if( nColSum != nRefValue ) pColumn[m_nColumnCount].Width -= ( nColSum - nRefValue ); https://gerrit.libreoffice.org/59400 tdf#76683 writerfilter: TwipMeasure must be positive https://gerrit.libreoffice.org/59401 related tdf#76683 writerfilter: hanging implemented as SignedTwips
The following unit tests had instances where a TwipsMeasure was found with a negative value. ooxmlexport2: fdo66781.docx - numbering.xml hanging indent -1080 ONLY ON A ROUND TRIP - so we are exporting incorrectly in numbering - should be "firstLine" instead of "hanging" for negative numbers. -also ooxmlexport4 tdf86926_A3.docx -also ooxmlexport9 tdf112169.odt -also ooxmlexport10 tdf89702.docx proposed fix at https://gerrit.libreoffice.org/59423 related tdf#76683 docx export: use firstLine, not hanging ooxmlexport11: tdf118521_marginsLR.docx - document.xml hanging indent -500. Error in hand-crafted document. Interestingly MS Word ACCEPTS AND USES THE NEGATIVE VALUE despite their documentation.
Justin Luth committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=352efa5b3cb7d025b9a299e2fcade5f7822ed043 related tdf#76683 docx export: use firstLine, not hanging It will be available in 6.2.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.
Created attachment 144894 [details] Not sure working I tested 2 files with 6.2 on linux: I am not sure it is working, please see the video I made. On this video I open first the file from comment 6, the one with errors, and the file is open blank. After that, in video I open the file from comment 8 and it is working as aspected. Version: 6.2.0.0.alpha0+ Build ID: 9a9b81c7212fa6a6762246593acf3f1950677a22 CPU threads: 4; OS: Linux 4.15; UI render: GL; VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2018-09-08_00:00:43 Locale: ro-RO (ro_RO.UTF-8); Calc: threaded
Oops. Yes, the patches to fix it are still pending. Comment 15 was just a related patch. The proposals in Comment 13 are still pending review. Not fixed yet.
Justin Luth committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=93242e985a002d94b0ac765952ce47b928effcae tdf#76683 writerfilter: TwipMeasure must be positive It will be available in 6.2.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.
Really fixed now. Tomorrow's related patch will build on and take advantage of the TwipsMeasure changes made to fix this bug, but not related to the column bug itself.
Justin Luth committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=b4c0a0ea0102d4157572b4f4302324533c0667fb related tdf#76683 writerfilter: hanging implemented as Signed It will be available in 6.2.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.