SumDoc — what it is

SumDoc is the document part of the SumOffice platform: a DOCX editor and document processor that embeds into your application. The document itself is read, changed, and written by the Rust core—the same core on every platform.

In one sentence

You keep your brand, users, storage, and processes, and SumDoc adds full document handling inside your product.

You don’t need to replace your product: a document processor and a ready-made user surface are added to it.

What your system already does

The document card, users and roles, approval routes, versions, digital signatures, archiving, audit, integrations with your systems — transport, ERP, CRM — and retention rules all stay on your side.

What SumDoc adds

• Open — receive a DOCX from your system and open a managed document session.
• Show — render the pages and give the user a familiar editing surface.
• Change — accept the actions of a user or an agent as verifiable commands. Nobody edits the file directly.
• Save — assemble a valid DOCX and return the file or a confirmed result back to your system.
• Report — pass the document state to your application: ready, unsaved changes, saved, error.

The main boundary

SumDoc never owns the document card or the business process. It’s responsible for what’s inside the open document and how that content changes.

What it looks like for an end user

The user opens the document from the familiar card. The editor appears inside the same window, under the same brand. The user edits the agreed elements, and on save the new version goes back into the existing storage and audit perimeter — with no manual export to a separate Word and back.

See it live

The editor runs right on the documentation page: live example.

Which files it works with

The primary format is DOCX: it is opened, edited, and saved back in a single session. Other formats are converted to a document and back by separate processor calls. PDF is the only output-only format: you can save to it but cannot open from it.

Format	Open	Save	What to know
DOCX	Yes	Yes	The primary format: open, edit, and save in the same session.
DOCM — DOCX with macros	Yes	Yes	Same as DOCX; the macro project is not lost on save. The processor refuses to downgrade .docm to .docx when saving under another name.
DOC — Word 97–2003	Partial	—	Only text and paragraph breaks are carried over; font styles, styles, tables, images, headers and footers, footnotes, fields, and tracked changes are not. You can find out in advance what will be lost without writing anything; the original .doc is not changed.
PDF	—	Yes	Including with embedded fonts.
ODT	Yes	Yes	An editable ODT copy is available too.
RTF	Yes	Yes	A text interchange format between editors.
HTML	Yes	Yes	A web page.
Plain text	Yes	Yes	Text only, no formatting.
EPUB	Yes	Yes	An e-book.
FB2	Yes	Yes	An e-book.
XODT — flat ODT	Yes	Yes	A single XML file instead of a zip package.

Flat ODT is the same OpenDocument format, but as a single XML file instead of a zip package: convenient when the document lives in version control or is edited by an external tool. For spreadsheets, the same thing is called FODS.

You can convert a single file or a whole directory at once—specifying the extension and, if needed, walking nested folders.

For viewing without the editor, one DOCX is turned into one self-contained HTML file. It opens in any browser straight from disk, with no server and no network, and the layout is computed by the same core as in the editor.

About PDF/A-1b — the archival storage format

Export to regular PDF works, including with embedded fonts. Full PDF/A-1b is not yet promised: the document readiness check honestly reports that PDF/A export is still closed, and the result can be checked with an external program that you specify yourself. If the archival format is mandatory under your retention rules, that is a pilot condition, not a ready capability.

For developers—which calls perform each row: formats and calls; the full list is in the reference. For spreadsheets the same is collected as a matrix: what you can do with each format.

What else the processor does besides editing

A document in progress is rarely just edited. Below are the tasks that cover the rest of the contract workflow; all of them are one-off, like format handling: they do not need an open session.

Task	What happens
Compare two versions	From the original and the changed file a third one is built, where the differences are shown as tracked changes with author and date.
Merge reviewers’ edits	Edits from several files are merged into one document.
Send a mail merge	A template and a CSV list of recipients produce a batch of finished documents; you can take only part of the list.
Inspect macros without running them	The processor reports whether the file contains a macro project and shows the printable strings from it (the inspect-vba call). A separate call parses the project properly: it lists modules and procedures and, if needed, their source text.
Run a macro behind a shield	The macro runs over the text of the open file, but the user’s file is never overwritten: changed paragraphs go to a copy. Without an explicit grant for each entry point the result is a refusal, and that is the default; calls to external objects are allowed by name.
Check the file’s protection	Shows how the document is protected.
Update the table of contents	Rebuilds the table of contents or the list of figures, or removes the table of contents.

This is only part of it: headers and footers, sections, watermarks, form fields, bibliography, printing, and mail merge are grouped by task on a separate page—what SumDoc can do with a document. The calls and their keys for developers are named there too.

Terms that come up across every section — session, revision, projection, explicit refusal — are collected in the glossary.

Word-class inside your product

Inside your window runs the same stack as in the ready-made SumDoc app: the editor surface, the document session, and the core. Your application is responsible for the window, brand, sign-in, storage, and processes; SumDoc for everything inside the open document. The service that serves the editor runs on the same machine and listens only on a local address—nothing is opened to the outside. What the parts are and who is responsible for what—Architecture.

What the user gets in the Word corridor

• Opening agreed DOCX documents inside your application, with no separate SumDoc window.
• Editing, pagination, saving, reopening, and confirming the document stayed itself.
• The base set has the ready, dirty, saved, error, and unmounted events; for a delivery under your brand, selection, content, and command-state events are added to them.
• Styling under your brand: theme, language, read-only mode, styling variables, and your own shell instead of ours.
• Headless operation — for batch processing, services, pipelines, and agent actions.

The boundary of an honest promise

• Opening a file does not mean saving it without loss. The capability profile records separately what is read, shown, edited, saved, and what is carried over unchanged—for each family of DOCX elements.
• Full compatibility with Microsoft Word and Office.js is not included without a separate agreement. VBA macros run only behind a shield: with an explicit grant for each entry point and into a copy of the document—see what SumDoc can do.
• Production delivery requires acceptance on each platform: save and reopen, lifecycle, security, and packaging.