Text viewer
| Document kind | text |
| Drawn from | a file — it can also be previewed in the file manager |
| Formats that open here | any file no richer viewer claims |
| Refuses to draw below | 180px wide |
What it draws
Whatever the file actually is, read-only, with line numbers. This is the viewer of last resort, and that is its job: every file you can put in a project can be opened, so "delete it" is never the only thing you can do with a file the application does not have a specialised canvas for.
A file that reads as text is drawn as numbered lines. A file that does not is drawn as a hex dump — offset, bytes, and the printable characters beside them — which is the honest way to show something that is not text rather than showing its bytes decoded into replacement characters.
What opens in it
Anything not claimed by a richer viewer. In practice: bare .txt, annotation and interval files,
configuration and log files, and any extension the application does not recognise at all.
Several formats that are technically text open elsewhere, and that is worth knowing before you
go looking for them here. A VCF opens in the variant table, a FASTQ in the read-quality viewer, a
CSV or TSV in the table, a .md in the markdown viewer, an .svg in the SVG viewer, and a FASTA or
GenBank file becomes a sequence rather than a document. If you want to see one of those as raw text,
the specialised viewers that offer a Source view are where to do it.
What this computes
Nothing. This is the viewer of last resort and it computes no scientific quantity at all: it shows you the bytes in the file.
The one determination it makes is whether the file is text, and it acts on the answer rather than hiding it:
- A file that reads as text is drawn as numbered lines.
- A file that does not is drawn as a hex dump — offset, bytes, and the printable characters beside them — because showing non-text bytes decoded into replacement characters would misrepresent the file as damaged text when it is simply not text.
That is the whole computation, and it is deliberate: every file you can put in a project can be opened, so delete it is never the only thing you can do with a file that has no specialised canvas.
What it does report is what it observed while doing that, and every one of those readings is named here in the words you would search for:
| Readout | What it is |
|---|---|
| Format | what the file was taken to be, or binary when it is not text |
| Size | bytes, and of total when only a prefix was loaded |
| Lines | 1-based line count over the loaded prefix |
| Detected encoding | the character set the bytes were judged to be in, by statistical detection over the first 64 KB |
| Confidence | the detector's own score for that judgement — not a calibrated probability, and reported as the library states it |
| Detection window | how many bytes were examined, so a claim about a prefix is not read as a claim about the file |
| Decoded as | the encoding actually used to render the text: the detection, or your override |
| Undecodable byte runs | how many replacement characters the decoder itself produced — a fact about this decode, not a detection |
| Line endings | whether the file uses CRLF |
| Final newline | whether the last line ends with one |
The uncertainty, stated plainly: encoding detection is inference from byte frequencies, and it is wrong more often on short files than long ones, because a few hundred bytes carry little evidence either way. The confidence figure is the detector's, not an independent estimate. Where it matters scientifically — a sequence file, a variant file, a table — the specialised reader for that format parses the file properly and this canvas is not what you should be relying on.
Reading it
Line numbers are 1-based, as every text editor numbers them, so a line number here is the line number a colleague means.
Whether a file is text is decided by inspection, not by its extension. The first few kilobytes are examined for null bytes and unprintable characters; if it looks textual it is decoded, otherwise the hex view is used. A file with an unfamiliar extension that happens to be plain text will therefore open as readable text.
The character encoding is detected, and the file is decoded with what was detected rather than assumed to be UTF-8. That is what stops a Russian, Greek, Japanese or Central-European document arriving as a field of replacement characters. The detection is a statistical one — it reads the byte patterns, not any declaration inside the file — so it is offered as a reading with a confidence beside it, never as a verdict, and you can override it (see Controls).
It is a claim about the beginning of the file, and says so. Only the first 64 KB are examined, because a document's script is established long before its end; the reading states the window it read, so a claim about a prefix is never presented as a claim about the whole file.
Three ways it declines to answer, each stated rather than implied. When nothing scores above a minimum confidence the reading is unknown rather than a guess. When the best candidate is below 50% it is marked uncertain. And when the detected label is one your browser has no decoder for — browsers implement a fixed set, so EUC-TW and Johab are refused — it says so instead of quietly falling back to UTF-8 and showing you nonsense.
No language is named, only the encoding. Several encodings are shared by several languages, and the reading that matters for reading the file is the encoding; a language label would be decoration that can be wrong.
Controls
Encoding. The detected encoding is used by default, and the control lists every candidate the detector scored with its confidence, so you can overrule it when you know what the file is — an extraction from an instrument or a collaborator's export whose provenance you already know. Picking one re-decodes the text in place. This is the one setting here, and it exists because a detection is a suggestion.
The text itself is read-only by design — this is the canvas for looking at a file you have not got a better tool for, and offering an edit here would be offering an editor with none of the guarantees the specialised editors have.
Where it appears
As a stage tab and in the file manager's preview aside.
Performance and limits
Only a bounded prefix of the file is loaded and decoded — enough to inspect it, small enough that opening a very large or binary file is instant and can never freeze the tab. The viewer says when it is showing a prefix and how large the whole file is, so a truncated view is never mistaken for a short file.
That bound is the honest limit of this canvas: it is for identifying and inspecting a file, not for reading a large one end to end. A file you need to read in full is a file that wants a real viewer, and if the application has none for it, that is worth reporting.
Screenshots
No frame is committed for this canvas yet. What one would show: a file with no richer reader, shown as text rather than refused.
The absence is stated rather than left as a blank heading: a picture that does not exist yet is worth knowing about, and a placeholder would be worse than either.
Related
The markdown viewer and the table, which claim files this one would otherwise catch; the file manager, where every file in a project is listed.