A text file is the least opinionated document there is. No fonts, no margins, no pages — just characters.
That freedom is exactly what makes conversion interesting: every layout decision has to be invented, because the source expresses none of them. The quality of the result is entirely the quality of those invented decisions.
What has to be decided
To put text on a page, a converter must choose:
- Page size and margins
- A typeface and size
- Line length — where lines wrap
- Leading, the space between lines
- Where pages break
None of this is in the source file. A good conversion picks sensible defaults; a poor one picks the obvious ones, which are not the same thing.
Text to PDF works out the format from the file extension, or from its Read as setting, and typesets accordingly in your browser: plain text in Courier, CSV as a table, Markdown in Helvetica with code in Courier. Body text is set at 10.5 pt on portrait A4 or Letter with margins of about 2 cm, and there are no font, size or orientation settings, so Markdown prose runs to about 100 characters a line.
Line length is the decision that matters
If only one thing is chosen well, it should be this.
Typographic convention puts comfortable line length at roughly 65 to 75 characters. Shorter and the eye jumps back too often; longer and it loses the start of the next line on the return sweep.
Using the full page width with narrow margins gives lines of 100 characters or more. That fits more on a page but is past the range above. Text to PDF’s Markdown output lands there: proportional type at 10.5 pt between margins of about 2 cm sets about 100 characters a line. Its plain text output, in Courier, fits about 75 on an A4 line.
Generous margins are not wasted paper. They are what makes the text readable — and they leave room for the annotations people make on a printed document.
Three kinds of text, three treatments
Prose — a proportional typeface, comfortable line length, generous margins. Wrapping is helpful here, since the text has no meaningful line structure of its own.
Code and fixed-width data — a monospaced typeface, always. Alignment depends on every character being the same width, and a proportional face destroys the column structure that made the content readable. Wrapping is also harmful: a wrapped line of code loses its indentation and so loses its structure. Better to reduce the font size, or turn the page landscape, than to wrap. Text to PDF can do neither, so it wraps plain-text lines and Markdown code lines that are too wide, and says so in the result notes.
Tabular data — see below.
Getting this wrong is the commonest complaint about text conversion, and it is nearly always a proportional font applied to content that needed a monospaced one.
CSV becomes a table
A CSV is a table wearing a text file’s clothes. Converting it as prose produces unreadable comma-laden lines.
Treated properly, the delimiter marks column boundaries and the widest value in each column sets its width. That works well for regular data and has two well-known failure modes:
- Quoted fields containing the delimiter —
"Smith, John"is one field, not two, and a naive split produces a table shifted by one column from that row onward. - Rows with different field counts — a ragged file has no consistent table shape to build.
Check a converted table against the source, particularly the first and last rows. A table that is off by one column reads plausibly and is entirely wrong.
For a wide table, landscape orientation buys about forty per cent more width, which is usually the difference between a readable table and a truncated one. Text to PDF does not turn pages landscape. It narrows the columns and wraps their text to fit portrait A4 or Letter, and a table whose columns still do not fit even at about 1.3 cm each, usually 13 or more columns, is set in labelled groups of columns, one after another.
Markdown carries structure worth keeping
Markdown is the one text format that does describe its own structure. # is a heading, - is a list item, ` is code.
A conversion that honours that produces a properly typeset document — real heading hierarchy, indented lists, code in a monospaced face. A conversion that ignores it produces a page with visible hash marks and asterisks, which is worse than the source.
If your notes are already in Markdown, that structure is doing work for you. Keep the file as .md rather than renaming it to .txt, so the conversion can recognise it.
Encoding, and the mojibake problem
Text files carry no dependable declaration of their encoding. The bytes are just bytes, and the reader has to guess.
Guess wrong and you get mojibake — café becoming café, where a UTF-8 file was read as a single-byte encoding. Each accented character becomes two nonsense characters.
The fix belongs in the source: save the file explicitly as UTF-8, which every modern editor offers. If you receive a file that converts to gibberish, reopening it with the correct encoding and re-saving as UTF-8 resolves it.
Watch for this particularly in exported data, where legacy systems still emit older encodings.
Long documents
For text running to many pages, Add page numbers makes the result navigable — a reader can refer to a page rather than describing where something is.
If the conversion left margins wider than you want, Crop PDF tightens the visible page box without re-encoding anything. Be aware that cropping hides rather than removes: the content outside the box stays in the file, which is fine for margins and never appropriate for concealing text.
Before you send it
- Read the first page properly. Line length and font choice are obvious once you actually read rather than glance.
- Check accented characters and symbols — the encoding tell.
- Check the last row of a converted table against the source, where quoting errors accumulate.
- Confirm indentation survived, for code or structured text.
- Look at a page break to see it did not fall somewhere absurd, like between a heading and its paragraph.