Take odrcore 6.9.0

[andiwand]

6.7.1 to 6.9.0, taking 6.8.0 on the way. 6.9.0 was tagged while this was being
written, so the pin is on a real release, not a guess.

What we ask for that we could not before

A document is drawn in the reader's own appearance. HtmlConfig.colorScheme
arrived in 6.8.0 and we set it to .system, so the page carries both sheets and
picks between them from prefers-color-scheme. The web view answers that from
the device setting, which means turning the phone dark while a document is open
costs no second translation - the page swaps itself.

The store copy for 1.35 said documents follow the light and dark appearance.
The engine used to do that on its own; since the HTML rewrite it renders light
unless asked, so this is that sentence becoming true again rather than a new
promise.

A pdf has no dark view - FileTypeCapabilities.colorScheme says so for every
type - and stays on white. Nothing to do about that here.

Our own two pages, "loading" and the error, are a web view's default styling,
which is white whatever the device says. They now name color-scheme so they
are dark alongside the document instead of flashing white in front of it.

The four config options 6.9.0 deprecates (embedOutline, noDrm,
backgroundImageFormat, backgroundImageDpi) are ones we never set.

What comes with it, for free

• A filled-in pdf form shows what was filled in, and a marked-up one its markup.
• A scanned pdf page is no longer blank: JBIG2Decode images decode.
• A pdf page is turned the way its /Rotate says, justified text is spaced as
  the file asks, and a subset font's glyph names resolve.
• A .docx keeps its paragraph spacing, line height and table row heights, and
  a table follows the style it names.
• Prose with a comma in every line is read as text, not as a two column table.
• A megabyte of text opens in under a second where it took 38.

Checked

xcodebuild test on an iPhone 17 simulator, 51 passing.

Two tests are new:

• The served page carries a (prefers-color-scheme: dark) sheet.

• Printing. Print takes the page the web view is showing, and a dark page
  printed as it stands is pale ink on white paper - the words would be gone.
  PrintAppearanceTests renders a print page out of a web view held in a dark
  window and measures it: the paper comes back white and the ink dark, so the
  web view prints in light of its own accord and the menu needs nothing.

  It asserts matchMedia first, because the trap here is that a web view not in
  a window ignores an appearance set on it - the first version of this test
  passed while never having been dark at all.

I also read the rendered colours back out of a page served in a dark window,
which is where the confidence that this works end to end comes from: body
rgb(1, 4, 9), text rgb(230, 237, 243), the sheet rgb(22, 27, 34), against
white and black in light. A screenshot would have been better, but WebKit renders
out of process and a unit test host photographs it blank.

🤖 Generated with Claude Code