Repository navigation
windows-ui: PdfView is a placeholder STATIC label — no real PDF rendering #6613
Description
PdfView on Windows is a stub-with-state: a STATIC control showing [PDF: name — page X/Y @ Z%], with page state tracked but no page pixels ever rendered. macOS backs the same widget with PDFKit, so cross-platform apps using PdfView get a text label instead of a document on Windows. Found in the 2026-07-18 Windows audit (main @ 58e555e).
Evidence
crates/perry-ui-windows/src/widgets/pdf_view.rs:1-9— module doc: STATIC control showing "[PDF: filename] page X of Y"; rendering deferred.crates/perry-ui-windows/src/ffi/rich_pdf_map.rs:38-40— "PdfView (API for creating PDF reports and a Pdf Viewer widget #516) — Win32 stub-with-state... Real page-bitmap rendering... is a follow-up."
Suggested fix
Render real pages via WinRT Windows.Data.Pdf (PdfDocument -> page bitmap blitted into the control), or host WebView2 and use its built-in PDF viewer.
Activity
proggeramlug commentedon Jul 30, 2026
Revalidated against current
mainwhile processing the oldest Windows tickets. This is still current: the Windows backend remains a stateful STATIC-label placeholder and does not render PDF pages. I found no assignee or active PR. Keeping it open—the correct fix needs a substantive WinRTWindows.Data.Pdfor WebView2 rendering backend, not a stale/no-op closure.proggeramlug commentedon Aug 24, 2026
Closed by #8717, landed on
mainvia #8721 (squash3f655301e).That PR was landed through a batch wrapper PR rather than merged directly, so GitHub's close keyword never fired at merge time. Verified before closing: the
Windows.Data.Pdfrender path is onmainincrates/perry-ui-windows/src/widgets/pdf_view.rs, replacing the STATIC-label placeholder.