Ahmed Zaki

My framing question is always what has to survive the conversion, because a PDF has no single correct output. To Word, the hard part is structure rather than glyphs. A PDF stores the positions of characters that have already been drawn, so the extractor has to reconstruct paragraphs, lists and tables from coordinates. It gets this right most of the time for prose and rarely for tables, because a table is a grid of positioned fragments and no reliable signal says which fragments belong together. To HTML you have a choice that matters more than the converter you pick. Render the page as an image and you get a perfect visual match with no selectable text and no accessibility. Extract the text and you get selectable, accessible, reflowable output that will not look like the original. Trying to get both is the real project. To images the decision is resolution. Rendering at screen density looks sharp on a screen and soft in print. Rendering at print density produces files nobody wants to email. I cover the scale factor and what it does to file size. Fonts are the recurring cause of mangled output. A document using a font the converter does not have gets substituted, and the substitution changes metrics, which reflows the page. There is no universal fix, but there is a check: compare the page count before and after. Everything here runs locally, and I say so on every page, because a document leaving a device is the thing people most want to avoid when the file contains what the filename suggests it contains.