Skip to content

README: name the decoders, because which one runs is the point #107

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
tannevaled merged 2 commits into from
Oct 6, 2026
Merged

README: name the decoders, because which one runs is the point #107

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
dfbc71e
README: name the decoders, because which one runs is the point
tannevaled Oct 4, 2026
a955e5d
README: the suite is RUN on eight lanes, not cross-compiled for them
tannevaled Oct 4, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
32 changes: 29 additions & 3 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -30,9 +30,20 @@ XObjects with their own matrix, bounding box and resources.
Images too: XObjects and inline images, at every bit depth the format has,
in every colour space, with a `/Decode` array, as one-bit stencils painted
in the colour in force, and with either kind of transparency — a soft mask
of levels or a stencil of what to leave out. A JPEG is decoded by the
standard library; a format nothing here reads is left undrawn rather than
drawn wrong.
of levels or a stencil of what to leave out. A format nothing here reads is
left undrawn rather than drawn wrong.

Which decoder runs is part of what this draws, so it is named:

| filter | decoder |
|---|---|
| `/DCTDecode` | [`go-images/jpeg`](https://github.com/go-images/jpeg) — Go's own `image/jpeg` with one change, a four-component picture's chroma upsampled the way libjpeg does rather than by repeating each sample. The standard library merges those four planes itself and hands back an `*image.CMYK`, so a caller cannot put it right afterwards: the planes are gone. Worth 36 levels to 2 on the cyan plate of one corpus picture. |
| `/JPXDecode` | [`go-images/jpeg2000`](https://github.com/go-images/jpeg2000), a fork for the same kind of reason |
| `/JBIG2Decode` | `go-gfx/gfx/codec`, where the fleet keeps its image decoders |
| `/CCITTFaxDecode`, `/FlateDecode`, `/LZWDecode`, `/RunLengthDecode` | `go-pdfkit/reader`, which runs them to samples |

This said *"a JPEG is decoded by the standard library"*, which stopped being
true when the fork was taken.

Text: the whole text state and every positioning and showing operator,
with glyphs taken from an embedded TrueType or OpenType font, from a
Expand Down Expand Up @@ -109,6 +120,21 @@ CI gates on **exact 100% statement coverage**, `go vet`, and a cross-compile
across `linux/{amd64,arm64,riscv64,loong64,ppc64le,s390x}`, `js/wasm`,
`darwin/arm64` and `windows/amd64`.

~~and a cross-compile~~ — **it also RUNS the suite** where it used only to
build it. Eight lanes beyond `linux/amd64`:

| lane | how |
|---|---|
| `riscv64`, `loong64`, `ppc64le`, `s390x`, `arm` | `go test ./...` under `qemu-*-static` |
| `386` | **natively** — `qemu-i386` loses the guest's floating-point state across preemption, which failed five of eight runs and passed eight of eight with `asyncpreemptoff=1`; the workflow carries that measurement beside the lane |
| `macos-latest`, `windows-latest` | `go test ./...` on the runner |

`s390x` is big-endian. Cross-compiling for darwin and windows is not running
there, and poppler and pdfium are tested on both — so those two are not new
ground, they are ground the references hold and this repository did not: path
handling, line endings and file semantics are where a Linux-only suite is
quietly incomplete.

## The rest of the family

[**reader**](https://github.com/go-pdfkit/reader) reads and writes the format ·
Expand Down
Loading