PdfSource
Unified, sealed description of where a PDF comes from.
Earlier revisions of the library mixed two concerns: in-memory payloads were modelled as PdfSource while remote / disk / asset loads travelled as a bare uri: String. That string had to be pattern-matched ("does it start with https://?"), couldn't carry per-shape configuration (headers, timeouts), and made "URI" a misnomer for what was in practice five different transports.
Every variant now lives under PdfSource, split along two axes:
In-memory — Bytes, Document. The bytes are already in hand; the viewer renders synchronously.
Async — FilePath, Remote, ContentUri, Asset. The viewer fetches the bytes on a background dispatcher, showing a loading state until they arrive.
Use the matching constructor directly when you know the shape (e.g. PdfSource.Remote("https://…", headers = mapOf(…))), or fall back to auto when you only have an opaque string.
PdfDocument payloads stay special-cased because the viewer can overlay an invisible, selectable text layer on top of each rasterised page — that overlay needs the captured PdfTextRuns and PdfHyperlinks, which only the PdfKmp DSL produces.
Inheritors
Types
Android-only payload referenced by a content:// URI. Resolved through the host's android.content.ContentResolver. On iOS, the resolver throws — content URIs are an Android concept.
PDF payload paired with the laid-out text runs and hyperlink annotations the renderer produced. Lets PdfViewer mount a transparent, selectable text overlay on each page and attach a clickable layer for hyperlink targets.
PDF fetched from an HTTP(S) endpoint. Bytes are downloaded in full to a transient buffer before rendering starts — this implementation is not streaming. Apps that need progress reporting or streaming should fetch the bytes themselves and hand them in as Bytes.