Markdown to PDF: Keep Fonts, Turkish Characters and Searchable Text
A Markdown document can look correct in an editor and still produce a disappointing PDF: the typeface changes, Turkish letters disappear, code clips at the page edge or the whole document becomes an image.
These are different problems. A reliable export needs to preserve the document's structure, render the intended characters and produce usable text in the final file. Checking only the preview misses the last part of that process.
Markdown describes structure, not a finished page
Markdown expresses headings, emphasis, lists, links and other document elements. It does not, by itself, specify a font family, paper size or page margin. The CommonMark reference illustrates that distinction: its syntax describes the content's structure rather than a complete print layout.
The exporter decides how that structure becomes a PDF. Two editors can accept the same Markdown and still produce different line wrapping, pagination and typography. Extensions also vary, so check support for tables, task lists and other syntax before depending on them.
Keep an editable .md copy. The PDF is a distribution format, not a replacement for the source you will need when revising the document.
Selectable text and a screenshot are not equivalent
An exporter can create a PDF from text and drawing instructions, or it can capture the rendered page as an image. Both outputs may look similar at first glance.
An image-only export does not contain the original selectable text unless a text layer is added separately. A text-based export can support searching and copying, but it still needs correct character mappings and sensible reading order. Being able to drag a selection is not the same as confirming that the selected text copies correctly.
For a practical check, select a paragraph from the exported PDF and paste it into a plain-text editor. Look for missing characters, substituted symbols, unexpected word breaks and the order of the copied lines.
Custom fonts need more than a family name
Choosing a font in a browser preview does not automatically make that font available to a PDF generator. The export system needs access to the appropriate font data and must support its format.
Embedding includes font data in the PDF so the recipient does not need the same font installed. Adobe's font embedding guidance describes both full-font embedding and subsetting, which includes only the characters used. It also notes that font settings can restrict embedding. Check the licence as well; having a font on your computer is not permission to redistribute it without conditions.
Check regular, bold, italic and bold italic separately. A family name is not evidence that all four styles exist or that the exporter has loaded them. A fallback or simulated style can look different from the intended face.
Browser font loading is another separate stage. For developers, document.fonts.ready provides a way to wait for the document's font loading and associated layout to settle. It does not, on its own, verify that an independently generated PDF embedded the right fonts.
Test Turkish characters in both directions
Do not test only English letters and assume the rest of the alphabet works. Include characters that the actual document needs:
Ğ ğ İ ı Ş ş Ç ç Ö ö Ü ü
İstanbul, Iğdır, değişiklik, ölçüm
Inspect the shapes in the exported PDF, then copy the text back into a plain-text editor. A letter can look plausible on the page while copying to the wrong character. In particular, dotted İ and dotless ı are not interchangeable substitutes for ordinary Latin I and i.
If a character fails, check the chosen font's coverage, the exact face used for that style and the exporter's handling of that font. Replacing the letter with an English approximation hides the symptom by changing the document.
Use a small export checklist before a long document
Prepare a sample containing a heading, paragraph, bold and italic text, a list, a link, a long code line and the character sample above. If the document uses tables, include one with a long cell.
Then inspect the downloaded PDF for:
- Correct letter shapes and copied characters.
- Working links where the exporter supports them.
- Code and table content that stays inside the page.
- Headings that do not become isolated from their following text.
- Readable spacing at the intended paper size and margins.
- Searchable phrases and sensible copied reading order.
This is a suggested checking procedure, not a report of a new comparative test.
A browser-local workflow on this site
The Markdown editor guide documents a one-document workspace with font choices and text-based PDF export. Its current workflow is: write or open Markdown, adjust styles and page settings, download the PDF, then inspect that file separately. Download the Markdown source before closing; document contents are not automatically saved as a draft.
One portability detail matters: in this editor, a standalone --- acts as a PDF page break. That is an application-specific behaviour, not a universal Markdown page-break command. Image references are shown as placeholders rather than fetched and embedded, so it is not an illustrated-report workflow.
For any exporter, judge the finished file by more than its first page. The useful result is a document that looks right, preserves its language and remains usable when someone searches, copies or revises its source later.
