There's no way to get Markdown out of this package today -- every conversion target is another document format (docx/pptx/odt/odp/ods/odg ⇄ PDF, plus the six PDF-bypassing bridges). For a caller that wants plain-text/Markdown extraction (e.g. feeding a document into an LLM context or a search index), the only path is external: render to PDF then run a separate PDF-to-text tool, or hand-write something against the raw ContentDocument.
The pivot model this package already produces has what a renderer needs:
ContentTable's rows/cells map directly to GFM table syntax.ContentListMembership (numId/level) gives real multi-level list nesting.ContentImageBlock already carries inline base64 bytes plus altText/widthPt/heightPt -- no extra fetch needed to emit an image reference.
The one genuinely heuristic piece: ContentParagraph.styleId is a free-form string (whatever the source format's own named style is -- "Heading1" for docx, ODF's own style-name convention for odt), not a structured heading-level field. Mapping styleId conventions to #/##/etc. is real, format-specific inference, the same category of heuristic reconstructWordprocessing/reconstructPresentation already do for PDF input -- not a schema gap.
Proposed shape, mirroring the existing src/layout/ (ContentDocument → LayoutDocument) pattern: a new src/markdown/ module with convertWordprocessingToMarkdown/convertPresentationToMarkdown/convertSpreadsheetToMarkdown (drawing has no real Markdown-representable target, given its content is vector primitives). Exposed both as direct functions and via the existing onDocument-callback/DocumentConverter port pattern the PDF conversions already use, so a caller can go straight from any supported format to Markdown without caring whether PDF is involved.
There's no way to get Markdown out of this package today -- every conversion target is another document format (docx/pptx/odt/odp/ods/odg ⇄ PDF, plus the six PDF-bypassing bridges). For a caller that wants plain-text/Markdown extraction (e.g. feeding a document into an LLM context or a search index), the only path is external: render to PDF then run a separate PDF-to-text tool, or hand-write something against the raw
ContentDocument.The pivot model this package already produces has what a renderer needs:
ContentTable's rows/cells map directly to GFM table syntax.ContentListMembership(numId/level) gives real multi-level list nesting.ContentImageBlockalready carries inlinebase64bytes plusaltText/widthPt/heightPt-- no extra fetch needed to emit an image reference.The one genuinely heuristic piece:
ContentParagraph.styleIdis a free-form string (whatever the source format's own named style is --"Heading1"for docx, ODF's own style-name convention for odt), not a structured heading-level field. Mapping styleId conventions to#/##/etc. is real, format-specific inference, the same category of heuristicreconstructWordprocessing/reconstructPresentationalready do for PDF input -- not a schema gap.Proposed shape, mirroring the existing
src/layout/(ContentDocument → LayoutDocument) pattern: a newsrc/markdown/module withconvertWordprocessingToMarkdown/convertPresentationToMarkdown/convertSpreadsheetToMarkdown(drawing has no real Markdown-representable target, given its content is vector primitives). Exposed both as direct functions and via the existingonDocument-callback/DocumentConverterport pattern the PDF conversions already use, so a caller can go straight from any supported format to Markdown without caring whether PDF is involved.