Wire epub-codec into the conversion engine, CLI, MCP, and web - #1091
Merged
Conversation
…pathfinder Registers epub as a wordprocessing-variant DocumentFormat: content read/write via epub-codec's readEpubContent/writeEpubContent (codecs registry and read.ts, following doc-codec's bare-ContentDocument pattern rather than rtf's, since epub-codec takes no signal), a capability entry with no layout path of its own, and a composition FORMAT_NODES entry that wraps epub's zip bytes through the same latin1 round trip doc/xls/ppt already use for their own byte-oriented formats. epub therefore same-variant bridges to docx/odt/markdown/ rtf/doc and reaches every other target through those plus PDF, the identical routing rtf/doc already have. setDocumentMetadata rejects epub explicitly rather than rebuilding through it: epub-codec's OPF reader/writer round-trip title, author, keywords, and language through real Dublin Core elements, but has no mapping for subject, so a metadata rebuild would silently drop that one override.
Wires epub into the CLI's extension map and the TUI's open/export/ undo/root-screen paths the same way rtf/doc/ppt already are: no live editor exists for it, so opening one runs epubToPdf once and browses the result through the shared pdf screen family, with the original bytes kept for export-pdf to re-run with real fonts and diagnostics. Also fills in wpd/doc/xls/ppt, which the generic convert/from-package usage-error format list had been missing since those formats gained write support.
Adds epub to the path-extension classifier and the convert_document
tool's own supported-format list, following the identical mapping
document-cli's format.ts already has.
Also fills in doc/xls/ppt, which this file's own extension map had
been missing since those formats gained write support in documents.js
-- a gap its header comment ("ported from document-cli... so both
entry points classify a path identically") already claimed didn't
exist.
Recognises the .epub extension, reads its content directly through readEpubContent for the standalone preview path, and routes it through the wordprocessing preview component alongside docx/odt/rtf/doc -- the conversion picker and pair list already derive from DOCUMENT_FORMATS and the converter's own conversions, so both pick up epub with no further change.
…rebase conflict The lockfile's own entry for documents.js's markdown-codec dependency still carried the pre-rebase ^6.3.7 specifier despite package.json already declaring ^6.4.0, and epub-codec was missing entirely from the same dependency block -- both left behind when an earlier rebase conflict on this file was resolved by taking origin/main's copy wholesale before pnpm had regenerated it against the rebased package.json. Regenerated via pnpm install against origin/main's own lockfile as the base, so every other package's resolution stays exactly as main already has it.
Mearman
marked this pull request as ready for review
September 7, 2026 17:41
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Wires epub-codec into every layer of the ecosystem the way rtf-codec and doc-codec already are, closing the "built but unreachable" gap #919 described.
epub is registered as a wordprocessing-variant
DocumentFormat: content read/write throughreadEpubContent/writeEpubContent(following doc-codec's bare-ContentDocumentpattern, since epub-codec's own functions take no signal), a capability entry with no layout path of its own, and a compositionFORMAT_NODESentry wrapping its zip bytes through the same latin1 round trip doc/xls/ppt already use. It same-variant bridges to docx/odt/markdown/rtf/doc and reaches every other target through those plus PDF -- the identical routing rtf/doc already have.setDocumentMetadatarejects epub explicitly rather than rebuilding through it: epub-codec's OPF reader/writer round-trip title/author/keywords/language, but there's no Dublin Core mapping for subject, so a rebuild would silently drop that one override.document-cli opens an epub as a read-only PDF preview through the shared pdf screen family, the same shape rtf/doc/ppt already get. document-mcp and web both recognise the
.epubextension and route it through their own generic conversion/preview paths.Along the way, fixed a few pre-existing format-list gaps I touched directly while adding epub to the same lines: document-cli's
KNOWN_DOCUMENT_FORMATSand document-mcp's extension map were both missing wpd/doc/xls/ppt, despite comments claiming parity with each other.Fixes #919