From dfbc71eea0eda54a3224b015ecec8d4883fca93d Mon Sep 17 00:00:00 2001 From: tannevaled Date: Sun, 4 Oct 2026 16:07:40 +0200 Subject: [PATCH 1/2] README: name the decoders, because which one runs is the point It said "a JPEG is decoded by the standard library". That stopped being true when the fork was taken: image.go imports go-images/jpeg, and its own comment says why -- Go's image/jpeg merges a four-component picture's four planes itself and hands back an *image.CMYK, so a caller cannot correct the chroma upsampling afterwards, and on the corpus's 258x258 YCCK picture that is worth 36 levels against 2 on the cyan plate. Two whole codecs were missing as well. The module depends on go-images/jpeg2000 and reaches JBIG2 through go-gfx/gfx/codec, and the section listing what it draws named neither -- while most of the conformance work of the last month has been about exactly those two. So the four filter families are in a table with the decoder each one reaches, since "which decoder runs is the point" is what the code says about itself one line above the import. No code change. --- README.md | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index 4ab05bf..045bf66 100644 --- a/README.md +++ b/README.md @@ -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 From a955e5d4688e81d8e184c36355e9f344d355e753 Mon Sep 17 00:00:00 2001 From: tannevaled Date: Sun, 4 Oct 2026 19:03:35 +0200 Subject: [PATCH 2/2] README: the suite is RUN on eight lanes, not cross-compiled for them The Testing section said CI gates on "a cross-compile across linux/{amd64, arm64,riscv64,loong64,ppc64le,s390x}, js/wasm, darwin/arm64 and windows/amd64", which was true until 2026-09-26 and understates what the workflow does now: beside that cross-compile there is an arch-qemu job that RUNS go test ./... on riscv64, loong64, ppc64le, s390x and arm, a 386 lane that runs it natively, and an os-matrix that runs it on macos-latest and windows-latest. A README that describes a build where the file beside it runs a test suite is understating the only thing a reader would want to know -- and the difference is not academic: those lanes found four defects on 32-bit, one inexpressible on Linux, and five POSIX-only fixtures. The 386 lane's reason is carried over from the workflow's own comment, because "runs natively" without "qemu-i386 loses the guest's floating-point state across preemption" reads as an arbitrary exception. No code change. --- README.md | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/README.md b/README.md index 045bf66..4529bfe 100644 --- a/README.md +++ b/README.md @@ -120,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 ·