Bug 118812 - FILEOPEN: Direct formatting overwriting style in DOCX tables, wrong spacing
Summary: FILEOPEN: Direct formatting overwriting style in DOCX tables, wrong spacing
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: László Németh
URL:
Whiteboard: target:7.0.0
Keywords: filter:docx
: 127000 127615 134720 (view as bug list)
Depends on:
Blocks: DOCX-Tables
  Show dependency treegraph
 
Reported: 2018-07-17 20:38 UTC by Luke
Modified: 2020-07-27 10:49 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Comparison of table in Word vs Writer (100.53 KB, image/png)
2018-07-17 20:38 UTC, Luke
Details
tdf118812_tableStyle.docx: hand-crafted example with inherited styles, normal, default styles (11.35 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2018-07-21 09:22 UTC, Justin L
Details
tdf118812_tableStyle.docx_word2003.pdf (15.87 KB, application/pdf)
2018-07-21 09:23 UTC, Justin L
Details
ugly patch that "works" for comment 0's example, but not comment 2 (4.32 KB, patch)
2018-07-21 09:44 UTC, Justin L
Details
tdf118812_tableStyle.doc: hand-crafted example with inherited styles, normal, default styles (27.50 KB, application/msword)
2019-02-03 20:50 UTC, Luke
Details
Screenshot of the example file in Word and Writer master (53.47 KB, image/png)
2019-10-07 11:29 UTC, Gabor Kelemen
Details
tdf118812_tableStyles-comprehensive.docx: shows lots of import flaws (12.09 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2019-10-09 09:23 UTC, Justin L
Details
tdf118812_tableStyles-comprehensive_word2016.pdf: MSWord 2016 (231.16 KB, application/pdf)
2019-10-09 09:28 UTC, Justin L
Details
tdf118812_tableStyles-comprehensive_word2003.pdf: similar, but not identical to MSO2016 (25.64 KB, application/pdf)
2019-10-09 09:30 UTC, Justin L
Details
tdf118812_tableStyles-comprehensive_LO64.pdf: current state in LO (20.23 KB, application/pdf)
2019-10-09 09:33 UTC, Justin L
Details
Screenshot of the document in recent 6.5 master (92.77 KB, image/png)
2020-01-15 07:48 UTC, NISZ LibreOffice Team
Details
Screenshot of the tableStyles-comprehensive docx in current master (210.01 KB, image/png)
2020-02-04 07:59 UTC, NISZ LibreOffice Team
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Luke 2018-07-17 20:38:43 UTC
Created attachment 143610 [details]
Comparison of table in Word vs Writer

The direct formatting appears to be interfering with docx table styles. 

Steps to reproduce:
1. Open attachment 107350 [details] in Writer

Expected results
Importer should honor:
Intense Quote style ->  Paragraph -> Spacing Below -> 18pt
 

Note: it honors 
Intense Quote style ->  Paragraph -> Spacing Above -> 18pt

In writer, selecting the table and "clear direct format" resolves this issue.
Comment 1 Luke 2018-07-20 05:04:17 UTC
The direct formatting variant of this issue was fixed by: https://cgit.freedesktop.org/libreoffice/core/commit/?id=5e4d89f59614cec08376e1e77625f8610a1490e5

tdf#117297 sw unotbl XCell: apply char/para style props to text
Comment 2 Justin L 2018-07-21 09:22:06 UTC
Created attachment 143668 [details]
tdf118812_tableStyle.docx: hand-crafted example with inherited styles, normal, default styles

This example file frustrated my efforts to come up with a working fix - i.e. a good test example.

1.) table styles seem to only overwrite document defaults. If the paragraph style (including the default style) defines w:spacing, that wins out over table style.
2.) direct paragraph formatting of course wins out over everything.

So, one key here I think is to devise a way for writerfilter to distinguish between "assigned to the style somewhere" and "document default" values.

And likely bug 117297 has made things worse, because almost every paragraph seemed to have the property as DIRECT_VALUE which prevents any check against the style.
Comment 3 Justin L 2018-07-21 09:23:02 UTC
Created attachment 143669 [details]
tdf118812_tableStyle.docx_word2003.pdf
Comment 4 Justin L 2018-07-21 09:44:59 UTC
Created attachment 143670 [details]
ugly patch that "works" for comment 0's example, but not comment 2
Comment 5 Luke 2019-02-03 20:50:53 UTC
Created attachment 148876 [details]
tdf118812_tableStyle.doc: hand-crafted example with inherited styles, normal, default styles

The [MS-DOC] importer correctly handles your mixed case, so it's an importer issue only.
Comment 6 Justin L 2019-09-02 17:36:48 UTC
*** Bug 127000 has been marked as a duplicate of this bug. ***
Comment 7 Justin L 2019-09-24 10:55:05 UTC
*** Bug 127615 has been marked as a duplicate of this bug. ***
Comment 8 Luke 2019-10-04 00:16:13 UTC
Miklos has made some improvements in this area:

https://cgit.freedesktop.org/libreoffice/core/commit/?id=c424a1f509205cfbaa3421bddfd6514b340a798a
Comment 9 Gabor Kelemen 2019-10-07 11:29:22 UTC
Created attachment 154795 [details]
Screenshot of the example file in Word and Writer master

In a current build the original attachment looks still the same, unfortunately:

Verzió: 6.4.0.0.alpha0+ (x64)
Build az.: 751a89b9d120eccc6c4b53e3b398149f29c79ed9
CPU szálak: 8; OS: Windows 10.0; Felületmegjelenítés: GL; VCL: win; 
Területi beállítások: hu-HU (hu_HU); Felület nyelve: hu-HU
Calc: CL
Comment 10 Justin L 2019-10-07 17:22:25 UTC
(In reply to Luke from comment #8)
> Miklos has made some improvements in this area:
It almost worked. It needed improvements in two areas.
1.) if the node has no attributes, then don't apply the setting IF you are searching the parents - (!bHasAttrSet && !bSearchInParent).
2.) bottom_margin was handled separately as a hack, so DomainMapperTableHandler's lcl_ApplyCellParaProps should be removed.

There are still at least two cases which I have no idea how to fix. One is in duplicate bug 127615 - where only the top_margin is set.  The settings of top_margin, bottom_margin, and context and bundled together into a single setting inside of LO. If ANY one of those three are set, the item is created and therefore the other two items are considered to be SET (even without finishParagraph explicitly resetting them).

The other case is where a style is applied, but the setting itself comes from the defaults. That is seen in ooxmlexport11's tdf64264.docx.
Comment 11 Justin L 2019-10-09 09:23:40 UTC
Created attachment 154853 [details]
tdf118812_tableStyles-comprehensive.docx: shows lots of import flaws

(In reply to Justin L from comment #10)
> It almost worked. It needed improvements in two areas.
Well, this example document shows that everything is still fundamentally flawed. Perhaps only flawed results are possible since there are so many complicating factors, and the improvements are just "best effort at practical improvement".
Well, actually there are still LOTS of areas that need improvement. These grouped properties cause a LOT of problems. Also, I believe that default properties are merged into the -none-inheritance styles which is bad because 

So things to fix:
1.) Apply Doc Defaults ONLY to the internal "Paragraph style". The problem here comes during export to .odt and perhaps others. See bug 103961c15
2.) In MSO, table styles DO NOT override the Normal/Default paragraph style settings. They only override DocDefaults (and character size + ??? for certain compatibility states). So Miklos' fix brings us closer in a practical sense, but comments should indicate TODOs necessary.
3.) Somehow we need a way to find out if a grouped property was really SET or just created - for the benefit of importing foreign documents.
4.) Search the numbering style for properties too.
Comment 12 Justin L 2019-10-09 09:28:57 UTC
Created attachment 154855 [details]
tdf118812_tableStyles-comprehensive_word2016.pdf: MSWord 2016

This opened in compatibility mode. When converting to normal mode, the table style DID NOT override the Default Style's font size.
Comment 13 Justin L 2019-10-09 09:30:11 UTC
Created attachment 154856 [details]
tdf118812_tableStyles-comprehensive_word2003.pdf: similar, but not identical to MSO2016
Comment 14 Justin L 2019-10-09 09:33:04 UTC
Created attachment 154857 [details]
tdf118812_tableStyles-comprehensive_LO64.pdf: current state in LO
Comment 15 NISZ LibreOffice Team 2020-01-15 07:48:28 UTC
Created attachment 157158 [details]
Screenshot of the document in recent 6.5 master

tdf118812_tableStyles-comprehensive.docx Looks much better in:

Version: 6.5.0.0.alpha0+ (x64)
Build ID: d122a9d12d970d55f4dc9e4268e0681fd2e6786f
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: GL; VCL: win; 
Locale: en-US (hu_HU); UI-Language: en-US
Calc: CL

Maybe the table style does not override the para style, or somesuch, which causes the larger font sizes and general increase of the table height. But we are waaaay better since the previous comment - thanks everyone :).

Also the originally reported problem seen on attachment #143610 [details] is fixed since bug #119054 was fixed.
Comment 16 NISZ LibreOffice Team 2020-02-04 07:59:54 UTC
Created attachment 157631 [details]
Screenshot of the tableStyles-comprehensive docx in current master

Seems like the 8 pt font size here is taken from the table style in Word (but not the font color), and from the paragraph style in Writer. Other settings seem to be applied correctly.

Version: 7.0.0.0.alpha0+ (x64)
Build ID: ee9a15422561dfae0ae259c1641695f6c5c41388
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win; 
Locale: en-US (hu_HU); UI-Language: en-US
Calc: CL
Comment 17 Justin L 2020-02-04 11:27:14 UTC
(In reply to NISZ LibreOffice Team from comment #16)
> Seems like the 8 pt font size here is taken from the table style in Word
> (but not the font color), and from the paragraph style in Writer.
Fontsize is very tricky with table styles, because of this compat setting:
---------------------------------------------------------------
2.3.1 overrideTableStyleFontSizeAndJustification

A compatSetting element whose name attribute has the value "overrideTableStyleFontSizeAndJustification" and whose uri attribute has the value "http://schemas.microsoft.com/office/word" specifies how the style hierarchy of the document is evaluated.

If this value is true, then the style hierarchy of the document is evaluated as specified in [ISO/IEC29500-1:2016] section 17.7.2.

If this value is false, which is the default, then the following additional rules apply:

    If the default paragraph style (as specified in [ISO/IEC29500-1:2016] section 17.7.4.17) specifies a font size of 11pt or 12pt, then that setting will not override the font size specified by the table style for paragraphs in tables.

    If the default paragraph style (as specified in [ISO/IEC29500-1:2016] section 17.7.4.17) specifies a justification of left, then that setting will not override the justification specified by the table style for paragraphs in tables.
---------------------------------------------------------------
Things get very interesting if the table style itself does not specify a fontsize, but a docDefault does.  In that case, the tableStyle apparently picks up the docDefault fontsize and seems to consider it part of the tableStyle specifications. So in the compatible case:
1.) even though the tableStyle has no fontsize property, it ought to pick up the docDefault size of 8.
2.) if the default style has a fontsize of 11 or 12, then the 8pt tableStyle will win out (only in the compatible mode).

So it seems like we ought to merge the table style with docDefaults properties before evaluating anything. In the non-compatible case, we would match or be overridden by style properties. In the compatible case, we can override left-justification or fontsize11/12.
Comment 18 Commit Notification 2020-02-19 15:47:58 UTC
László Németh committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/4d5c0eaf3e0d3d3bcd9e691fffee19b75f3d6631

tdf#118812 DOCX import: fix table style preference – part 2

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.
Comment 19 László Németh 2020-02-19 16:06:06 UTC
Fixed in master. For default MSO interoperability, the fix uses overrideTableStyleFontSizeAndJustification=false mode in the case of font sizes, see in tdf118812_tableStyles-comprehensive.docx.

The exception for the justification will be handled in a new test document/bug report, also support of overrideTableStyleFontSizeAndJustification=true.
Comment 20 Commit Notification 2020-03-20 08:16:21 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/65bea6cbe772ef2ab840d507307396b74e8d031e

tdf#118812 writerfilter: overrideTableStyleFontSizeAndJustification

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.
Comment 21 Xisco Faulí 2020-07-24 11:19:42 UTC
*** Bug 134720 has been marked as a duplicate of this bug. ***