The Code ↔ Paper reader

The reader is the first section of a paper's page when its authors' code was read: the paper on the left, the code on the right, and between them the matches that OSCR computed — which paragraph of the paper goes with which lines of code.

Two panes

The reader takes the window's whole width, wider than the rest of the page, because code needs it. Each pane scrolls on its own. The bar above them says how many matches there are and by which method they were computed; its buttons move between matches and hide the paper.

Where the paper comes from

The paper is not stored by OSCR, nor sent by it: when the pane is shown, your browser fetches the paper's full text from Europe PMC (the open-access XML) and shows it as plain text, its paragraphs numbered in the XML's order. Europe PMC often takes a few seconds; the pane says it is loading, and when it is slow. A try waits 20 seconds and is made once more. If Europe PMC still does not answer, a paper in PubMed Central is read from NCBI's copy instead, and the pane says so; its paragraphs may be numbered otherwise, so each match is placed by its section and its evidence terms. When neither answers, the pane keeps links to the paper at doi.org and on Europe PMC, and a button to try again. Without JavaScript, only those links are there.

These requests go from your browser to Europe PMC (www.ebi.ac.uk) or NCBI (eutils.ncbi.nlm.nih.gov) directly: those services see your address, as they would if you read the paper on their sites (the privacy page).

Matches and their colours

A match joins one paragraph of the paper and a range of lines of one file. Both sides take the same colour — six colours used in turn, so that neighbouring matches differ: a light tint on the paragraph and on its lines, with a thin mark in the paragraph's margin and in the code's gutter. The match you are reading turns a stronger shade, on both sides, with a wider mark. The rest of the code keeps its white ground and its syntax colours.

• Click a coloured paragraph: its lines come into view, in the code pane.
• Click coloured lines: their paragraph comes into view, in the paper pane.
• "The matches", above the panes, unfolds the list of every match: the paragraph's section, the file and its lines, the score, and the evidence — a few short technical terms that both sides share (identifiers, constants, tool names), never a sentence of the paper. Each entry opens its match on both sides.

Matches are computed by the harvester beforehand (method lexical-v1): a pair is kept only when several rare terms agree on both sides. They are proposals, not statements by the authors; a wrong one can be reported from the paper's Contribute section. A paper without matches yet still shows its paper and its code side by side.

Weak matches

When a match covers a whole file (nine tenths of its lines or more), it says only "this paragraph goes with this file". Such a weak match tints only the file's first line, and the list of matches marks it "a weak match".

Moving between matches

"‹ Previous" and "Next ›" go through the matches in order, opening each on both sides. The page opens on the first match of the file it shows. The address follows what you read: #pair-3 for a match, ?path=… for a file, #L10-L20 for lines, so a link you copy opens the same view.

Hiding the paper

"Hide the paper" folds the paper pane; the code then takes the whole width. "Show the paper" brings it back. Your browser remembers the choice for the next papers (in its local storage, on your device only; nothing is sent). Hiding the paper before it has loaded also means it is not fetched.

The files, and the tools of a file

• Files opens or closes the list of the code's files: the matched files first, then the repository's folders, with a filter. A file that cannot be shown here — neither copied nor shown from its source — is in italics.
• Wrap wraps long lines instead of scrolling sideways.
• Copy copies the whole file; line numbers are never part of what you copy.
• Link copies a link to the file, or to the lines you selected: click a line number, and Shift-click another for a range.
• Raw downloads the file as it is shown: OSCR's copy, or what your browser fetched from its source.
• ⋯ links to the file and to its repository at the source, at the verified commit, and says why.

Notebooks show their cells, their Markdown as text; the syntax is coloured by language. Email addresses written in the code are hidden, with a note.

A copy, or the source

A file's text is shown from OSCR's copy only when its repository's licence allows it. Otherwise OSCR keeps no copy, and your browser fetches the file from where its authors published it, at the verified commit or record — GitHub, GitLab.com, Bitbucket, Codeberg, Hugging Face or Zenodo, or Software Heritage for the other forges and for a file inside a Zenodo archive. It checks that the file's SHA-256 fingerprint is the one OSCR computed, hides its email addresses, and only then shows it and draws its matches, under a notice that says where it comes from and that no copy is kept. Without JavaScript, it is not fetched.

A file whose fingerprint differs, that does not answer, is larger than 1 MB or is not text, is not shown: the reader says why in words and links to it — and to the exact lines of each match — at the source. So do the files of hosts that do not let another site's page read them (OSF, PubMed Central's supplementary files). These requests go from your browser to the host directly: it sees your address, as when you open the file there (the privacy page). The rules are in the code policy. A file may also be withheld at a removal request: the reader says so, and fetches nothing.

On a phone

On a narrow screen the panes are stacked, the code first; the list of files, when open, sits above the code. Long lines scroll inside the code pane, never the page.

Keyboard and screen readers

Each pane can be focused and scrolled with the keyboard; every button is a real button with a label, and the paper's loading state is announced. Colours are never the only sign of a match: the list of matches names each one in words. The accessibility statement lists what is known not to work well yet.