# Format Comparison Methodology

| Field | Value |
|---|---|
| Document | ONDC-TN-002 |
| Status | Technical Note (Non-Normative) |
| Updated | 2026-11-03 |
| Native Draft | `1.0-draft.1` |
| Office Exporter | LibreOffice 24.2.7.2 |

## Reference Text

What does a tool have to open to reach a document's text? This comparison starts with six actual files and lets you inspect the path from stored bytes to readable content. It is a small experiment in representation and access. It cannot answer which format is best for a book, which editor has the best layout, or which source gives an AI model the most accurate answer.

“The North Wind and the Sun,” from Aesop's fables, translated by George Fyler Townsend. The underlying work is public domain. Text is sourced from [Project Gutenberg eBook 21](https://www.gutenberg.org/cache/epub/21/pg21-images.html). No book illustrations are reproduced.

The same title, attribution, two body paragraphs, and italic moral appear in each comparison file. Presentation and paragraph styling were added for this demonstration.

The shorter story in the homepage chat is a separate, site-authored retelling. Its [ONDC download](/comparison/north-wind-summary.ondc) is excluded from the six-format measurements because it contains less text.

## Files

- **ONDC:** actual XML conforming to the project's current native draft, published under the selected `.ondc` filename for this demonstration. The prototype's normal XML export behavior is unchanged.
- **ODT and DOCX:** actual exports from a common flat-ODF seed using LibreOffice's Writer filters. These are typical exports from this version and settings, not minimum possible encodings for their standards.
- **PDF:** a page-oriented export from the same seed. The preview image is rendered from the actual PDF using Poppler's `pdftoppm`.
- **Markdown:** a UTF-8 text representation containing the same text, heading, and emphasized moral.
- **HTML:** a self-contained, text-based HTML document containing the same text, structure, and emphasis.

Every original file is downloadable. Office package parts are extracted without altering their bytes. The source viewer wraps lines and formats XML automatically. ONDC already has a readable hierarchy, so its original source is preserved without adding blank lines. Other XML display formatting does not change the downloaded file.

## From Generator To Download

The generator starts with the shared story fixture. It constructs a flat-ODF seed, exports ODT/DOCX/PDF through LibreOffice Writer, and writes ONDC, HTML and Markdown from the same content. It then records archive entries, extracts original parts, builds normalized preview blocks and computes file fingerprints.

These are typical outputs from the recorded generator and LibreOffice version. They are not hand-minimized examples of each format. Metadata, supporting styles and thumbnails can remain in the office exports even when the story itself does not need them.

The original downloads are the evidence. The source viewer is an aid to inspection. It may wrap lines or display a formatted copy of an XML part, but those changes do not affect the file's bytes or hash. The native source already has a readable hierarchy and is displayed without inserted blank lines. Binary entries use a short, labeled hexadecimal preview rather than a full decode.

## Reading The Previews Correctly

The visual Guide explains organization before asking the visitor to inspect markup. Source lets the visitor open the actual text parts. Document shows content in a common reading layout. Each view answers a different question.

The normalized previews intentionally use shared typography. They make common text and emphasis easy to compare, but are not screenshots from Word, Writer or a complete ONDC renderer. Identical previews do not establish identical page breaks, font metrics, spacing or printing behavior. The PDF image is the exception: it is rendered from the actual PDF, so it shows that exporter's page output.

Body XML is only part of an office document. Styles, relationships, numbering and resources can live elsewhere. A tool that reads `word/document.xml` alone has not necessarily understood all the formatting. Existing format-aware libraries can resolve these dependencies automatically.

## How To Interpret The Figures

| Measurement | Definition | Exclusion |
|---|---|---|
| Stored bytes | Exact downloadable-file length | Memory use, model input and decoded package size |
| File parts | Non-directory archive entries; one for a standalone file | Empty ZIP directory entries |
| Body-source characters | Unicode character count after decoding the selected body source | Other office parts, shared styles and relationships |
| SHA-256 | Digest of original file or extracted bytes | Authorship, signature validation and safety certification |

One UTF-8 character can occupy several bytes. The story's attribution includes a non-ASCII character, so character counts and byte counts differ. The viewer's KiB labels use 1,024 bytes per KiB. Source counts are taken before presentation formatting adds whitespace.

For packaged office documents, stored size includes compression while the source count describes decoded XML. Those are different quantities. A smaller source count does not automatically imply a smaller download or fewer model tokens.

## Recorded Results

The [published manifest](/comparison/manifest.json) records exact paths, counts and fingerprints for these committed artifacts.

| Format | Stored Bytes | File Parts | Body-Source Characters |
|---|---:|---:|---:|
| DOCX | 5,947 | 11 | 2,764 |
| ODT | 17,322 | 8 | 4,388 |
| PDF | 29,520 | 1 | Binary; not reported as source text |
| Markdown | 765 | 1 | 764 |
| HTML | 1,206 | 1 | 1,205 |
| ONDC | 1,208 | 1 | 1,207 |

Markdown is smaller than ONDC here, and HTML is approximately the same size. The exported office documents have longer body XML and more supporting parts. This is a result for these files, not a minimum size required by those standards.

The ODT includes an exporter-produced thumbnail, settings and metadata. Different export settings can change the result. With larger documents, repetition and compression can change the relative sizes again. A comparison of storage efficiency needs a corpus and controlled exporter settings.

## What The Chat Is Showing

The homepage asks for a shorter story, waits briefly, then shows a prepared document. The request, reading state and reply form a scripted example. No prompt is transmitted to an AI provider, and the pause is chosen for presentation rather than measured execution time.

The shorter result keeps the heading and italic ending, while replacing the body with two shorter paragraphs. Its source view and download describe the same file. This makes the intended interaction inspectable without implying that arbitrary rewriting is implemented.

The specification's separate four-stage walkthrough uses a smaller change: replace “Force” with “force” in the final lesson. Its commands are explanatory pseudocode, not a published API. It illustrates direct source access and archive-aware access, while omitting many details of a production editor. Permission, unlock, format-aware handling, validation and review are necessary in either path.

## Verification And Regeneration

From the landing-site directory:

```sh
python3 scripts/generate-comparison.py --verify
```

Verification checks fingerprints and file sizes, archive contents, extracted original bytes, shared document text and emphasis. PDF text checking uses Poppler. Native XML can also be checked against the project's draft grammar and semantic rules; that establishes structural evidence rather than visual fidelity.

Regeneration requires LibreOffice and Poppler, including `pdftoppm` and `pdftotext`. An ordinary site build uses the committed artifacts and does not need those authoring tools. Exporter metadata can vary between runs, so unchanged story text does not guarantee identical file hashes. No bit-for-bit reproducibility across exporter versions is claimed.

Review the downloads, extracted parts, manifest and normalized content together after regeneration. Updating numbers alone can leave the viewer describing a different artifact. The separate chat summary should be checked for preview/download agreement without changing the six-format measurements.

## Current Limits

ONDC remains experimental. This comparison does not establish complete layout support, conversion fidelity, independent interoperability, secure AI editing, or an adopted standard. Images and other assets may remain separate binary files, and encrypted stored data cannot be searched as plaintext before authorized unlock.

## A More Useful Next Experiment

A broader study should name its corpus, tool versions, task definitions and pass criteria before running. Useful tasks include finding text across differently formatted runs, rewriting a paragraph without changing neighboring structure, preserving an unsupported object and reopening an output in an independent consumer.

Report failed edits and preservation errors alongside successes. Model comparisons need named models, prompt and tool configurations, repeated runs where relevant, and actual token/cost measurements. Conversion comparisons need feature-specific loss reports and native-application review. Neither study can be replaced by counting XML characters.

## References

- [ODF 1.3 Packages](https://docs.oasis-open.org/office/OpenDocument/v1.3/os/part2-packages/OpenDocument-v1.3-os-part2-packages.html)
- [WordprocessingML Structure](https://learn.microsoft.com/en-us/office/open-xml/word/structure-of-a-wordprocessingml-document)
- [LibreOffice Conversion Filters](https://help.libreoffice.org/latest/en-US/text/shared/guide/convertfilters.html)
- [ONDC Architecture Overview](native-format-overview.md)