Has anyone solved printing JSM Knowledge Base articles from the customer portal?

@Chris Green , you have already eliminated the easy answers, so let me name the mechanism that kills them and then the two routes that survive it.

Why every Confluence-side route fails: the portal reader is, in most cases, a portal-only customer with no Confluence licence. The article they see is the Confluence page rendered inside the portal shell by JSM; the customer never touches Confluence itself. So Export to PDF, the PDF stylesheet, Confluence print CSS and every Confluence app that adds a print button are all on the wrong side of the wall. Browser print is the only exporter the customer has, and it prints what the portal renders, chrome included, with print CSS that Atlassian owns and the portal theme cannot override. That is why JSDCLOUD-4045 has sat in Gathering Interest since it was filed, and why the workaround field on JSDCLOUD-15848 is empty.

Route 1, no code, works today: the browser's reader view. Chrome's Reading mode (side panel), Edge's Immersive Reader and Safari's Reader all strip the portal chrome and render the article body alone; printing from reader view gives an article-only page with images and tables intact, at the current content, respecting whatever the customer was allowed to see. It is not a button on your portal, but it is a one-line instruction at the bottom of every KB article ("To print, open Reader view then print"), and in my experience it closes most of the actual demand. Test it against your worst table before relying on it; wide tables still wrap.

Route 2, Forge, permission-safe by construction: Forge has JSM portal modules (portal header, footer, sub-header and request-view actions) that can put a "Print this article" control on every portal page. The design that respects permissions:

1. The Forge control opens a Forge-rendered view for the current article ID.
2. The app checks the customer can see that article through the JSM knowledge base API, which only returns articles visible to the caller, so a customer cannot print what they cannot read.
3. Only then does the app read the page body as the app from the Confluence API and render it as plain article HTML with @media print rules you own, and the browser prints that.

Always current, no PDF attachments, no per-article maintenance, and the permission check is the same one the portal uses. I have not built this exact app, so treat it as a design, not a tested recipe; the pieces are documented and the pattern is standard.

Route 3, Marketplace: there are portal customisation apps that replace the KB rendering with their own view, and some include a print or PDF action. I would evaluate any of them on one question only: does its print view call the KB API as the customer, or fetch the page as the app without a visibility check? The second kind leaks restricted articles the moment someone guesses a page ID.

And vote on JSDCLOUD-4045 with a link to this thread; a Champion's write-up with three tickets cross-referenced is the kind of comment that moves a Gathering Interest ticket.