PDF.js sizes each line's span tightly around its glyphs, so the space between
two lines belongs to neither of them: pressing there is pressing on the rendered
page, and the drag selects nothing. A web page does not behave that way — a
paragraph's box carries its line-height leading, so a press a few pixels high
still lands on the nearest text.

Measured on a five-line page: line boxes 15px tall, 27px apart, leaving 12px
that nothing owned. Starting a drag 4px above a line selected nothing at all.

The bundled viewer now pads each line's hit box by 5px a side and pulls the
glyphs back with a matching negative margin, so the text does not move and the
gap is no longer dead space. Pressing anywhere from 6px above a line to 8px
below its top now lands on that line; 8px above still goes to the line before,
which is the right answer.

Nothing shifted: glyph tops were 144, 171, 199, 226, 253 before the change and
are 144, 171, 199, 226, 253 after it.

Checked against a baseline first, because "the PDF viewer is fiddly" is as
likely to be PDF.js as it is to be us. The same viewer, the same document and
seven kinds of drag produced byte-identical results with the extension loaded
and with it unloaded — nothing OpenRead does was making selection harder. What
it can do is ship a viewer that is easier to use than the stock one.

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>