I had this noted from some earlier investigation:
What sdkjs-ooxml is
It's a separate sibling repository merged in at build time as a Grunt addon — exactly like sdkjs-forms (which is present in your tree), but sdkjs-ooxml is not in your checkout.
The addon mechanism (build/Gruntfile.js:65) resolves each --addon to a sibling dir (../../sdkjs-ooxml) and merges its configs/*.json file lists into the main word/cell/slide/visio bundles. So the addon ships extra source files that get compiled into the SDK.
What it provides
- Client-side (in-browser) OOXML XML reading and writing. The core sdkjs you have only speaks ONLYOFFICE's internal binary format; all conversion to/from real .docx/.xlsx/.pptx/.vsdx XML is done server-side by the C++ FileConverter. The sdkjs-ooxml addon adds the fromXml/toXml/readChildXml methods and SerializeXml.js files (referenced in comments at visio/model/VisioDocument.js:212 and common/Drawings/Format/Format.js:9627) that let the browser parse and emit OOXML XML directly.
- It's gated at runtime by a feature flag — the addon registers Asc.Addons.ooxml = true, and code checks it via asc_isSupportFeature("ooxml") (common/apiBase.js:5202). sdkjs-forms does the
identical thing (sdkjs-forms/api.js:38), which confirms the pattern.
What you lose without it
Everywhere the flag is checked, the code has a working fallback to the standard server-conversion pipeline:
- apiBase.js:1349 / 2201 / 3143 — "open OOXML directly in browser" (isOpenOOXInBrowser) and the convertToOrigin path that avoids a redundant ooxml→ooxml server roundtrip. Without the addon, the
document is opened via the normal binary conversion instead.
- pdf/src/document.js (commit b920c61 "use ooxml if supported") — client-side parsing of PDF-form page-shape XML; falls back otherwise.
- Some Visio (.vsdx) client-side XML parsing.
- The word/custom-xml/custom-xml-ooxml.html test — already explicitly skipped in tests/runAll.js:96 with the note "needs the sdkjs-ooxml addon, which is not available in CI yet."
Summary
No end-user editing functionality is lost. Opening, editing, and saving docx/xlsx/pptx/vsdx all still work through the C++ converter — that's the normal upstream open-source behavior. What sdkjs-ooxml adds is a performance/architecture optimization: doing OOXML serialization in the browser to skip server conversion roundtrips, plus enabling that one custom-xml test path.
I had this noted from some earlier investigation:
What sdkjs-ooxml is
It's a separate sibling repository merged in at build time as a Grunt addon — exactly like sdkjs-forms (which is present in your tree), but sdkjs-ooxml is not in your checkout.
The addon mechanism (build/Gruntfile.js:65) resolves each --addon to a sibling dir (../../sdkjs-ooxml) and merges its configs/*.json file lists into the main word/cell/slide/visio bundles. So the addon ships extra source files that get compiled into the SDK.
What it provides
identical thing (sdkjs-forms/api.js:38), which confirms the pattern.
What you lose without it
Everywhere the flag is checked, the code has a working fallback to the standard server-conversion pipeline:
document is opened via the normal binary conversion instead.
Summary
No end-user editing functionality is lost. Opening, editing, and saving docx/xlsx/pptx/vsdx all still work through the C++ converter — that's the normal upstream open-source behavior. What sdkjs-ooxml adds is a performance/architecture optimization: doing OOXML serialization in the browser to skip server conversion roundtrips, plus enabling that one custom-xml test path.