Description: Open the attached DOCX. It is completely empty in LibreOffice Writer. However, opening it with NextCloud reveals that this is actually a rather large document: https://nextcloud.inrae.fr/s/zEPjc5SCPaAiGno Maybe the references or the very wide table caused a problem? Steps to Reproduce: 1.request the DOCX from me as I cannot upload it here (Downloading from NextCloud will transform it to another kind of file that is twice as large and does open up in Writer) 2. Open in Writer and stare at the blank page Actual Results: blank page Expected Results: visible document Reproducible: Always User Profile Reset: No Additional Info: Version: 24.2.6.2 (X86_64) / LibreOffice Community Build ID: 8e9a753d9daaea75c34b417ba1bdf556bf2fc5b3 CPU threads: 16; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: en-GB (en_GB.UTF-8); UI: en-GB Calc: threaded
Created attachment 196722 [details] faulty DOCX
(In reply to darrask from comment #0) > Description: > Open the attached DOCX. It is completely empty in LibreOffice Writer. > > However, opening it with NextCloud reveals that this is actually a rather > large document: https://nextcloud.inrae.fr/s/zEPjc5SCPaAiGno > > Maybe the references or the very wide table caused a problem? > > Steps to Reproduce: > 1.request the DOCX from me as I cannot upload it here (Downloading from > NextCloud will transform it to another kind of file that is twice as large > and does open up in Writer) > 2. Open in Writer and stare at the blank page > > Actual Results: > blank page > > Expected Results: > visible document > > > Reproducible: Always > > > User Profile Reset: No > > Additional Info: > Version: 24.2.6.2 (X86_64) / LibreOffice Community > Build ID: 8e9a753d9daaea75c34b417ba1bdf556bf2fc5b3 > CPU threads: 16; OS: Linux 6.8; UI render: default; VCL: gtk3 > Locale: en-GB (en_GB.UTF-8); UI: en-GB > Calc: threaded I found out how to add an attachment
Basically, this is the same as bug 151080 - but here, the altChunk is for HTML, not MTH. Anyway, we don't support yet *any* kind of altChunk content.
Thanks Mike. A warning would be useful so users don't think the file is empty.
In this case, we already support HTML; so, unlike bug 151080, this can be implemented fairly easily - just running a secondary import at each altChunk reference (it's a "one-time conversion facility", as ECMA-376 Part 1 specifies; and it may appear anywhere where a 'p' element is permitted).
The idea of the fix is: during XML parse, when a reference is found, use the "Text from file" function (i.e., similar to what happens in SwView::InsertMedium). This must be implemented as function in writerfilter::dmapper::DomainMapper (and its _Impl).
Created attachment 200167 [details] A minimal valid DOCX+HTML sample
ArsalanKhan04 committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c55ae722661d499cb27bc1f2727bc9873248adc5 tdf#163164 support altChunk referencing HTML in DOCX 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.
Muhammad: feel free to close as fixed.