Description: Bullets become red (font color) after save & reload Steps to Reproduce: 1. Open the attached file 2. Press Enter after World 3. Type say AAA 4. Press Enter again 5. Type say BBB 6. Save 7. Reload Actual Results: Last to bullets becoming red Expected Results: Black as on screen (only font color) Reproducible: Always User Profile Reset: No Additional Info: Version: 7.1.0.0.alpha0+ (x64) Build ID: e8b8e7be0b2ad693224cd94062a55610eb69df7e CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL
Created attachment 165217 [details] Example file
LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4
Confirm with Version: 6.4.3.2 Build ID: 747b5d0ebf89f41c860ec2a39efd7cb15b54f2d8 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3; Locale: ro-RO (ro_RO.UTF-8); UI-Language: en-US Calc: CL
repro 7.2+. See bug 131785 for a related discussion. It seems like the bullet SHOULD be RED right away for the new content being typed.
Very interesting. "Fixed" in LO 7.4 because now the text colour is not copied when pressing Enter - at least not in this particular document. commit 71019ec15bd3fe15385443b68614fd2402e0040f Author: Miklos Vajna on Fri May 6 2022 sw: don't copy useless char escapement to next node on split However,if we simply make the text bold first, then the problem still remains...
The reason the bullet turns red is because the entire paragraph has the same red character format. You can thank Microsoft for that oddity (although to be fair, they only do that when the CR is formatted in Red. Since LO can't format the CR, it approximates by taking char runs that apply to the whole paragraph).
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/a4d011fb8ae24f90375744af5e98ba81716a22cb related tdf#136536 sw: don't copy useless char escapement to next node on split It will be available in 7.6.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.
Still exists in LO 7.6 dev under Windows 10(x64). Version: 7.6.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 975590e69edfa351ef20a0973a5005ca49d08edc CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: en-IN (en_IN); UI: en-US Calc: threaded
repro 24.8+
While editing the document, this red colour is simply a direct formatting character colour (because the internal paragraph style it came from did not define font colour). Upon saving, it must notice that the entire paragraph has the same font colour, and so it transfers that to the paragraph style. Thus at load time, the paragraph style colour is applied to the list number/bullet. The same principle applies during editing as well. If you select the entire paragraph and set the font colour, then the font colour is applied to the paragraph style (and immediately gets applied to the list). Obviously we don't want a simple carriage return at the end of a paragraph to automatically convert the direct character formatting into a new paragraph style right away. Another set of "steps to reproduce" would be to hit enter after "Holle Wo". After a round-trip, the last bullet point will become yellow. The same principle applies: the new paragraph "rld" had every character with the same yellow attribute, so on save it exported that colour into the automatic paragraph style. Once again, I can't imagine that it would be smart to have LO analyse both "new" paragraphs and immediately reconfigure their automatic paragraph styles. So, any attempt to "fix" this bug report will have to focus on the export process. Why would LO not simply export the automatic styles as they are instead of "optimizing"? (It is worth noting that this "optimization" does NOT affect the in-memory document - it still uses the old styles.) I would have to imagine that making changes to the export process will have many unintended ramifications...
Created attachment 195101 [details] 136536_character2paragraphStyleOnImport.odt: clean-room version (no previous history as DOCX format) (In reply to Justin L from comment #10) > any attempt to "fix" this bug report will have to focus on the export process. Actually, it must be the import process. > Why would LO not simply export the automatic styles as they are > instead of "optimizing"? It doesn't. It must happen on import. The first export only defines P1, as well as T1 and T2. But if you reload and then resave immediately, then the second export defines P1 and P2, as well as only T1.
From what I can see in xmloff/source/text/txtimp.cxx: XMLTextImportHelper::SetStyleAndAttrs, import does NOT try to reproduce the same internal styles at all. It just uses that information and sets the properties on the appropriate nodes. So the style name is set to "Standard" (aka Default Paragraph Style) and not P1. What happens from there is just simple SW internals to convert into dynamic autostyles. The same is true for character styles. sw/source/core/unocore/unoobj.cxx SetPropertyValue("CharAutoStyleName", "T1") sw/source/core/txtnode/thints.cxx SwTextNode::SetAttr // entire paragraph // If there are any character attributes in rSet, // we want to set them at the paragraph: if ( const SwFormatAutoFormat* pItem = aTextSet.GetItemIfSet( RES_TXTATR_AUTOFMT, false ) ) const bool bRet = SetAttr( *pItem->GetStyleHandle() ); // puts the whole attrset of the charAutoStyle into the paragraph style, and calls GetNewAutoStyle So then, this "bug" is all caused by the "normal" process of consolidating whole-paragraph-character-attributes into the paraAutoStyle during a SetPropertyValue(). Really sounds like a WONTFIX to me.