AnymarkPDF to Markdown is a reconstruction problem, not a conversion
People expect “PDF to Markdown” to work like “Word to Markdown”. It cannot, and knowing why saves a lot of frustration.
A Word file says “this is a heading, this is a list item, this is a table with three columns”. A PDF says “draw the letter R at x=72, y=701 in 14-point Helvetica Bold”, four hundred times per page. There is no heading, no paragraph, no table in the file. Any structure in the Markdown has to be inferred from where the letters sit, how big they are and what is near them.
What a good engine has to work out
Reading order. A two-column article has to be read down the left column, then down the right, not straight across. Headers, footers and page numbers have to be set aside. A pull quote in the middle of the page has to be read as its own block.
Paragraphs. Lines that end because the margin was reached have to be rejoined into one paragraph; lines that end because the paragraph ended must not be. The clues are line spacing, indentation and whether the previous line reached the right margin.
Headings. Bigger or bolder text set apart from the body is a heading, but small print set in bold is not, and a title that spans two lines is one heading. A document rarely has more than four heading levels; an engine that produces seven is guessing.
Lists. A bullet glyph or a number followed by indented text is a list item. “(a) …, or (b) …” inside a sentence is not a list, however much it looks like one.
Tables. The hard case. A ruled grid is easy: the lines say where the cells are. A table ruled only horizontally needs the columns found from the gaps between words. A table with no rules at all needs the columns found from alignment alone, and the engine has to decide where the table ends and the paragraph below it begins. Then the header row has to be found, and numbers right-aligned.
Pictures. Logos, charts, stamps and signatures should come out as image files beside the Markdown, with the text around them in the right place.
What you should expect from the output
For ordinary documents, reports, papers, letters, statements and manuals, a good engine gets reading order, paragraphs, headings and lists right nearly all the time and tables right most of the time. You will still read it through once.
For documents whose meaning lives in the layout, forms with arrows, posters, slides with text in boxes, mathematical typesetting, expect the words in a sensible order and not much more. Keep the original beside you.
How Anymark approaches it
Anymark’s PDF engine runs on your computer and does the inference above: columns and reading order, paragraph rejoining, heading levels capped at four, lists (with the “(a), (b)” trap avoided), and three kinds of table, ruled, half-ruled and unruled, keeping alignment and bold totals. Centred and right-aligned paragraphs stay aligned. Pictures are saved beside the file. Fillable forms keep what was typed and ticked. Scanned pages go through OCR first (more on that in a separate article).
It is honest about the limits: the app tells you a converted file was converted, keeps the original untouched, and the website says plainly that forms, formulas and tables without rules convert roughly. If you have a PDF that comes out wrong, send it to support@anymark.app; the test suite is built from exactly those files.