Created attachment 144752 [details] overlapBorder.docx: just open in LO to see the text overlap the border In this exaggerated example, the text really overlaps the border. In Word, it doesn't overlap. (A side note is that Word has a maximum border width, while LO keeps growing, but that isn't the cause of this overlap, since it also happens at non-maximum border-widths.) Bibisect-43all suggests this is inherited from OOo, and various spot checks indicate that it has never worked. I ran into this when trying to remove the document.xml's tblBorders.
I confirm it with Version: 6.0.6.2 (x64) Build-ID: 0c292870b25a325b5ed35f6b45599d2ea4458e77 CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; Gebietsschema: de-DE (de_DE); Calc: group
Created attachment 144771 [details] table-cell-marginB.docx: table cell A1 DOES determine table position (left only). Modified version of the proof unit test in ooxmlexport10.cxx
Created attachment 145163 [details] table-cell-marginC.docx: test showing how table borders / cell borders affect position (In reply to Justin L from comment #2) > table-cell-marginB.docx: table cell A1 DOES determine table position That might be true in Writer, but in Word it is the last row that determines the column position. (This is getting really ugly, because export also seems to be based on cell A1.)
Created attachment 145164 [details] PDF from word 2016 - last row seems to determine table position.
Created attachment 145165 [details] PDF from word 2003 - first row seems to determine table position. Even worse - MS isn't consistent in this...
proposed fix at https://gerrit.libreoffice.org/60989 tdf#92026 docxexport: eliminate fake tblBorders
Created attachment 145181 [details] overlapBorder_withTblBorders3Row.docx: example document where different MSWord versions look very differently. This example document was just added to show the complexity in working in this area. LO opens it like the modern MSO 2016, which is fine.
Justin Luth committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=fe847dda1751bc2c96ef646baa4f16bcc431c1e3 tdf#119760 writerfilter: cell border priority over tblBorder 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.
it works on 6.2 Version: 6.2.0.0.alpha0+ Build ID: a906b68a9fff30c2af5c03189e59c1952cd3f69f 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-30_19:07:59 Locale: ro-RO (ro_RO.UTF-8); Calc: threaded
(In reply to Justin L from comment #3) > (This is getting really ugly, because export also seems to be > based on cell A1.) The code pointer for this statement comes from commit https://cgit.freedesktop.org/libreoffice/core/commit/?id=9751056ba806ba9614392f3c70ada3cbd1251814
(In reply to Justin L from comment #3) > export also seems to be based on cell A1. I'm re-evaluating this bug in light of CompatibilityMode changing to 15 (from 12), but this export business is irrelevant. The compatibility here comes in only if there are no defaults provided for the table. On export we always set a default by picking one cell (and it doesn't matter which one it is) and use it as the default. Anything that doesn't match that chosen default is explicitly written out. Therefore, whether picking from the first row, last row, or middle row (which probably would be the best actually...) is irrelevant for compatibility.
(In reply to Justin L from comment #11) > The compatibility here comes in only if there are no defaults > provided for the table This is definitely inaccurate, but irrelevant to the discussion anyway. A fix to better position tables in compatibility mode 15 is proposed at https://gerrit.libreoffice.org/c/core/+/91608. It doesn't match this particular bug, but it is related.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/d2db4bc9507653a46fdea282d41b9683910a072f tdf#119760 docx: table starts at left, not mid-border 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.