DocumentBodyMarkdown.h header
#include <ew/app/DocumentBodyMarkdown.h>Namespace ew::app
Functions
QString ew::app::document::documentBodyMarkdown(const ew::core::document::Document &document)The document's stored body as the app's Markdown, decided by its ew::core::document::BodyFormat tag rather than by guessing from the text: a Markdown-format body (the default since the Markdown-native document store) is returned verbatim, while a legacy Html-format body is converted via htmlBodyToMarkdown. This is the single normalizer the export engine and the embed renderer use so every consumer reads a document body as Markdown, and so a Markdown body that merely contains incidental angle brackets is never misread as HTML (as a content heuristic could).
QString ew::app::document::htmlBodyToMarkdown(const QString &body)Converts a document body the editor stored as rich-text HTML (what QTextDocument::toHtml emits) into the app's Markdown. This is the per-body normalizer the export engine (which is UI-free and cannot walk a QTextDocument itself) runs so an HTML-authored body exports as clean Markdown rather than raw markup; it is also the foundation the Markdown-native storage rework builds on (the segment SSOT is docs/MARKDOWN_EDITING.md). A body that is not rich text (already Markdown or plain text) is returned unchanged.
It builds a QTextDocument from body, walks the root frame's blocks and child tables, and emits Markdown itself – preserving inline bold/italic/strikethrough/links (which Qt's own toMarkdown drops), ordered/unordered/nested lists, block quotes, horizontal rules, and GFM pipe tables, and passing the app's ![[…]] / [^id] markers through verbatim for the export engine's embed-strip and footnote-fold. Formatting beyond Markdown's vocabulary (colour, font, alignment, …) is dropped here (this is the export transform; DOCX/RTF exporters parse the Markdown themselves and would leak an extension token).
QString ew::app::document::htmlBodyToMarkdownWithStyles(const QString &body)As htmlBodyToMarkdown, but ALSO emits the {.ew …} rich-text extension (see ew::app::MarkdownExtension) for the formatting Markdown cannot express, so the conversion is lossless: an inline run's colour, highlight, font family/size, underline, and super/subscript become [text]{.ew …}, and a paragraph/heading's non-default alignment, line spacing, or indent become a leading {.ew …} block line. This is the storage-fidelity conversion the Markdown-native document store uses (docs/MARKDOWN_EDITING.md); markdownToHtml renders the extension back. (A named paragraph style's relative size adjustment is not captured – its other effects, heading level / alignment / bold / italic, round-trip through their own Markdown.)
QString ew::app::document::textDocumentToMarkdownWithStyles(const QTextDocument &document)As htmlBodyToMarkdownWithStyles, but reads a live QTextDocument instead of HTML text. This is what an editor should call to serialize what the writer is looking at.
The string overload exists for a body already STORED as HTML. Handing it document.toHtml() instead looks equivalent and is not: toHtml() is a lossy projection, and re-parsing it loses information the model still had. Two defects came from exactly that indirection. toHtml() writes the document's default font into the <body> style, which the re-parse then materializes onto every fragment, so an untouched paragraph came back wearing an explicit {.ew font=… size=…} span (F-0163). And toHtml() does not preserve a block's nonBreakableLines, so a fenced code block came back as an ordinary paragraph in a monospace font – indistinguishable from prose a writer chose to set in Courier, and therefore unrecoverable downstream (F-0167).
Reading the model directly avoids both at the source: the default font stays the document's default rather than becoming per-run formatting, and a code block is still a code block.