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.
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
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.
Created attachment 143669 [details] tdf118812_tableStyle.docx_word2003.pdf
Created attachment 143670 [details] ugly patch that "works" for comment 0's example, but not comment 2
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.
*** Bug 127000 has been marked as a duplicate of this bug. ***
*** Bug 127615 has been marked as a duplicate of this bug. ***
Miklos has made some improvements in this area: https://cgit.freedesktop.org/libreoffice/core/commit/?id=c424a1f509205cfbaa3421bddfd6514b340a798a
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
(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.
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.
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.
Created attachment 154856 [details] tdf118812_tableStyles-comprehensive_word2003.pdf: similar, but not identical to MSO2016
Created attachment 154857 [details] tdf118812_tableStyles-comprehensive_LO64.pdf: current state in LO
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.
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
(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.
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.
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.
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.
*** Bug 134720 has been marked as a duplicate of this bug. ***