The print preview URL is export?format=html-print&xpage=get&outputSyntax=plain&sheet=XWiki.PDFExport.Sheet (PrintPreviewURLBuilder.java:91).
contentvars.vm:26-31 turns $request.outputSyntax into $tdoc.displayDocument(plain/1.0), which pushes plain/1.0 as the rendering context target syntax for the whole sheet rendering.
LiveDataImportmapUIExtension.execute() (17.10) goes through the template manager, which tags the Velocity output as new RawBlock(result, renderingContext.getTargetSyntax()) — i.e. plain/1.0 (TemplateAsyncRenderer.java:180-181, same in InternalTemplateManager.java:747-748).
$services.rendering.render(block, 'xhtml/1.0') does pick the right renderer — but XHTMLChainingRenderer.onRawText silently drops raw text whose syntax isn't HTML-family → empty string.
Why master is unaffected: JavascriptImportmapUIExtension returns new RawBlock(..., HTML_5_0) explicitly (JavascriptImportmapResolver.java:191), so it no longer depends on the ambient target syntax. The underlying bug is still there on master: any template-based or wiki-based UIX on org.xwiki.platform.html.head still breaks, because AbstractWikiUIExtension.configure() also propagates renderingContext.getTargetSyntax() into the UIX execution.
About your principle — one constraint worth flagging: Velocity evaluates $uix.execute() before render() is called, so RenderingScriptService.render(Block, syntax) can't retroactively fix the block. To give the render call's syntax priority, the push has to wrap the execution, which means a combined API (e.g. $services.uix.render($uix, 'xhtml/1.0')) rather than a change inside render().
Marius Dumitru Florea on 03/Sep/26 17:04
PDF export needs to use outputSyntax=plain when loading its print preview:
XWiki.PDFExport.Sheet emits the whole HTML document from a velocity wiki="false" block (Sheet.xml). With wiki="false", AbstractScriptMacro.parseScriptResult runs the output through the plain text parser (AbstractScriptMacro.java:211-220) — so the HTML becomes Word/Space/NewLine blocks, not a RawBlock. Only PlainTextChainingRenderer prints those verbatim; the html/5.0 and xhtml/1.0 renderers XML-escape them, so you'd get <html>… in the print preview. outputSyntax=plain is load-bearing for the sheet's own output.
Making an HTML output syntax viable would mean changing the sheet to emit a real raw block — e.g. wrapping #renderPDFSheet(...) in html clean="false" and flipping the macro to velocity (wiki=true). That re-parses the generated output as xwiki/2.1, meaning arbitrary exported page content gets scanned for /html — a macro-injection hazard for a marginal gain. I'd not go there.
So the print preview's outputSyntax should stay plain, and the fix belongs where the mismatch actually is: the html.head UI extensions are executed with the ambient plain/1.0 target syntax but rendered to xhtml/1.0.
Suggested fix:
17.10.x — liveData/importmap.vm is a template-based UIX, so TemplateAsyncRenderer tags its output RawBlock(plain/1.0) and the XHTML renderer drops it. Adding ##!raw.syntax=html/5.0 to the template makes it declare HTML explicitly — exactly what master's JavascriptImportmapResolver does with new RawBlock(…, HTML_5_0). One line, no API change, backport-friendly.
master — the latent generic bug remains for any template-based UIX on org.xwiki.platform.html.head. Fixing it per your principle needs a combined execute+render API, because Velocity evaluates $uix.execute() before render() ever runs.
This message was sent by Atlassian Jira (v9.3.0#930000-sha1:287aeb6)
If image attachments aren't displayed, see this article.
