The issue is already in the original document, in the way it has been created.
It looks as if the original presentation has been created with PowerPoint (what else…) on Mac (well the presentation may have been created on Windows, and then brought to Mac to create the PDF). No OCR involved.
The PDF creation occurred using the Apple tools, and it seems that these tools have problems with ligatures. Instead of using the Ligature character from the "main" font file, it creates another subset containing the ligature character, but does not properly encode the Unicode code, and the result is that transposing the encoding to the "main" font encoding leads to the character 8.
As we all know, in PDF, text is a set of "words" placed on a canvas, where the "words" are separated by whitespace. The connection between the "words" to form a sentence does not exist in basic PDF. For copying, either the PDF viewer does some heuristics to determine whether those "words" belong together or not, and/or it uses the structure information (if present). Chrome's logic is different from Acrobat's logic, and that's how the discrepancies appear.
Actually Acrobat XI has an option in the Context Menu of the selection "Copy with Formatting", and that lead (after pasting into BBEdit) to:
"Training"
"1. Collect a set of representa8ve training documents"
This option apparently uses more logic to create sentences. But the ligature is wrong, because it can not be properly recreated.
Verdict, badly created PDF leads to discrepancies when attempting to repurpose contents with different PDF viewers…