Bug 168325 - ODF: questionable markup for character style change tracking
Summary: ODF: questionable markup for character style change tracking
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
26.2.0.0 alpha0+ master
Hardware: All All
: medium normal
Assignee: Miklos Vajna
URL:
Whiteboard: target:26.2.0 target:25.8.3
Keywords:
Depends on:
Blocks: Track-Changes-TextFormatting
  Show dependency treegraph
 
Reported: 2025-09-08 20:54 UTC by Regina Henschel
Modified: 2025-09-18 21:00 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Regina Henschel 2025-09-08 20:54:31 UTC
Start a text document and write some text.
Apply a character style (not direct formatting) to a word, e.g. `Emphasis`.
Enable recording change tracking (menu Edit > Track changes).
Apply a different character style to the same word, e.g. `Strong Emphasis`.
Save the document.

Examine the part content.xml. Find the element <text:format-change>, child of element <text:changed-region> in element <text:tracked-changes>.
The element <text:format-change> has an attribute loext:style-name, whose value points to an automatic style, likely `T1`. The purpose of the attribute loext:style-name is to backup the style, that was applied to the portion of text before its format was changed. Thus the expected value is the common style `Emphasis`.

LibreOffice corrects the faulty value on opening the document, so that you get indeed `Emphasis` at the text portion when you reject the change. But the file format should correctly reflect the situation. And that was, that the portion has no direct formatting but a common style applied.

Creating an automatic style in this situation is not needed at all. If you delete the automatic style and set `Emphasis` as value to the loext:style-name, then LibreOffice opens the file without problems and you can reject or accept the tracked change.
Comment 1 Miklos Vajna 2025-09-09 08:56:14 UTC
Interesting, thanks for the report. I can reproduce this. Note that sw/qa/filter/xml/data/format-char-style-change.odt is a very similar case, switching from Strong (~bold) to Quote (~italic) and that doesn't have this behavior. So the intent is already what you describe (no automatic style if possible), but you found a case where this is not happening.
Comment 2 Regina Henschel 2025-09-09 10:28:11 UTC
I have noticed the problem, when I made changes to the default styles and when I use an own style.
Comment 3 Miklos Vajna 2025-09-12 13:16:20 UTC
I see, I'll take a look.
Comment 4 Commit Notification 2025-09-18 13:57:09 UTC
Miklos Vajna committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/0c7eaa023a840a6f0967fe119463a936241a8130

tdf#168325 sw format redline, char style: improve recording

It will be available in 26.2.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 5 Commit Notification 2025-09-18 21:00:20 UTC
Miklos Vajna committed a patch related to this issue.
It has been pushed to "libreoffice-25-8":

https://git.libreoffice.org/core/commit/1f6b2a4d6db61f0ae0f00774b3104cf679c3db4d

tdf#168325 sw format redline, char style: improve recording

It will be available in 25.8.3.

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.