feat: expose the supported-format tables and a per-file-type capability query

[andiwand]

🤖 Generated with Claude Code

Closes #632.

Why

Consumers have to rebuild odrcore's format knowledge by hand — OpenDocument.droid keeps three separate format tables plus an instrumented test to hold them in sync. The lookups in odr.hpp are one-directional and incomplete, and there is no way at all to ask what the library can do with a format before holding a file, which is exactly when an app has to decide (intent filters, picker MIME lists, "open with" entries).

All of it lived as six independent if-chains over FileType in odr.cpp, which had already drifted apart:

• markdown had a MIME type but no extension.
• The wpd MIME round trip was broken — libmagic reports application/vnd.wordperfect, file_type_by_mimetype could not map it back, and odr_test::types_wpd documented the gap.
• rtf, svm, cfb and office_open_xml_encrypted had no MIME type at all.
• There was no extension_by_file_type; file_type_to_string accidentally doubled as one.
• Whole alias families were missing (docm, dotx, xlsb, ppsx, the macro-enabled and template MIME types, application/x-vnd.oasis.*).

What

One central table. src/odr/internal/file_type_table.{hpp,cpp} — a constexpr array, one row per FileType, holding the name, every extension, every MIME type (canonical first), the category, the document type and the capabilities. Every public lookup is now a thin forward into it; odr.cpp shrinks from 441 to 164 lines.

Enumeration. all_file_types, file_extensions_by_file_type, file_extension_by_file_type, mimetypes_by_file_type — so a consumer never needs its own copy of these tables.

Capabilities. FileTypeCapabilities + capabilities_by_file_type answer, per format, whether we can detect / open / decrypt / render / edit / save / encrypt it:

struct FileTypeCapabilities final {
  bool detect_by_content{}; ///< recognised from its bytes alone
  bool open{};              ///< a decoder exists
  bool decrypt{};           ///< encrypted instances can be decrypted
  bool translate_html{};    ///< `html::translate` produces output
  bool edit{};              ///< `Document::is_editable` can be `true`
  bool save{};              ///< `Document::save` is supported
  bool encrypt{};           ///< `Document::save` with a password is supported
};

It is explicitly a declared upper bound — the question you have to answer before you hold a file. DecodedFile::capabilities() refines it for the file in hand, and Document::is_editable/is_savable stay the precise answer.

Aliases. docm/dotx/dotm, pptm/potx/potm/ppsx/ppsm, xlsm/xltx/xltm, dot/pot/pps/xlt/xlm, md/markdown, otm, text, ttc, xlsb; the ODF x-vnd/-template/-master/-flat-xml families, the OOXML .template/.slideshow/macroEnabled.12 families, plus text/rtf, application/x-pdf, image/x-ms-bmp and friends.

Keeping it honest

A hand-maintained table can lie, so the invariant is a test rather than discipline.

FileTypeCapabilities.declaration_matches_the_engines walks the corpus and asserts that DecodedFile::capabilities() is a subset of what the table declares, and that Document::is_editable() / is_savable(false|true) equal the declared edit/save/encrypt. Over-declaring edit support for a format that cannot edit now fails CI.

Alongside it: every FileType has exactly one row (derived from the enum, not the table, so a missing row is caught), no extension or MIME type is claimed twice, every alias round-trips, the canonical alias is front(), and only unknown lacks a MIME type. html_output_test now derives its "cannot open" skip from capabilities_by_file_type(...).open instead of a hardcoded list.

Behaviour changes

• mimetype_by_file_type throws only for FileType::unknown now. wpd, rtf, cfb, ooxml-encrypted and svm gained canonical types; svm's is taken from svm_file.cpp so the static answer matches what the file object reports.
• file_category_by_file_type(pdf) reported unknown while abstract::PdfFile::file_category() has always said document. It is document now, with document_type text — matching what pdf_file.cpp already puts in file_meta. office_open_xml_encrypted likewise becomes document, and is named ooxml_encrypted instead of unnamed.
• internal::ImageFile::mimetype() returned ""; it answers from the table.

xlsb gets its own FileType::excel_binary_workbook rather than riding along with xlsx: the package is OOXML but the workbook parts are binary, so there is no decoder. Since capabilities are keyed on FileType, sharing the xlsx row would have made it inherit open/translate_html and led exactly the pickers this PR is meant to serve into offering files that cannot be opened. Its own type carries an all-false capability row.

Bindings

Both layers expose the new API: JNI gets FileTypeCapabilities.java, five natives on Odr and DecodedFile.capabilities(); pyodr gets the matching free functions plus FileTypeCapabilities and DecodedFile.capabilities.

Reference output

Regenerated for the two changed metadata fields (fileCategory on every PDF and the two encrypted OOXML packages; fileType on those two). Every HTML output is byte-identical, so no html-tidy pass was involved.

Testing

• Full odr_test suite green. The category change surfaced five PDFs whose document_type is unset because the meta parse is all-or-nothing (see pdf/AGENTS.md); the comparison is guarded for that.
• pytest python/tests: 43/43.
• JNI compiles on both sides (javac --release 17 -Xlint:all over all of jni/java, and the touched jni_*.cpp against JDK headers). The JUnit suite itself was not run locally — CI covers it.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 46f9d4ad05

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".