deps(deps): bump the maven-minor-patch group across 1 directory with 4 updates

[dependabot]

Bumps the maven-minor-patch group with 4 updates in the / directory: org.junit:junit-bom, io.github.demchaav:graph-compose, io.github.demchaav:graph-compose-fonts and org.apache.maven:apache-maven.

Updates org.junit:junit-bom from 6.1.2 to 6.1.3

Release notes

Sourced from org.junit:junit-bom's releases.

JUnit 6.1.3 = Platform 6.1.3 + Jupiter 6.1.3 + Vintage 6.1.3

See Release Notes.

Full Changelog: junit-team/junit-framework@r6.1.2...r6.1.3

Commits

• f59f60d Release 6.1.3
• cd8ec92 Finalize 6.1.3 release notes
• c8729f2 Restore compatibility with GraalVM 25 (#5901)
• ddc9e74 Update graalvm/setup-graalvm action to v1.6.4 (#5959)
• fe2c52a Update plugin org.graalvm.buildtools.native to v1.1.7 (#5923)
• 62afc02 Delay GraalVM plugin updates for 3 days
• 0cc2902 Skip graalVmTest task if GraalVM env vars are not set
• f6bbfc5 Move GraalVM tests to separate test task (#5903)
• e87e052 Update plugin org.graalvm.buildtools.native to v1.1.6 (#5899)
• 1cd56df Update plugin org.graalvm.buildtools.native to v1.1.5 (#5880)
• Additional commits viewable in compare view

Updates io.github.demchaav:graph-compose from 2.1.1 to 2.2.0

Release notes

Sourced from io.github.demchaav:graph-compose's releases.

GraphCompose v2.2.0

v2.2.0 — 2026-08-15

Public API

• A paragraph can say which way it runs. ParagraphBuilder.direction(...) takes TextDirection.LTR, RTL, or AUTO, which reads the direction off the first strong character. Hebrew and Arabic were previously laid out and drawn in logical order — the order text is read in, not the order a page draws it — so every line came out reversed in a document that otherwise looked finished.

  Direction is a separate choice from TextAlign: alignment says where a line sits, direction says which way it runs. They meet in one place, so a right-to-left paragraph aligns right unless the caller chose an alignment of their own.

  Lines are resolved with the Unicode Bidirectional Algorithm, so a Latin word or a number embedded in Hebrew keeps running forwards, and the paragraph direction only decides what it is embedded in. A line with no right-to-left character resolves to itself without the algorithm running at all, so existing documents take the path they always took — held to that by the layout snapshots and visual baselines, none of which moved.

  A paragraph is the unit this applies to; the sibling entry below carries it into a table cell.

  All three wrap paths carry it: plain text, inline runs (what templates author through), and markdown. Each backend does what it must and no more — the PDF backend reverses a right-to-left run, because a PDF draws characters in the order it is given them; PowerPoint and Word have their own bidirectional engines, so the text reaches them in logical order rather than rewritten. Word is told the paragraph's base direction with w:bidi, which is the only way it can lay out a line that opens on a neutral character; PowerPoint is told the same thing per frame, because pinning a span where the page put it settles the order across the line but not which side a neutral falls on inside a frame.

  The bidirectional formatting characters (U+200E, U+200F, U+061C and the embeddings and isolates) now survive control-character sanitizing until the algorithm has read them. They are what an author uses to steer a neutral stretch of text, and removing them with the rest of Unicode category C deleted the instruction before anything could act on it. They draw nothing, so they are dropped again at the seam that measures and draws — where substituting them with ? would have put a visible mark on the page and given a zero-width character a width.

  One shaping limit is worth knowing. Letters are given their contextual forms before the line is wrapped, because wrapping measures widths and the forms are what carry them. A word longer than the column is therefore broken with the forms it was given while whole: the letters either side of the break keep their connecting strokes, as if the word continued across the line boundary. Arabic does not break words, so this only arises where the word cannot fit at all — the case every script degrades in — and re-shaping the halves would change their widths, which is what the wrap already spent.

... (truncated)

Changelog

Sourced from io.github.demchaav:graph-compose's changelog.

v2.2.0 — 2026-08-15

Public API

• A paragraph can say which way it runs. ParagraphBuilder.direction(...) takes TextDirection.LTR, RTL, or AUTO, which reads the direction off the first strong character. Hebrew and Arabic were previously laid out and drawn in logical order — the order text is read in, not the order a page draws it — so every line came out reversed in a document that otherwise looked finished.

  Direction is a separate choice from TextAlign: alignment says where a line sits, direction says which way it runs. They meet in one place, so a right-to-left paragraph aligns right unless the caller chose an alignment of their own.

  Lines are resolved with the Unicode Bidirectional Algorithm, so a Latin word or a number embedded in Hebrew keeps running forwards, and the paragraph direction only decides what it is embedded in. A line with no right-to-left character resolves to itself without the algorithm running at all, so existing documents take the path they always took — held to that by the layout snapshots and visual baselines, none of which moved.

  A paragraph is the unit this applies to; the sibling entry below carries it into a table cell.

  All three wrap paths carry it: plain text, inline runs (what templates author through), and markdown. Each backend does what it must and no more — the PDF backend reverses a right-to-left run, because a PDF draws characters in the order it is given them; PowerPoint and Word have their own bidirectional engines, so the text reaches them in logical order rather than rewritten. Word is told the paragraph's base direction with w:bidi, which is the only way it can lay out a line that opens on a neutral character; PowerPoint is told the same thing per frame, because pinning a span where the page put it settles the order across the line but not which side a neutral falls on inside a frame.

  The bidirectional formatting characters (U+200E, U+200F, U+061C and the embeddings and isolates) now survive control-character sanitizing until the algorithm has read them. They are what an author uses to steer a neutral stretch of text, and removing them with the rest of Unicode category C deleted the instruction before anything could act on it. They draw nothing, so they are dropped again at the seam that measures and draws — where substituting them with ? would have put a visible mark on the page and given a zero-width character a width.

  One shaping limit is worth knowing. Letters are given their contextual forms before the line is wrapped, because wrapping measures widths and the forms are what carry them. A word longer than the column is therefore broken with the forms it was given while whole: the letters either side of the break keep their connecting strokes, as if the word continued across the line boundary. Arabic does not break words, so this only arises where the word cannot fit at all — the case every script degrades in — and re-shaping the halves would change their widths, which is what the wrap already spent.

... (truncated)

Commits

• 1e0f0df Release v2.2.0
• 89dc8bd fix(release): move the release-status prose with the version it belongs to (#...
• fec2cba docs(readme): make the hero the banner the release advertises (#561)
• 7a4ed47 ci(release): try the cut on a line the roadmap has not staged (#562)
• 056a8b2 docs: put writing direction where a reader looks for it (#560)
• dddf663 fix(pptx): let a chip read the same on a slide as it does on the page (#559)
• 55a76be feat(api): let a table cell say which way its text runs (#558)
• 897527e docs: stage the 2.2 line so the cut can describe it (#557)
• 502740a docs: give coding agents the rules this repository already runs on (#556)
• 0460af7 perf(docx): resolve an exported image once instead of twice (#555)
• Additional commits viewable in compare view

Updates io.github.demchaav:graph-compose-fonts from 1.0.0 to 1.1.0

Release notes

Sourced from io.github.demchaav:graph-compose-fonts's releases.

GraphCompose v1.1.0

Highlights

• compose-first built-in template usage is now the documented default
• backend-neutral DocumentComposer and handler-driven rendering make the engine less PDF-centric internally
• layout snapshot testing is now part of the regression workflow for pagination and geometry changes
• runnable examples now cover CV, cover letter, invoice, proposal, and weekly schedule generation
• document-level PDF features now include QR/barcodes, watermarks, headers/footers, bookmarks, metadata, protection, explicit page breaks, and dividers
• visual showcase tests make pagination, document chrome, and barcode output easier to inspect
• benchmark tooling now includes current-speed, comparative, and diffable JSON/CSV reports
• an experimental live preview dev tool is available in test scope for fast template iteration

Added

• barcode support with QR, Code 128, and EAN-13 builders
• watermark support
• configurable headers and footers with page numbers and separators
• PDF bookmarks / outline generation
• document metadata support
• PDF protection hooks
• explicit page-break and divider builders
• visual showcase render tests
• benchmark export and diff tooling
• one-command benchmark runner

Compatibility

• older tagged JitPack releases such as v1.0.3 remain usable
• deprecated render(...) template adapters are still available for compatibility
• new docs and examples now prefer compose(...)

v1.0.3 — First Public Release

Highlights:

• Declarative document composition with reusable builders and layout systems
• Automatic multi-page layout and pagination
• Markdown support via Flexmark
• Shared font registration and reusable text styles
• Template layer with CvTheme and TemplateBuilder
• JitPack distribution for easy integration

Changelog

Sourced from io.github.demchaav:graph-compose-fonts's changelog.

v1.1.0 - 2026-04-13

Highlights

• shifted the public built-in template narrative to compose(DocumentSession, ...)
• added document-level PDF features for richer real-world output
• moved the engine further away from PDF-centric internals through backend-neutral composition and render-handler seams
• strengthened architecture guard rails for template scene builders
• expanded visual testing and benchmark tooling for day-to-day development

Added

• canonical DocumentSession contract as the primary composition seam
• layout snapshot extraction and JSON-based regression coverage for resolved document geometry
• runnable examples/ module for CV, cover letter, invoice, proposal, and weekly schedule generation
• new built-in business templates and data models for invoice, proposal, and weekly schedule documents
• barcode support with QR, Code 128, and EAN-13 builders
• watermark support
• configurable headers and footers with page numbers and separators
• PDF bookmarks / outline generation
• document metadata support
• PDF protection hooks
• explicit page-break and divider builders
• visual showcase render tests for barcodes, QR codes, pagination, and document chrome
• current-speed benchmark suite
• benchmark JSON/CSV export and diff tooling
• one-command benchmark runner: scripts/run-benchmarks.ps1

Changed

• bumped the library release to v1.1.0
• updated README installation snippets to the new release version
• documented built-in templates as compose-first by default
• refreshed README visuals to show barcode/QR and compose-first template output
• added release-facing notes for the experimental live preview dev tool in test scope
• refreshed release documentation to point contributors at visual tests and benchmark workflows

Architecture and CI

• engine-side text measurement and rendering dispatch are now more explicitly decoupled from PDFBox-specific implementation details
• added template boundary guard coverage so *SceneBuilder classes stay free of backend-specific PDFBox types
• split architecture/documentation guards into a dedicated CI job that can be required independently in branch protection

Compatibility notes

• older tagged JitPack releases remain usable as long as consumers pin a specific version such as v1.0.3
• deprecated render(...) template adapters remain available for compatibility, but new docs and examples now prefer compose(...)

Commits

• cdedd9d Prepare v1.1.0 release
• a5424fe Add quiet logging to stress and endurance benchmarks
• dc65c2b Add benchmark diff workflow to README
• 07b95b8 Add benchmark report export and usage docs
• e9f7ef1 feat: Add PdfPageBreakRenderHandler and visual showcase tests
• 2e08ecf feat: Add comprehensive document-level features and barcode support
• ecefc8e Extract shared PDF template adapter support
• 849103d Enforce template boundaries and compose-first examples
• 3567aae Split built-in templates into compose-first scene builders
• 4c6fa50 docs: Add contributor architecture rules for engine changes
• Additional commits viewable in compare view

Updates org.apache.maven:apache-maven from 3.9.12 to 3.9.16

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions

[dependabot]

Labels

The following labels could not be found: dependencies, maven. Please create them before Dependabot can add them to a pull request.

Please fix the above issues or remove invalid values from dependabot.yml.