A PDF does not contain paragraphs. It contains characters positioned on a page, and the line breaks you see are where the typesetter decided the line should end. Copy that text and you get exactly what was stored: a hard break at the end of every visual line, which your word processor faithfully preserves as it reflows the text into a completely different width.
The result is the familiar ragged block that looks broken in a way you cannot fix by dragging the margins. Here is what is actually in there, and the order to deal with it.
The order matters
This is the part people get wrong. Removing line breaks first destroys the information you need to work out where the paragraphs were.
The correct sequence is always: mark the real paragraph breaks, then remove the false ones, then tidy whitespace, then fix characters. Reverse any two of those and you will be re-reading the text to work out where paragraphs belonged.
One: keep the paragraphs
In text copied from a PDF, a real paragraph break usually shows up as two consecutive line breaks, while a false one is single. So before doing anything else, replace every double break with a placeholder no sane document contains - something like @@PARA@@.
Now every remaining line break is one you want gone. Remove them all, then swap the placeholder back for a proper break. This two-step is the whole trick, and it is why doing it by hand takes twenty minutes and doing it properly takes two.
Where the source has no blank lines between paragraphs at all, the fallback is indentation - a line starting with whitespace often marks a new paragraph. Less reliable, but better than reading the whole thing.
Two: whitespace
Three separate problems that look identical on screen.
Double spaces after sentences. A typewriter convention that survived into a surprising number of documents. Harmless in prose, visible in justified text, and worth normalising for consistency.
Trailing spaces at line ends. Invisible, and they break things - in Markdown, two trailing spaces mean a line break, so text pasted from elsewhere renders with mysterious gaps.
Non-breaking spaces. The genuinely nasty one. U+00A0 looks exactly like a normal space and is a different character. Search for a phrase containing one and you will not find it. Split on spaces in code and it will not split. PDFs and Word documents are full of them.
The last is the reason a "remove double spaces" operation sometimes appears to do nothing: the two characters are not both spaces, so a naive find-and-replace never matches.
Three: the quote marks
Smart quotes are the curly ones autocorrect produces: " " and ' '. They are typographically correct and they are not the ASCII characters " and '.
This is invisible right up until it is not. Paste a code snippet with smart quotes into a terminal and it fails with a syntax error that names a character you cannot see the problem with. Put one in a CSV and the parser takes it as literal text. The same applies to en and em dashes, which autocorrect substitutes for hyphens.
Converting to straight quotes is a one-pass operation and worth doing to anything headed for code, configuration or a data file. Worth not doing to anything headed for print, where the curly ones are correct.
Four: what is left over
Two categories that survive everything above.
Hyphenation from justified text. A word split across lines in the PDF arrives as hyphen- plus a break plus ation. Once you have joined the lines, you have hyphen- ation sitting in the middle of a sentence. These have to be found and rejoined, and no rule catches them safely, because legitimate hyphenated words exist.
Headers, footers and page numbers. Copy several pages and the running header appears every few paragraphs. They are consistent, which makes them easy to spot and easy to remove in one pass once you notice.
Doing it repeatably
Any text editor can do each of these steps. The problem with doing them in a text editor is that you do them slightly differently each time and forget one - usually non-breaking spaces, because you cannot see them.
TextLab keeps the operations as named steps you apply in order, which mostly removes the opportunity to do it inconsistently. The same applies to any tool that lets you save a sequence: the value is in not re-deciding the order every time.
For anything more specific than these standard cases, the honest answer is a regular expression, and we wrote about the handful of patterns worth memorising separately.
The sequence, in short
- Replace double line breaks with a placeholder.
- Remove all remaining line breaks.
- Restore the placeholder as a paragraph break.
- Normalise non-breaking spaces to ordinary ones.
- Collapse multiple spaces to one; strip trailing whitespace.
- Convert smart quotes and dashes, if the destination needs plain characters.
- Read through once for hyphenation and stray headers.
Only the last step needs your attention. The other six are mechanical, and that is exactly why they should not be done by hand - not because it is difficult, but because it is boring enough that step four gets skipped.