Open and save attachment 115291 [details] from bug 91061 back to DOCX, then try opening it in Word. => Word fails to open the file cleanly. Observed using LO 25.8.0.0.alpha0+ (736998ccef0bacdd2bbf038c98dacfbe654f1a4d) / Windows. If one: - unzips the saved DOCX, - executes the following command (can be done in Linux/Cygwin, needs xmllint installed): find . -name "*.xml" -type f -exec xmllint --output '{}' --format '{}' \; - rezips the result with .docx extension ...then Word points to line 204 of /word/document.xml, which is the end of an <a:custGeom> element. The element has lots of shape guides/gluepoints. This is a regression from the following commit in 25.8 (and its 25.2 backport): https://git.libreoffice.org/core/commit/86d36ee56521438069504fbacff8dc2aff3a1afc https://cgit.freedesktop.org/libreoffice/core/commit/?id=86d36ee56521438069504fbacff8dc2aff3a1afc author Tibor Nagy <tibor.nagy.extern@allotropia.de> Sun Feb 23 21:35:17 2025 +0100 committer Nagy Tibor <tibor.nagy.extern@allotropia.de> Mon Feb 24 14:22:14 2025 +0100 "tdf165262 PPTX export: fix shape export regression" Those suspicious gluepoints aren't there when exported from a build preceding the regressing commit. Based on basic research, it looks like "logwidth" isn't an allowed formula element for shape guides, eg.: <a:gd name="GluePoint1Y" fmla="3048002*logwidth/6096000"/> List of test files regressing from the same commit: fdo75230-1.docx fdo83227-3.docx forum-mso-en-11007.docx forum-mso-en-12264.docx forum-mso-en-12822.docx forum-mso-en-16347.docx forum-mso-en-16497.docx forum-mso-en-17960.docx forum-mso-en-3360.docx forum-mso-en-4455.docx forum-mso-en-4463.docx forum-mso-en-4464.docx forum-mso-en4-598647.docx forum-mso-en4-746483.docx forum-mso-en4-771610.docx forum-mso-en-5509.docx forum-mso-en-5558.docx forum-mso-en-6088.docx forum-mso-en-970.docx forum-mso-en-974.docx ooo123731-1.docx tdf91061-1.docx
17 PPTX files as well: fdo46987-1.pptx fdo49299-2.pptx forum-mso-de-71272.pptx forum-mso-en-5867.pptx moz1121066-2.pptx moz1121068-2.pptx moz1164516-1.pptx novell742593-1.pptx ooo121597-1.pptx tdf100390-3.pptx tdf106011-1.pptx tdf111857-4.pptx tdf126572-3.pptx tdf59019-6.pptx tdf65724-6.pptx tdf90898-4.pptx tdf92076-2.pptx
And some more. These first started crashing from the regressing commit in the description. The following commit fixed the crash, but the result files are corrupted: https://git.libreoffice.org/core/commit/61e1e38595e95e228168e8385662fe3bcd4c80e1 author Caolán McNamara <caolan.mcnamara@collabora.com> Sun Apr 06 15:34:03 2025 +0100 committer Caolán McNamara <caolan.mcnamara@collabora.com> Sun Apr 06 18:24:16 2025 +0200 crashtesting: out of bounds in export of tdf128404-1.ppt to pptx fdo40483-1.pptx fdo56864-1.pptx forum-mso-de-136104.pptx kde286114-1.pptx kde334850-1.pptx novell347597-1.pptx ooo119582-1.pptx ooo119583-1.pptx ooo119584-1.pptx rhbz615970-1.pptx tdf112868-1.pptx tdf127396-1.pptx tdf128404-1.pptx tdf136754-2.pptx tdf95345-1.pptx
Created attachment 201482 [details] Simple repro case
Created attachment 201483 [details] Simple repro case, after round-trip
Created attachment 201484 [details] Partial repro case
Created attachment 201485 [details] Partial repro case, after round-trip in version before issue
Created attachment 201486 [details] Partial repro case, after round-trip in version with issue
Created attachment 201487 [details] Partial repro case, after round-trip in version after issue partially resolved
I'm having what I believe to be this issue, and figured I should post what I've found in my investigation in case it's at all helpful for y'all to fix this. To reproduce: * Open attachment 201482 [details] in LO * Resave as DOCX: attachment 201483 [details] * Attempt to open in Word Error message: We're sorry. We can't open repro_post_25.2.4.3.docx because we found a problem with its contents. The parameter is incorrect. Location: Part: /word/document.xml, Line: 0, Column: 0 I've reproduced the error in: 25.2.2.2, 25.2.3.2, 25.2.4.3, 25.8.0.0.beta1, and the latest nightly (2025-06-26_05.47.46). This document works without error in 25.2.1.2 In working to reproduce this, I have another doc that failed in 25.2.2.2, but _works_ in 25.2.3.2 * Source doc attachment 201484 [details] * Round trip through 25.2.1.2 (works) attachment 201484 [details] * Round trip through 25.2.2.2 (fails) attachment 201485 [details] * Round trip through 25.2.3.2 (works) attachment 201486 [details] So I believe that this issue was introduced in 25.2.2.2 and was _partially_ resolved in 25.2.3.2, but in part still remains. I'm not sure exactly what the cause is, I tried poking around inside the XML but I'm way over my head there. I did notice that, in the doc that is still failing, there are <a:gd> elements with a formula that starts with +- while in the doc that is now working, all the <a:gd> elements start with */ ... and this seems to be consistent with the documents I've checked from customers reporting issues, all the ones that are still failing contain +- formulas. I couldn't begin to tell you what that means, though, I just hope it's useful info.
repro 26.2+
I did my testing with comment 0's 'CV_all_pages_not_opening.docx' attachment 115291 [details] (In reply to Aron Budea from comment #0) > Based on basic research, it looks like "logwidth" isn't an allowed formula > element for shape guides, eg.: > <a:gd name="GluePoint1Y" fmla="3048002*logwidth/6096000"/> logwidth is not being output now - probably not since bug 170035. '*logwidth/' is just a placeholder that gets replaced by 'w' (or 'h' for *logheight/). At the time of comment 0's identified commit, we were getting a possible divide-by-zero formula - which OUGHT to be considered invalid, but apparently MSOffice doesn't complain about these cases. <a:gd name="GluePoint1X" fmla="*/ 4800.50314993438 w 0"/> So a remaining problem is having an empty formula <a:gd name="GluePoint1Y" fmla=""/> which is happening because nIdx2 is always 0 (why?). aEquations[0] is 3048002*logwidth/6096000 so the GetFormula is empty because nIdx2 is replacing for logheight, not logwidth. Also, in unit test tdf123435.docx, we are getting NOT IsValidOOXMLFormula from formulas like '?0 *logwidth/3960' and '?2 *logwidth/3960'.
fdo83227-3.docx skipping nIdx1[5] because formula[?4 *logwidth/213] is empty. nIdx2[725*logheight/395] ?4 not a gluepoint. 19.171 draw:formula says that "?f4" means the variable f4. "A "?" (U+003F, QUESTION MARK) is used to mark the beginning of a formula name." It appears that this is being transformed into simply ?4 etc. I'd guess that what needs to happens is that aEquation[4] needs to be evaluated to produce a number. -------------------------------------------------------------------------------- fdo75230-1.docx <a:gd name="GluePoint1X" fmla=""/> X and Y. skipping nIdx1[0] because formula[logwidth/2] is empty [because the search/replace is for *logwidth/]. logwidth stands for 'logical width'.] I'd guess that what needs to happens is that we also need to: 'logwidth/2' -> '*/ 1 w 2' 'logwidth' -> '*/ 1 w 1' -or- 'val w'
justin.luth@collabora.com committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/efeee389064ae7d56020fdbfe38a5e9cb48bc016 tdf#166335 oox export: don't export invalid gluepoint fmla It will be available in 26.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.
justin.luth@collabora.com committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/eb0f75e3140952179edf3be53000e67a8a20a11e follow-up tdf#166335: concern about 'correctness' and cleanup It will be available in 26.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.
justin.luth@collabora.com committed a patch related to this issue. It has been pushed to "libreoffice-26-2": https://git.libreoffice.org/core/commit/cbc677310acf205cd4f6efd1fe1667b9c0f090a9 tdf#166335 oox export: don't export invalid gluepoint fmla It will be available in 26.2.1. 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.
The error still seems to be happening in the nightly... tested in the 2026-01-17_03.41.36 Linux build of 25.8.0.0.alpha0 Opened attachment 201482 [details], save to ODT, reopen, save to DOCX, Word refuses to open it. Still the same error message: "The parameter is incorrect"
Wait, no, I think I was using the wrong nightly... I'd installed the nightly from the 15th to test it was still reproducible, and then installed the nightly from the 17th to see if it had been fixed, and I don't think I switched versions properly, I was probably still testing the build from the 15th. Having resolved that, I can confirm that in the nightly from the 15th it is still reproducible, and in the nightly from the 17th (and also the one from the 18th) it is resolved. Thank you so much!
Created attachment 205283 [details] kde239786-1.ods : out of range indexes when saving as XLSX My patch asserted that an EQUATION would always have a valid index. Sadly, this turns out not to be true - in a disastrous way. I'll try to describe the problem, but I might not be very accurate... kde239786-1.ods is a decent example. Although a complex document, the first set of equations (size 17) exhibits the problem (equation list grows to size 20, and has a gluepoint that tries to reference index 17 from the non-grown list). When exporting as XLSX, we hit an assert at filter/source/msfilter/escherex.cxx OSL_ASSERT(nIndex < rEquationOrder.size()); // nIndex == 17, size = 17 This is related to EnhancedCustomShapeFunctionParser.cxx. It does all kinds of complex stuff. Sometimes it creates two (or more) equations for every equation that it parses. This of course enlarges ConvertEnhancedCustomShapeEquation's rEquations so that it is larger than rEquationOrder. There is some kind of attempt to mitigate that at the end of the function which I didn't understand at all. Perhaps the same kind of mitigation needs to be done with the gluePoint's references to the equations. One key line to investigate is escherex's drawing::EnhancedCustomShapeParameter aPara( aExpressNode->fillNode( rEquations, nullptr, 0 ) ); which leads to a whole world of insane complexity. So the problem seems to be that equation and gluepoint references point to the parsed array of equations, but DrawingML::WriteCustomGeometry's aEquationSeq is the original, unparsed array of equations.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/d78b115d48156b2fd91216877f3525722683f1bb tdf#166335 followup: remove assert - gluePoint indexes are ~random It will be available in 26.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.