Created attachment 91207 [details] MS WORD 97-2003 DOC with 3-column table Windows XP - MS Office 2007 Subject: MS WORD 97-2003 DOC has a 3-column table with global cell margins, configured in Table Properties->Table tab->Options. Some rows of this table have non-global cell margins, configured in Table->Cell->Options->uncheck "Equal to whole table". Bug: LibreOffice only copies the first cell margins of the "non-global" rows. The 2nd and 3d cell get the global cell margins instead of the (smaller) non-global cell margins. Example DOC: Table with global cell margins above, below, left, right = 0,15 0,45 0,15 0,15 cm. Table header = 0,1 0,1 0,15 0,15 cm. Other single line rows are 0,15 0,15 0,15 0,15 cm. In LibreOffice all rows show as 0,15 0,45 0,15 0,15 cm, because the margins of the 2nd and 3d cells of the non-global rows are not correctly implemented by LibreOffice. (Select the whole cell to check cell 1, 2, 3) Open attached DOC with LibreOffice Writer and examine table starting at page 2.
In my description: Replace "above margin" by "TOP MARGIN" Replace "below margin" by "BOTTOM MARGIN" In LibreOffice margins are inspected by following: 1. Select a table cell (not only the cell text, but the whole cell) 2. Choose Table... (Menu or Rightmouse click) 3. Choose Table Properties 4. Choose Borders tab: Spacing to contents - Left Right Top Bottom When you select the table header row in the provided example in LibreOffice Writer, you will find Spacing to contents = 0,00 0,00 0,00 0,00 cm, because the 3 Cells have different TOP/BOTTOM margins: 1st cell is correct: 0,15 0,15 0,10 0,10 cm (equals MS WORD margins) 2nd and 3d cell are incorrect: 0,15 0,15 0,15 0,45 cm (MS WORD cell margins 0,15 0,15 0,10 0,10 are not imported. Standard table cell margins get used instead)
This bug is about conversion of MS WORD DOC to LibreOffice ODT. I will not even start with MS WORD DOCX to LibreOffice ODT. It is a nightmare!!! Therefore I always save my co-workers DOCX to DOC, before I open with LibreOffice.
Bug still existing in version 4.2.5.2
I confirm -> NEW. Win 7 64-bit Version: 4.4.0.0.alpha1+ Build ID: 1baad070d8c2a38581cf33d803c5043f1974647f TinderBox: Win-x86@39, Branch:master, Time: 2014-11-01_00:15:06
Lowered version number after reproducing with: Ubuntu 14.10 64-bit LibreOffice 3.5.0rc3 Build ID: 7e68ba2-a744ebf-1f241b7-c506db1-7d53735
Created attachment 111936 [details] MSWORD 97-2003 DOC with 3-column TABLE More concise DOC, followed by 2 PNG images to view the differences online between FILEOPEN MSWORD and FILEOPEN LibreOffice Writer.
Created attachment 111937 [details] MSWORD FILEOPEN MSWORD DOC TABLE (IMAGE/PNG) FILEOPEN MSWORD DOC TABLE by MSWORD (IMAGE/PNG)
Created attachment 111938 [details] LIBREOFFICE WRITER FILEOPEN MSWORD DOC TABLE (IMAGE/PNG) FILEOPEN MSWORD DOC TABLE by LibreOffice Writer (IMAGE/PNG)
LIBREOFFICE WRITER FILEOPEN MSWORD DOC TABLE (IMAGE/PNG) The mentioned incorrect 2nd and 3d cell margins of the non-global 1st and 3d table row are in fact the table's global margins (as in the global 2nd row). Non-global 2nd and 3d cell margins don't get imported by LibreOffice Writer.
(In reply to Beluga from comment #4) > I confirm -> NEW. > > Win 7 64-bit Version: 4.4.0.0.alpha1+ > Build ID: 1baad070d8c2a38581cf33d803c5043f1974647f > TinderBox: Win-x86@39, Branch:master, Time: 2014-11-01_00:15:06 Thanks BELUGA!
** 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.4 or later) 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-01-17
Repro with: Version: 5.4.0.0.alpha0+ Build ID: 99eed82939999d9a9689788a4134dd05d5c20c5a CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; TinderBox: Win-x86@42, Branch:master, Time: 2017-01-14_23:37:40 Locale: nl-NL (nl_NL); Calc: CL
(In reply to Telesto from comment #12) > Repro with: > Version: 5.4.0.0.alpha0+ > Build ID: 99eed82939999d9a9689788a4134dd05d5c20c5a > CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; > TinderBox: Win-x86@42, Branch:master, Time: 2017-01-14_23:37:40 > Locale: nl-NL (nl_NL); Calc: CL What is the use of reporting a bug when never ever getting addressed? I solved my issue by defining the global table cell height by the smallest number (being the table header height in my case). This way all table rows with larger height defined in the specific cell options of other table rows (only being defined by LibtrOffice for the first table column cell) get respected.
** 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
This bug is still present with: Versie: 6.1.2.1 (x64) Build ID: 65905a128db06ba48db947242809d14d3f9a93fe CPU-threads: 4; Besturingssysteem: Windows 10.0; UI-render: standaard; Locale: nl-NL (nl_NL); Calc: group threaded
REGRESSION test with LibreOffice 3.3.0.4 Portable; RESULT: NEGATIVE The bug was present with 3.3 - set version to 'inherited from OOo' LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4
Dear Jeroen Hennekes, 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
This bug is still present with: Versie: 6.3.2.2 (x64) Build ID: 98b30e735bda24bc04ab42594c85f7fd8be07b9c CPU-threads: 4; Besturingssysteem: Windows 10.0; UI-render: standaard; VCL: win; Locale: nl-NL (nl_NL); UI-taal: nl-NL Calc: threaded
The support of the default margins and override margins appears to have started with commit af86fa3b49d8de756d530508b7b43e2a19d161fc Author: Caolán McNamara on Date: Thu Jun 13 13:19:07 2002 +0000 #99697# Improve quality of the Frame->Table hack which allows captioned graphics to be included in word's illustration index But there were a few unknowns here, which are the key to this bugfix. void WW8TabBandDesc::ProcessSpecificSpacing(const sal_uInt8* pParams) sal_uInt8 nWhichCell = *pParams++; //THIS SHOULD BE nStartCell ++pParams; //unknown byte //THIS SHOULD BE nEndCell sal_uInt8 nSideBits = *pParams++; sal_uInt8 nUnknown2 = *pParams; //Fts ftsDxa(0x3) or FtsPercent(0x2) Proposed fix at https://gerrit.libreoffice.org/c/core/+/92628
*** Bug 123394 has been marked as a duplicate of this bug. ***
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/623d6cf06ccba392c1993a3b0ad271d508205e73 tdf#73056 doc import: table margins - unknown byte is EndCell It will be available in 7.0.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Hard to believe this bug didn't have more CCs or duplicates. I guess this functionality is hidden away pretty deep in the MS UI. Very tempting to backport this, but not going to because 6.4 is nearly stable and way too far along in testing. Plus it effectively requires the patch for bug 98409 in order to round-trip anyway.
Finally :-) Your work is much appreciated, Justin & others!! (Former Java/C++ developer @ stachanov.com)