The most obvious way to turn Markdown into a PDF is to open the preview and hit "Print" or "Save as PDF." If you just need a throwaway copy, that's usually good enough.
But when you're preparing something to print, archive, or send formally, people expect more than "a file that opens." Headings should become PDF bookmarks, code blocks shouldn't get clipped at the page edge, Chinese characters shouldn't suddenly go missing, and page size and margins should stay consistent. Looking fine on screen doesn't guarantee any of that holds up.
That's why Abox Note doesn't treat PDF as a screenshot of the web preview. It re-lays out Markdown as a document meant for paper. What you get is a PDF with a defined page size, heading hierarchy, and layout rules—not a print job that depends on whatever width your window happened to be.
A webpage can stretch; a PDF has to commit upfront
A webpage can widen or narrow with the window, and images and paragraphs can keep flowing downward. A PDF is different: every page has a fixed boundary from the start.
That means export has to answer a set of questions ahead of time: how does a code block wrap when it doesn't fit, can a heading stay with the paragraph after it, how does an oversized image get scaled, can a long table still be read once it spans multiple pages? System print can only record whatever the browser happened to render at that moment—it doesn't necessarily understand the structure of a note.
Heading bookmarks work the same way. Text that just looks bigger on the page may still only "look like a heading" once printed; purpose-built layout can preserve the actual heading hierarchy, letting readers jump around a long PDF directly.
So PDF export isn't the same picture saved under a different file extension. It has to reinterpret content meant for scrolling as content meant for paging through, printing, and saving offline.
What users actually get: a stable paper version
In Abox Note, PDF export handles heading bookmarks, page layout, and fonts separately, and supports templated output. It's well suited to saving a longer note, or producing a version meant to be sent, printed, or archived.
"Stable" here doesn't mean promising pixel-identical pages on every device. It means the rules that matter don't depend on how wide your window happened to be at export time. For example:
- Headings remain recognizable, jumpable headings;
- Body text reflows against page boundaries instead of capturing whatever was on screen;
- When a font is missing certain characters, the system has a chance to fall back to an available glyph;
- If content or a resource can't be processed, the problem surfaces clearly, instead of silently producing an incomplete file.
For users, the important change isn't which technology runs underneath—it's that the export can leave the app and stand on its own. Close Abox Note, and the PDF is still a document with a complete page structure.
Why a PDF won't look exactly like the webpage
Re-laying out content also means accepting real differences.
Webpages are good at links, interactive components, and layouts that adapt to the window; PDFs are good at fixed pages, printing, and long-term storage. Embedded web snippets, remote images, or special styling in a note won't always transfer to paper as-is. Rather than pretend the two media are interchangeable, it's more reliable to define clear handling for content that can't convert directly.
Web code, for instance, can't keep running as a tiny browser inside a PDF. Keeping the readable original content is usually more honest than losing it silently. If something genuinely needs web interactivity, publishing it as a website is a better fit than exporting it as a PDF.
That's the real difference between "print preview" and "layout export": the former tries to copy the page in front of you; the latter first figures out what the other medium needs, then produces the matching result.
When system print is already good enough
Not every piece of Markdown needs a dedicated PDF pipeline.
For sharing a few paragraphs on the fly, grabbing a snapshot of the current page, or just viewing something on your own device, system print is faster and simpler. A dedicated export adds real cost—handling fonts, images, pagination, and templates—and the result won't keep every dynamic capability of the web page anyway.
That cost starts to pay off once a document depends on a table of contents, fixed paper size, longer code, Chinese fonts, or a repeatable layout. At that point, the PDF is no longer just a copy of the content—it's a deliverable that needs to be produced on its own terms.
Export isn't sealing up the last screen of your writing session. It's making the same content readable again in a different medium.