GraphCompose v2.3.0 — chrome, composed

[DemchaAV]

The banner above is itself a GraphCompose document — rendered by the engine from the same DSL you'd use in your app.

GraphCompose v2.3.0 is on Maven Central. The theme: page chrome built from nodes.

A repeating footer used to be three text slots and three placeholder tokens. Now a DocumentPageZone takes a content function and lays a real node subtree into the band — and because the band goes through the same layout and render path as the body, everything the body can do works there without the zone knowing about any of it.

• DocumentPageZone.footer(height, page -> node) — a badge chip, a real link annotation, an image, right-to-left text, any font the document has, all on one line. PageContext hands each page its numbers as plain Java values, so page.number() + " / " + page.total() replaces the tokens — and roman numerals, an offset, or a different line on the last page are ordinary Java in the same lambda. DocumentPageZone.header(...) builds the running head the same way.
• Word gets its first header/footer. page.pageNumber() returns a node rather than an int: a fixed-layout export resolves it to text, and the DOCX export maps it onto Word's live PAGE / NUMPAGES field — styled, so a 9pt bold counter stays 9pt bold in Word. One zone definition serves both lanes.
• A page reference works inside a zone. addPageReference("appendix") in a running head resolves against the body's own anchors, so "Appendix · p.4" is looked up on every page, never typed. appliesTo(page -> !page.isFirst()) keeps a band off the cover — and painting is all it decides: a reserving zone's height comes out of every page either way, so hiding the band on the cover reflows nothing.
• The text header/footer catches up on two counts. DocumentHeaderFooter.fontName(...) picks the family the band is typeset in — a Cyrillic page counter set in PT Sans keeps its letters where standard-14 Helvetica drew ? — and reserveSpace(true) takes the band out of the content area so the body is never laid out underneath it. Both additive; a header that names neither renders byte-identically to 2.2.
• The knowledge pack ships with the release. A tracked, generated description of the whole public API lives under knowledge/ — extracted from the compiled classes, gated in CI so it cannot drift from the code, with documentation claims resolved to executable proofs. An offline, queryable bundle is attached to this release's assets: "does this method exist, and what is its signature" is now answerable without the sources.

The contract worth calling out: a zone does not paginate. Content that outgrows the band raises AtomicNodeTooLargeException naming the zone and its height — whether the overflow is an atomic row or a paragraph that would have quietly continued onto a second band. A footer that silently loses half of what it was given is the harder bug to find, so both overflows get the same loud answer.

Known limits: an arbitrary appliesTo predicate cannot be evaluated where Word owns pagination — a DOCX export writes such a zone on every page and says so in the log. The semantic PPTX export does not carry zones; the fixed-layout PPTX backend draws them.

Install:

<dependency>
    <groupId>io.github.demchaav</groupId>
    <artifactId>graph-compose</artifactId>
    <version>2.3.0</version>
</dependency>

Nothing breaks 2.2 — the zone API is additive, DocumentHeaderFooter is unchanged, and japicmp holds the train binary-compatible against the published baseline.

Release notes: https://github.com/DemchaAV/GraphCompose/releases/tag/v2.3.0
Maven Central: https://central.sonatype.com/artifact/io.github.demchaav/graph-compose/2.3.0
Showcase: https://demchaav.github.io/GraphCompose/

As always — author intent, not coordinates.