1.6.1

A page says how big it is in the unit it was engraved in.

One fix. A unitless SVG length is a user unit, and a user unit is a CSS pixel — 1/96
inch, not 1/72 — so the root element's width="792" never said 11 inches, it said 8.25.
Every page CeolKit emitted declared itself at 75% of the size it was engraved for, and
anything that trusted that declaration got the smaller page.

The fix (#165)

The root now writes 792pt. The viewBox is unchanged, so the document is exactly
self-consistent: one user unit is one point, which is what every coordinate in the body
already assumed. Nothing about the drawing moves, and nothing about the geometry the
library computes changes — only what the page tells a reader about its own size.

What that reader was getting wrong:

• A PDF whose media box is taken from the document opened at 8.25 × 6.375 in rather than
  11 × 8.5.
• rsvg-convert without an explicit -w rasterised at three quarters of the intended
  scale.
• A browser embedding the page at its natural size laid it out 25% small.

CeolKitSVGGeometry needed the matching change. It read the root through the generic
attribute reader, which drops any value Double(_:) cannot parse, so 792pt would have
made pageSize(in:) throw missingPageDimensions on every page. It now reads the
root's two lengths directly and resolves an absolute unit suffix — pt, px, in, pc,
cm, mm, or none — to points. A length it cannot resolve, such as 100%, is still
missingPageDimensions. The generic attribute reader is untouched, because body values
genuinely are unitless user units.

PageGeometry.width and .height are therefore now in points in fact, not only in the
documentation.

What's Changed

• Fix #165 — the root declares its size in points by @sbeitzel in #166
• Release 1.6.1 by @sbeitzel in #167

Full Changelog: v1.6.0...v1.6.1

Upgrading

Source-compatible with 1.6.0. No API changed.

The emitted SVG differs from 1.6.0 in exactly two characters per page — pt on the root's
width and height — so a snapshot test that pins page markup needs re-recording.

If you worked around the old declaration downstream, remove the workaround: a rasteriser
told to render at 4× no longer needs the 96/72 correction, and a PDF pipeline that read
the document's own size no longer needs to override it.