Hello,
I am currently reading a PDF book, and in the text, there are strange jumblings of the letters like the ones in this screencap:

I don't think things like the collision between /t and /e can be explained by human error. A typist normally couldn't mess up the kerning that is in the font, and at other places in the text, the kerning seems to work. There is perhaps some technical issue that caused this. If you have encountered similar errors when typesetting books, please share what caused them and if it was something with the font or with some other software.
Comments
The screencap is from Adobe Reader; I opened the book in MS Edge, and the error was there too. And here it is in Adobe Illustrator:
So it’s kinda funny and irritating that some of those official Adobe PDFs from the early ’90s often look terrible now.
yo ucan
ho tel
kn ow
In all 3 cases \o is involved.
Opening the page in Adobe Illustrator shows there are no space characters between the words. Instead, the book is built with extra tracking values added to the glyphs next to where a space is needed. Why the book was saved this way, I haven't a clue, but every now and again throughout the book, the extra tracking is either added or removed in the middle of words, which creates the visibly bad letterspacing.
If that pdf was used for print, an editor should have caught the problem.
I didn't adequately explain myself. The problem is obviously in the PDF since the same odd spacing first shows up when viewed in various PDF readers and in Illustrator when opened up in that application. In those unaffected blocks of text, actual space characters are used instead of tracking values.
Illustrator just chooses to display the problem as a tracking issue where it substitutes tracking values for the missing space characters. Affinity Publisher and Designer, for what it's worth, run into the PDF problem too, but Affinity seems to choose simply to close up the missing spaces rather than substituting approximated tracking.
An oddity, as you mentioned, is that the problem doesn't show up when copied from the PDF and pasted into a code editor, but the problem does show up in MSWord, which, unlike a code editor, attempts to display some of the formatting.
This observation doesn't solve the question of where the problem in the PDF originated, but it does help narrow down the possibilities.
What originally caused the problem in the PDF, I don't know. As @Mark Simonson found, the document was originally laid out in QuarkXPress, so it might trace back to that. However, Quark has had over 30 years to work out these glitches, so I suspect there's more to it. I suspect the problem has something to do with some unknown step in the procedure from the original Quark layout to the final downloaded PDF.