<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Easier said than done. Even for tools that want to do this, the only reliable way is tagging with /ActualText, but this has to be done per grapheme cluster as PDF viewers can’t select or highlight parts of text tagged with <font color="#000000" class="">/ActualText, so Arabic excluded since PDF stores glyphs in visual order and you don’t want to tag full paragraphs. In case of reordering, you will also need to tag the whole reordered sequence as one unit since you can’t tell which glyphs belongs to which character any more. People will also complain about increased file size, so you will have to do tagging selectively for cases than can’t be handled in a different way.</font><div class=""><font color="#000000" class=""><br class=""></font></div><div class=""><font color="#000000" class="">In short, text extraction from PDF is a mess. </font><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Aug 17, 2020, at 8:00 PM, Markus Scherer <<a href="mailto:markus.icu@gmail.com" class="">markus.icu@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">PDFs *should* be generated with Unicode strings, so that copy-and-paste etc. need not try to map back from glyphs.<div class="">Of course, that's optional, and some tools don't bother.</div><div class="">markus</div></div>
</div></blockquote></div><br class=""></div></body></html>