How to actually read academic PDFs on an iPad

An iPad should be the ideal device for reading papers. In practice most people end up pinching and panning around a two-column PDF at 40% zoom, and give up. The problem is not the hardware — it is that a PDF is not a document format in the sense you want it to be.

Why PDFs fight back

The core issue: a PDF describes a page, not a text. It is closer to a set of printing instructions than to a document. It records that a particular glyph should appear at particular coordinates in a particular font. It does not necessarily record that these glyphs form a word, that these words form a paragraph, or that this paragraph continues at the top of the next column.

Everything that makes academic PDFs painful follows from this.

Two-column layouts

Text extracted naively from a two-column paper often reads across both columns, producing interleaved nonsense: half a sentence from the left column, half from the right. Reflowing it onto a phone screen is worse than useless. This is why "just use reader mode" fails on papers.

Running headers and page furniture

The journal name, the author surname, and the page number sit in the text layer exactly like body copy does. Extract without filtering and you get the article title injected into the middle of a sentence every few hundred words.

Footnotes and endnotes

A footnote is positioned at the bottom of a page, but it belongs to a specific word partway up it. Nothing in the file records that relationship. Naive extraction dumps the footnote into the prose at a page boundary, mid-paragraph.

Scanned pages have no text at all

A large portion of the older literature — and most chapters photocopied from books — is images of pages. There is no text layer to extract. It has to be recognised optically first, and OCR on a two-column scan with marginalia is a genuinely hard problem.

Ligatures and hyphenation

Typeset text breaks words across lines, and renders "fi" and "fl" as single glyphs. Extract carelessly and you get ef​ficient split in half, or a word that no search will ever match.

Getting papers onto the iPad

Worth doing well, because a bad pipeline here creates the folder of 200 unread PDFs.

• Share Sheet, not download. From Safari, use Share rather than saving to Files and importing later. The second step is where things get lost.
• arXiv and PubMed Central serve papers directly, DRM-free, no login. arXiv also offers the LaTeX source for many papers, which is often far cleaner than the PDF if you want the text.
• Check your institutional access before you leave campus. Publisher proxies expire; the paper you meant to read at the weekend often isn't there any more.
• Prefer the publisher PDF over a scan when both exist. A born-digital PDF has a real text layer; a scan of the same article does not.

What a reader has to do to make this work

Reading papers comfortably requires a tool that does structural work on the file rather than just displaying it:

• Detect the column layout and resequence so the text runs in reading order rather than geometric order.
• Identify and strip running headers and page numbers by finding what repeats at the same position across pages.
• Attach footnotes to their reference points instead of splicing them into the prose.
• OCR scanned pages and then run the same structural pass over the result.
• Rejoin hyphenated words and normalise ligatures so the text is searchable and readable.
• Find the real chapter and section boundaries so you can navigate, track progress, and stop where a section ends.

Then, and only then, is it reasonable to reflow the text for a screen.

How the common tools handle it

There is no single right answer here — annotation-first and reading-first are legitimately different tasks. But if the goal is getting through the reading list, most of these are optimised for something else.

The reading itself

Structure solved, the remaining problem is attention. Dense academic prose at the end of a long day is where reading actually fails, and no amount of text extraction fixes that.

A few things that help:

• Read the paper out of order. Abstract, then discussion and conclusions, then methods only if the result matters to you. Reading a paper linearly front to back is usually the wrong strategy — most papers are reference documents wearing narrative clothes.
• Separate the skim from the read. Decide whether a paper deserves a full pass before starting one. Most do not.
• Use a pace constraint on the parts you commit to. This is where RSVP earns its place — not for speed, but because a word-at-a-time stream leaves tired attention nowhere to wander. Turned down to 150–200 WPM on a dense results section, it is a focus lock rather than an accelerator.
• Switch to page view for figures, tables and equations. These are spatial objects and are meaningless as a word stream. A reader that can't switch instantly, at the exact word, will train you not to bother.

Where Velo fits

Velo was built for this specific case. PDFs go through a structural pass — column resequencing, running-header stripping, footnote and endnote linking, chapter detection, with Vision OCR for scanned pages — and then become readable in three modes that share one position: RSVP for focus, Scrub for rewinding, Reader for full page layout with figures intact.

Simple PDFs are handled entirely on-device. Genuinely difficult ones — dense academic layouts, poor scans — can be sent through Enhanced Processing, which is opt-in per document, because that is the only case where the file leaves your device.

It will not make a badly scanned 1970s photocopy pleasant. Nothing will. But the gap between "unreadable on a tablet" and "readable" is mostly structural work, and that work can be done.

← All guides