4 ms·
> "Selecting blocks of text" involves guessing which order the lines go in, depending on their location / distance from other lines. If you create your own PDF
by Someone 4y ago
> "Selecting blocks of text" involves guessing which order the lines go in, depending on their location / distance from other lines.
If you create your own PDFs, you can make sure they contain both information about reading order and the mapping from glyphs back to UTF-8 text by creating an accessible PDF (aka a “tagged PDF”)
I think most modern word processors can create such PDFs. MS Word definitely can (https://support.microsoft.com/en-us/office/create-accessible-pdfs-064625e0-56ea-4e16-ad71-3aa33bb4b7ed https://support.microsoft.com/en-us/office/create-accessible...).
> Compare to having for example "<recipient-address>...</...>" from which you can still generate the printed version.
Generating _a_ printed version is easy; generating _the_ printed version, guaranteeing 100% reproducibility isn’t. To get the exact same layout, you’ll have to guarantee to use the same fonts (difficult, as OSes can update their fonts, possibly tweaking a glyph, a kerning table or anything else that can affect layout) and, basically, never fix bugs in your PDF generation flow.
That’s why many people keep both the structured source data (e.g. in json or xml) and the generated PDF.
- viraptor 4y ago> creating an accessible PDF (aka a “tagged PDF”) I don't think I've seen a tagged PDF in the wild... ever. I'm sure they exist, but I'm doing a lot of stuff with PDFs in the healthcare context and this tech may as well not exist for me. To the point that most apps will support embedding a bad PDF in an HL7 file just to add metadata. > That’s why many people keep both the structured source data (e.g. in json or xml) and the generated PDF. They totally should. No dispute.