The same file must draw the same pixels every time

[tannevaled]

reader v0.4.2 stopped letting Go's map iteration order decide what an inline
image says. A dictionary may carry both spellings of a key and disagree with
itself — /W 20 beside /Width 10, /CS /RGB beside /ColorSpace /3chanRGB — and
expanding it in one pass over the map let the randomised order pick the winner.
The consequence landed here: eight renders of safedocs'
Inline_Image_Abbreviations fixture through this package gave five different
pictures.

before 79b9edef 79b9edef b2594aef 6bf89747 6bf89747 544c8e6b 79b9edef 43030bf3
after 87f31291 x 8

Nothing in this suite could have seen that. Every test here draws a page once,
and non-determinism is invisible to a suite that never repeats itself.
determinism_test.go repeats itself: it builds a one-page file whose inline
image says /W 2 and /Width 1, and /H 1 and /Height 2 — the two readings give a
2x1 image and a 1x2 one, which do not cover the same pixels — and draws it
forty times, requiring every draw to match the first. Against reader v0.4.1 it
fails on the second draw.

The image is built in the test rather than committed, so nobody else's PDF
enters the repository.

HOW MUCH OF THE EARLIER MEASUREMENT THIS PUTS IN DOUBT

Little, and the amount is measured rather than assumed. Rendering the first page
of 3 668 corpus files three times over — 1 633 real forms, 1 400 arXiv papers,
all 635 vendor fixtures — turns up exactly one file that disagrees with itself,
and it is that fixture. So the corpus figures in the v0.8.0 notes stand, with
one page of noise in them.