Bug 166680 - OpenXml nested runs "<w:r>" within a text box do not get rendered
Summary: OpenXml nested runs "<w:r>" within a text box do not get rendered
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
25.2.3.2 release
Hardware: All All
: medium normal
Assignee: Miklos Vajna
URL:
Whiteboard: target:25.8.0 target:25.2.5
Keywords: bibisected, bisected, regression
Depends on:
Blocks:
 
Reported: 2025-05-21 21:46 UTC by Joe Ferner
Modified: 2025-05-29 21:18 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
File which does not render properly (6.67 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2025-05-21 21:47 UTC, Joe Ferner
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Joe Ferner 2025-05-21 21:46:37 UTC
Description:
I have found some Word documents to not render some content in LibreOffice Writer. I narrowed it down to nested runs within a text box. The structure like this does not render the text: wps:txbx -> w:txbxContent -> w:p -> w:r -> w:r -> w:t -> #text

Steps to Reproduce:
Not sure how the documents are initially created but I was able to reproduce doing the follow:

1. Create a new empty document
2. Insert a text box
3. Add some text to the text box
4. Save as Word 2010-365 Document
5. Extract the docx file and edit word/document.xml
6. Find the "<w:r>" wrapping the text you entered and wrap it in another "<w:r>"


Actual Results:
Reopening the modified document in LibreOffice Writer does not render the text. Opening the modified document in Word does.

Expected Results:
The text is rendered as it is rendered in Word.


Reproducible: Always


User Profile Reset: No

Additional Info:
Version: 25.2.3.2 (X86_64) / LibreOffice Community
Build ID: bbb074479178df812d175f709636b368952c2ce3
CPU threads: 16; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded
Comment 1 Joe Ferner 2025-05-21 21:47:34 UTC
Created attachment 200903 [details]
File which does not render properly
Comment 2 Saburo 2025-05-22 10:04:24 UTC
Bisected with linux-43max
author	Miklos Vajna <vmiklos@collabora.co.uk>	2013-12-03 11:59:42 +0100
commit 57450afb768c085df0ba2344aa94b5f843060178

DOCX import: declare wps as a supported feature
This means in case we hit an mc:AlternateContent element, we will read
the mc:Choice branch of it, in case wps is the required feature, not the
mc:Fallback one, which contains the information in VML format (after a
lossy conversion).
Comment 3 Miklos Vajna 2025-05-23 06:55:32 UTC
Oh fun, this was found 12 years later... I'll try to see what's doable here.
Comment 4 Commit Notification 2025-05-28 15:52:52 UTC
Miklos Vajna committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/a414d7d884bc49f6d4028ad2fcf4186998a5a67e

tdf#166680 DOCX import: handle nested <w:r> runs

It will be available in 25.8.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-05-29 21:18:23 UTC
Miklos Vajna committed a patch related to this issue.
It has been pushed to "libreoffice-25-2":

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

tdf#166680 DOCX import: handle nested <w:r> runs

It will be available in 25.2.5.

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.