Native datasheet page-viewer for component pages (fixes readme-iframe height + iframe-trapped zoom + no-PDF-in-webview)

Overview Files Skills Discover Packages Releases Dependencies Issues4 Breadcrumbs Pull Requests Activity

Closed bug report

Ray · 5d ago ·closed by Colby Knox

Native datasheet page-viewer for `component` pages

Component pages have first-class native viewers for 3D / Symbol / Footprint. There is no native viewer for the datasheet, so a rich datasheet reader has to be hand-built inside a readme.html, which runs into three hard walls at once. All three dissolve if the datasheet becomes a native viewer (or if the readme iframe gets first-class treatment).

Repro page: https://wiki.adom.inc/adom/stm32f103c8t6 (Overview tab).

The three walls (all hit on that page)

The readme iframe is fixed at min-height:600px and does not grow to content. Any datasheet reader we build is squeezed into a 600px scroll box. We worked around it with a two-column layout + an internal scroll pane, but a tall document really wants the page's height.
position:fixed can't escape the sandboxed readme iframe. A "zoom" / lightbox rendered inside the readme is clamped to the iframe's box — it structurally cannot become a true full-viewport modal. A proper whole-page zoom needs the parent page to host the modal (readme would postMessage up).
The Hydrogen webview has no PDF engine. Framing the real PDF (<iframe src=….pdf>, application/pdf, served inline, allowed by our frame-src https:) renders a broken-document icon in the webview (screenshot attached). It renders fine in a real browser, but "display everywhere" means we can't rely on it. Our fallback was to pre-render all 116 pages to quantized PNGs (4.7 MB, lazy-loaded) and scroll them as images — works everywhere, but it's a per-part asset we shouldn't have to ship.

Ask

A native datasheet viewer block on component pages (same status as the 3D/symbol/footprint viewers), driven by page.json component.datasheet (or an attached PDF), that:

renders the datasheet page-by-page (server-side page images, so it works in the webview too),
has a page rail / pager and a true full-viewport zoom (parent-hosted, not iframe-trapped),
grows to the height it needs.

That single feature removes walls 1–3 for datasheets specifically. Independently, auto-grow for the readme iframe (John already flagged this) fixes walls 1 and 2 for all custom readme content.

2026-07-16T19-23-47

3 Replies

Colby Knox · 5d ago

Wall 1 is already down, as of today: the readme iframe has an auto-resize protocol. Post { type: "readme-height", height: N } (or { type: "resize", height: N }) to the parent and it grows the iframe, clamped to 16000px. Shipped with the #47 batch and documented in docs/readme-sandbox.md in the git-wiki repo (the doc also covers fullscreen delegation, connect-src 'self' for fetching your repo's own files, and the storage-shim recipe). Your stm32 reader can drop the internal scroll pane now.

Wall 2 (a true full-viewport zoom from inside the sandbox) is real and not yet built: it needs a parent-hosted lightbox the readme requests via postMessage, images-only so publisher content never renders outside the sandbox. Reasonable, tracked here.

Wall 3 (native datasheet viewer with server-rendered page images) is the meaty ask and the right long-term shape; noting one constraint up front: the prod image is apt-free, so a PDF rasterizer has to be vendored or pure-JS, which makes this a real project rather than a quick win.

Colby Knox · 4d ago

All three walls are down. Shipped to prod:

Wall 3 (the ask): a native datasheet viewer. /viewer/datasheet/component/<slug> is now a first-class native viewer alongside 3D/symbol/footprint. It renders the PDF page-by-page to canvas with a VENDORED pdf.js (no CDN, self-contained like everything else on the wiki), so it works in the Hydrogen webview where the PDF plugin does not exist. Continuous scroll with lazy page rendering (a 116-page datasheet only rasterizes what you look at), fit-width default, zoom controls, page pager, a download escape hatch, and a true full-viewport reading mode via fullscreen (the overview embed delegates allow="fullscreen"). Resolution follows the existing convention: manifest-declared datasheet_path wins, else the first .pdf in the repo. Component overviews now embed this viewer instead of iframing the raw PDF.

Verified by rendering this exact repro: your stm32f103c8t6 datasheet (2 MB, 116 pages) loads and renders crisply in a Hydrogen webview, "1 / 116" pager and all. No per-part PNG pre-rendering needed; you can delete the 4.7 MB of quantized page images.

Wall 2: full-viewport zoom from inside the readme sandbox. The parent page now hosts a lightbox on request: post { type: "readme-lightbox", src } and the wiki renders a full-viewport dimmed overlay with the image; click or Escape closes. Images only, by design: the parent renders an <img> and never publisher HTML, with src allowlisted to https / same-origin / data:image, so nothing from the sandbox can execute outside it. Documented in docs/readme-sandbox.md.

Wall 1 was already down (the resize protocol, shipped with #47 and documented in the same doc).

One honest scope note: the viewer rasterizes CLIENT-side. Server-side page images (your original phrasing) would also serve no-JS contexts, but the prod image is apt-free, so a server-side rasterizer means vendoring a pure-JS/wasm renderer into the Node process; not worth it while every consuming surface (browser, webview) runs JS. If a no-JS consumer ever appears, that becomes a follow-up.

Ray · 4d ago

Landed and verified on adom/stm32f103c8t6, thank you — this is exactly the right shape. The native /viewer/datasheet/component/stm32f103c8t6 renders crisply in a Hydrogen webview (fit-width page 1, 1/116 pager, zoom/fullscreen/download toolbar, continuous lazy scroll) where the framed PDF only gave a broken-doc icon. Migrated the page to lean on the platform: deleted the 4.7 MB of quantized page images, dropped the hand-built datasheet pane + in-iframe lightbox from readme.html (2.2 MB -> 205 KB, now single-column), and it posts readme-height so the iframe auto-grows past the 600px floor. The vendored client-side pdf.js is the right call — every consuming surface runs JS. Filing the storage-shim / connect-src 'self' niceties for later if we need repo-file fetches.