diff options
author | Miklos Vajna <vmiklos@collabora.com> | 2022-12-16 10:31:03 +0100 |
---|---|---|
committer | Miklos Vajna <vmiklos@collabora.com> | 2022-12-16 11:32:33 +0000 |
commit | 99ed51bcad4008a4006dcec24aa33fd7f757a433 (patch) | |
tree | 110339e1127b55bb81fabaa2b25608e9ad4381ee /sw/qa/core/text/text.cxx | |
parent | 56ab74cdf90880dbf756c6ee32135a02a98a6ec7 (diff) |
sw, numbering portion format: ignore char formats covering the entire paragraph
The bugdoc has a single paragraph, where the numbering portion is bold
in Writer but not in Word.
The reason for this appears to be that Writer considers text node hints
for the formatting of the numbering portion where the hint covers the
entire paragraph, but Word doesn't do this. This behavior was added in
commits cb0e1b52d68aa6d5b505f91cb4ce577f7f3b2a8f (sw, numbering portion
format: consider full-para char formats as well, 2022-10-20) and DOCX
export was also adjusted in commit
f546f7573158e52359bbeae6194a83a1ff8ac52c (DOCX export, numbering portion
format: consider full-para char formats as well, 2022-10-28).
Fix the problem by partially reverting the above two commits and instead
only consider hints that both start and end at the paragraph end. The
revert of the first commit fixes the new bugdoc (its numbering portion
is no longer bold) and the old bugdoc keeps working if the sw UNO API's
text portion enumeration is extended to expose such empty autoformats at
paragraph end.
Related testcases:
- CppunitTest_sw_ooxmlexport13's testTdf123460 explicitly tested that we
don't expose the paragraph marker's formatting on the UNO API.
- CppunitTest_sw_core_text's testNumberPortionFormat now uses the new
ODT markup for these explicit paragraph marker char props (empty text
span at para end).
- CppunitTest_sw_uiwriter2's testTdfChangeNumberingListAutoFormat failed
when only the above first commit (layout) was reverted, so revert the
matching DOCX export commit as well, which is also good for consistency.
- CppunitTest_sw_ooxmlexport18's testNumberPortionFormatFromODT also
used the old ODT markup, updated.
Change-Id: Iee8acf72dabcd10b3f4d3d68b83ed248bf50c324
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144292
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Diffstat (limited to 'sw/qa/core/text/text.cxx')
-rw-r--r-- | sw/qa/core/text/text.cxx | 18 |
1 files changed, 18 insertions, 0 deletions
diff --git a/sw/qa/core/text/text.cxx b/sw/qa/core/text/text.cxx index be21eaaee182..db1895b795c0 100644 --- a/sw/qa/core/text/text.cxx +++ b/sw/qa/core/text/text.cxx @@ -862,6 +862,24 @@ CPPUNIT_TEST_FIXTURE(SwCoreTextTest, testNumberPortionFormat) "font-height", "480"); } +CPPUNIT_TEST_FIXTURE(SwCoreTextTest, testNumberPortionNoformat) +{ + // Given a document with a numbering and a single paragraph, the entire run is red: + createSwDoc("number-portion-noformat.docx"); + + // When laying out that document: + xmlDocUniquePtr pXmlDoc = parseLayoutDump(); + + // Then make sure that just because the entire run is red, the numbering portion is not red: + // Without the accompanying fix in place, this test would have failed with: + // - Expected: ffffffff (COL_AUTO) + // - Actual : 00ff0000 (COL_LIGHTRED) + // i.e. the run color affected the color of the number portion in Writer, but not in Word. + CPPUNIT_ASSERT_EQUAL( + OUString("ffffffff"), + getXPath(pXmlDoc, "//SwParaPortion/SwLineLayout/SwFieldPortion", "font-color")); +} + CPPUNIT_PLUGIN_IMPLEMENT(); /* vim:set shiftwidth=4 softtabstop=4 expandtab: */ |