Opening a DocumentSession resolves a FontMetricsProvider so text can be measured, and graph-compose-render-pdf is the only artifact that publishes one. Two consequences reach consumers today:
DOCX is not installable on its own. render-docx/pom.xml declares render-pdf at test scope — enough for the module's own suite, which builds a session to exercise the exporter. A consumer who installs graph-compose-core + graph-compose-render-docx fails at create() with MissingBackendException before any export runs. Surfaced by the new s8-core-render-docx release-smoke scenario, which is why that scenario pins core + render-docx + render-pdf. Documented as a requirement in render-docx/README.md for 2.1.0.
PPTX drags in the whole PDF stack. render-pptx declares render-pdf at compile scope deliberately — it reuses the PDF font-measurement library so glyph widths stay aligned with the widths that produced the layout graph, and it re-renders through the PDF backend for the clip raster fallback. The measurement half of that coupling is not inherent; the raster half is. So "install exactly what you render" is not fully true for either POI backend.
Extracting the font-measurement seam into its own artifact (or shipping a default provider in core) would let a DOCX consumer install two coordinates and a PPTX consumer avoid PDFBox except when clipping actually rasterises.
Not a 2.1.0 blocker: both combinations work once the PDF backend is present, and that is now documented and covered by release smoke. Raising the dependency scope in render-docx was considered as a quick fix for 2.1.0 and rejected — it would widen every DOCX consumer's tree while leaving the underlying coupling in place.
Related: the roadmap's "Backend-neutral layout measurement" item.
Opening a
DocumentSessionresolves aFontMetricsProviderso text can be measured, andgraph-compose-render-pdfis the only artifact that publishes one. Two consequences reach consumers today:DOCX is not installable on its own.
render-docx/pom.xmldeclaresrender-pdfat test scope — enough for the module's own suite, which builds a session to exercise the exporter. A consumer who installsgraph-compose-core+graph-compose-render-docxfails atcreate()withMissingBackendExceptionbefore any export runs. Surfaced by the news8-core-render-docxrelease-smoke scenario, which is why that scenario pins core + render-docx + render-pdf. Documented as a requirement inrender-docx/README.mdfor 2.1.0.PPTX drags in the whole PDF stack.
render-pptxdeclaresrender-pdfat compile scope deliberately — it reuses the PDF font-measurement library so glyph widths stay aligned with the widths that produced the layout graph, and it re-renders through the PDF backend for the clip raster fallback. The measurement half of that coupling is not inherent; the raster half is. So "install exactly what you render" is not fully true for either POI backend.Extracting the font-measurement seam into its own artifact (or shipping a default provider in core) would let a DOCX consumer install two coordinates and a PPTX consumer avoid PDFBox except when clipping actually rasterises.
Not a 2.1.0 blocker: both combinations work once the PDF backend is present, and that is now documented and covered by release smoke. Raising the dependency scope in
render-docxwas considered as a quick fix for 2.1.0 and rejected — it would widen every DOCX consumer's tree while leaving the underlying coupling in place.Related: the roadmap's "Backend-neutral layout measurement" item.