@reekon-tools/react-native-pdf-canvas 0.1.0

package/dist/rasterizer/ios.d.ts

@@ -0,0 +1,84 @@
+/**
+ * The TypeScript half of the iOS backend.
+ *
+ * FOUR THINGS, and nothing else. The wire format, the error mapping, the
+ * transport negotiation, the base64 fallback, the cancellation wiring and the
+ * phase timings are all in `./native-bridge.ts`, shared byte-for-byte with
+ * Android. What is iOS's own is the id, the capabilities, the alpha encoding and
+ * which `PdfSource` shapes it accepts — which is the whole point of the seam
+ * existing.
+ *
+ * PURE ON PURPOSE, like `./android.ts`. Nothing here imports `react-native`, so
+ * the adapter is testable in vitest against a fake native module.
+ * `./index.native.ts` is the only file that resolves the real one.
+ *
+ * The native side is `ios/Sources/PdfCanvasCore/`, a React-free Objective-C++
+ * library that also builds under SwiftPM (`ios/Package.swift`) so its geometry,
+ * rotation, stride, alpha and error mapping are provable with `swift test` on a
+ * Mac — no device, no app, no simulator. `ios/Sources/PdfCanvasBridge/` is the
+ * React binding and the JSI slot store, and joins the build only through the
+ * podspec.
+ *
+ * ------------------------------------------------------------------------
+ * TWO ENGINES BEHIND ONE BACKEND, chosen per render by `annotations`.
+ * ------------------------------------------------------------------------
+ *
+ * `annotations: false` — every tile the controller asks for — draws through
+ * `CGContextDrawPDFPage`, which composites the page's content stream and NOT its
+ * annotation appearance streams. `annotations: true` — `renderPage`'s default,
+ * which is the thumbnail and print path — draws through PDFKit's
+ * `-[PDFPage drawWithBox:toContext:]`, which composites both.
+ *
+ * THAT MAKES iOS THE ONLY BACKEND THAT HONOURS `annotations: false`. Android
+ * cannot (`PdfRenderer.Page.render` has no annotation switch at any API level)
+ * and the PDFium web backend does not pass `FPDF_ANNOT` either. So an app that
+ * draws its own copy of a PDF-embedded annotation on the Skia layer sees it once
+ * on iOS and twice on Android — a real cross-platform difference, and the right
+ * way round.
+ */
+import type { TakePixels } from './native-bridge.js';
+import type { PageRasterizer } from '../types.js';
+export interface IosRasterizerOptions {
+    /**
+     * Concurrent renders. Clamped to [1, 4] natively — each slot is one more
+     * `CGPDFDocumentRef` over its own `CGDataProvider`, plus, once an
+     * `annotations: true` render asks for one, its own lazily-opened `PDFDocument`.
+     *
+     * ONE, AND FOR A WEAKER REASON THAN ANDROID'S. Android declares 1 because
+     * lanes above 1 were measured to make things WORSE — AOSP serialises
+     * `PdfRenderer` behind a process-wide PDFium lock that convoys, so four threads
+     * inflate the per-tile PDFium phases by up to 30x. None of that evidence is
+     * about CoreGraphics, and it must not be cited as though it were: the lock
+     * being measured there lives in `android_graphics_pdf_PdfRenderer.cpp`.
+     *
+     * WHAT IS ACTUALLY KNOWN ABOUT iOS. The pool exists so that concurrency is
+     * expressible at all: `CGPDFDocumentRef` is not documented thread-safe, and a
+     * single one shared across lanes would have to be serialised by a lock we own,
+     * which buys nothing. Opening the file once per lane gives each lane an
+     * independent parse — the same argument `PdfRendererPool` makes for not using
+     * `dup(2)`. Whether that then converts into wall-clock is unmeasured, which is
+     * why the default is the conservative 1 rather than the optimistic 2: an
+     * unmeasured speedup that is really a slowdown is exactly the mistake Android's
+     * `poolSize: 2` was, and it survived for months.
+     *
+     * Raising it does two things at once, as on Android: it opens more documents
+     * AND it widens the controller's lane bound, because it is also what the
+     * rasterizer reports as `RasterizerCapabilities.maxConcurrentRenders`. Measure
+     * before raising it, on a real drawing rather than a synthetic fixture — the
+     * Android note explains why that distinction inverted the answer there.
+     */
+    poolSize?: number;
+    id?: string;
+    /**
+     * How to find the installed JSI host function. Injected only by tests; the
+     * default reads `globalThis`.
+     */
+    lookupTakePixels?: () => TakePixels | null;
+}
+/**
+ * Wraps a native module in a `PageRasterizer`.
+ *
+ * The native module is INJECTED rather than imported so this file stays pure.
+ * `getDefaultRasterizer()` in `./index.native.ts` supplies the real one.
+ */
+export declare function createIosRasterizer(native: import('./native-bridge.js').PdfCanvasNativeModule, options?: IosRasterizerOptions): PageRasterizer;

package/dist/rasterizer/ios.js

@@ -0,0 +1,155 @@
+/**
+ * The TypeScript half of the iOS backend.
+ *
+ * FOUR THINGS, and nothing else. The wire format, the error mapping, the
+ * transport negotiation, the base64 fallback, the cancellation wiring and the
+ * phase timings are all in `./native-bridge.ts`, shared byte-for-byte with
+ * Android. What is iOS's own is the id, the capabilities, the alpha encoding and
+ * which `PdfSource` shapes it accepts — which is the whole point of the seam
+ * existing.
+ *
+ * PURE ON PURPOSE, like `./android.ts`. Nothing here imports `react-native`, so
+ * the adapter is testable in vitest against a fake native module.
+ * `./index.native.ts` is the only file that resolves the real one.
+ *
+ * The native side is `ios/Sources/PdfCanvasCore/`, a React-free Objective-C++
+ * library that also builds under SwiftPM (`ios/Package.swift`) so its geometry,
+ * rotation, stride, alpha and error mapping are provable with `swift test` on a
+ * Mac — no device, no app, no simulator. `ios/Sources/PdfCanvasBridge/` is the
+ * React binding and the JSI slot store, and joins the build only through the
+ * podspec.
+ *
+ * ------------------------------------------------------------------------
+ * TWO ENGINES BEHIND ONE BACKEND, chosen per render by `annotations`.
+ * ------------------------------------------------------------------------
+ *
+ * `annotations: false` — every tile the controller asks for — draws through
+ * `CGContextDrawPDFPage`, which composites the page's content stream and NOT its
+ * annotation appearance streams. `annotations: true` — `renderPage`'s default,
+ * which is the thumbnail and print path — draws through PDFKit's
+ * `-[PDFPage drawWithBox:toContext:]`, which composites both.
+ *
+ * THAT MAKES iOS THE ONLY BACKEND THAT HONOURS `annotations: false`. Android
+ * cannot (`PdfRenderer.Page.render` has no annotation switch at any API level)
+ * and the PDFium web backend does not pass `FPDF_ANNOT` either. So an app that
+ * draws its own copy of a PDF-embedded annotation on the Skia layer sees it once
+ * on iOS and twice on Android — a real cross-platform difference, and the right
+ * way round.
+ */
+import { createNativeRasterizer } from './native-bridge.js';
+import { PdfError } from '../types.js';
+/**
+ * A CONSTANT AND NOT PART OF THE WIRE RESULT, unlike `format`, and — unusually
+ * for this package — a fact about an API rather than a measurement.
+ *
+ * There is no non-premultiplied 8-bit RGBA `CGBitmapContext`. Apple's supported
+ * pixel formats for a 32-bit-per-pixel, 8-bits-per-component RGB bitmap context
+ * are `kCGImageAlphaPremultipliedFirst`, `kCGImageAlphaPremultipliedLast`,
+ * `kCGImageAlphaNoneSkipFirst` and `kCGImageAlphaNoneSkipLast` — premultiplied,
+ * or no alpha at all. `kCGImageAlphaLast` (straight) is not in the table and
+ * `CGBitmapContextCreate` returns NULL for it. So the only two choices a backend
+ * has here are "premultiplied" and "throw away the alpha channel", and throwing
+ * it away would break `background: 'transparent'`.
+ *
+ * `ios/Sources/PdfCanvasCore/PdfCanvasRasterizer.mm` creates exactly one context
+ * configuration and this constant states it. The `alphaIsPremultiplied` case in
+ * the Swift suite reads the bytes back and checks the encoding on an antialiased
+ * edge over a transparent page — the one cell the spec's alpha table had marked
+ * NOT MEASURED — so this is asserted rather than believed.
+ *
+ * IT AGREES WITH ANDROID BY COINCIDENCE OF MECHANISM. Android's value comes from
+ * `Bitmap` being premultiplied by default; this one comes from CoreGraphics
+ * having no other option. PDFium and pdf.js both emit STRAIGHT alpha. Four
+ * backends, three independent reasons, no default that would be right — which is
+ * why `RasterPixels.alpha` is a required field.
+ */
+const IOS_ALPHA = 'premultiplied';
+const CAPABILITIES = {
+    /**
+     * True, and — alone among the four backends — true in BOTH directions.
+     *
+     * `annotations: true` draws them (PDFKit) and `annotations: false` does not
+     * (`CGContextDrawPDFPage`). Android records the flag and ignores it; the web
+     * PDFium backend does not pass `FPDF_ANNOT`. The field only claims "can render
+     * PDF-embedded annotations into the raster", so all three answer true — the
+     * asymmetry is documented at the top of this file rather than inventable from
+     * the capability.
+     */
+    annotations: true,
+    /**
+     * False, and honestly so. `CGContextDrawPDFPage` and
+     * `-[PDFPage drawWithBox:toContext:]` are both synchronous and uninterruptible
+     * once entered; an abort can only stop the NEXT piece starting, or discard a
+     * finished raster that is no longer wanted. This is the platform
+     * `RasterPolicy.minEpochIntervalMs` was written for — PDFKit is named in its
+     * doc comment.
+     */
+    interruptibleRender: false,
+    /**
+     * FALSE, AND THIS ONE IS A DECLARATION ABOUT THE PACKAGE, NOT THE PLATFORM.
+     * PDFKit really does have `-[PDFPage string]`, `-[PDFDocument findString:]` and
+     * link annotations, so iOS could answer true for all three the day a text
+     * surface exists. It does not exist — see the Non-goals — and a capability that
+     * says "yes" about an API no consumer can reach is worse than one that says
+     * "no". Every backend declares false today for the same reason.
+     */
+    text: false,
+    search: false,
+    links: false,
+    // Overwritten per rasterizer with the pool size it was actually opened with —
+    // see `createNativeRasterizer`.
+    maxConcurrentRenders: 1,
+};
+/**
+ * Mirrors `kPdfCanvasMaxPoolSize` in
+ * `ios/Sources/PdfCanvasCore/PdfCanvasDocumentPool.mm`, which is where the clamp
+ * is actually enforced. Restating it here is what makes the DECLARED capability
+ * match the pool the native side will really hand out.
+ */
+const MAX_POOL_SIZE = 4;
+const clampPoolSize = (size) => Math.max(1, Math.min(MAX_POOL_SIZE, Math.floor(size) || 1));
+function toNativeSource(source) {
+    const password = source.password;
+    if ('uri' in source) {
+        return password === undefined
+            ? { uri: source.uri }
+            : { uri: source.uri, password };
+    }
+    // REFUSED FOR THE SAME REASON AS ANDROID, and it is the bridge's reason rather
+    // than the platform's. iOS could take bytes with no spool at all —
+    // `CGPDFDocumentCreateWithProvider` over a `CFData` needs no file, and the
+    // native `open` does implement the `base64` field of the shared wire format for
+    // exactly that — but getting the bytes THERE means base64-encoding the whole
+    // document across the bridge, which is the one thing the spec's "two rules that
+    // are now measured" says never to do.
+    throw new PdfError('unsupported', 'Passing a document as bytes is not wired through the iOS binding. The ' +
+        'native side supports it (no spool file is needed — CoreGraphics reads a ' +
+        'CGDataProvider over the bytes directly), but sending them over the ' +
+        'bridge costs a base64 round trip of the whole document. Pass a `uri` ' +
+        'instead: a plain path, a `file://` URL, or a security-scoped URL the app ' +
+        'can still read.');
+}
+/**
+ * Wraps a native module in a `PageRasterizer`.
+ *
+ * The native module is INJECTED rather than imported so this file stays pure.
+ * `getDefaultRasterizer()` in `./index.native.ts` supplies the real one.
+ */
+export function createIosRasterizer(native, options = {}) {
+    return createNativeRasterizer(native, {
+        // NOT `ios-pdfkit`, though the README's plan said PDFKit and an earlier draft
+        // of this file used that id. Half the renders never touch PDFKit — every tile
+        // goes through `CGContextDrawPDFPage` — and an id is what a bug report
+        // quotes, so naming the framework that handles the minority of renders would
+        // misdirect every investigation of a tile.
+        id: options.id ?? 'ios-coregraphics',
+        capabilities: CAPABILITIES,
+        alpha: IOS_ALPHA,
+        poolSize: clampPoolSize(options.poolSize ?? 1),
+        label: 'iOS',
+        toNativeSource,
+        ...(options.lookupTakePixels === undefined
+            ? {}
+            : { lookupTakePixels: options.lookupTakePixels }),
+    });
+}

package/dist/rasterizer/native-bridge.d.ts

@@ -0,0 +1,261 @@
+/**
+ * The part of a platform backend that is not platform-specific.
+ *
+ * TWO NATIVE BACKENDS, ONE WIRE FORMAT. `android.ts` and `ios.ts` are both thin
+ * over this file: they choose an `id`, a `RasterizerCapabilities`, an
+ * `AlphaEncoding` and how a `PdfSource` becomes a native source, and everything
+ * else — error mapping, page-geometry marshalling, the transport negotiation, the
+ * base64 decode, the cancellation wiring, the phase timings — is here and is
+ * identical. That is not tidiness: the spec's whole claim for the iOS step is
+ * "the seam is a seam and not an Android-shaped hole", and the cheapest way to
+ * be held to it is for the second backend to be unable to drift.
+ *
+ * PURE ON PURPOSE, exactly as `android.ts` was before it was split. Nothing here
+ * imports `react-native`, which is what lets the whole adapter be tested in
+ * vitest against a fake native module. `./index.native.ts` is the only file that
+ * resolves a real one.
+ *
+ * WHY THE WIRE FORMAT IS SHARED RATHER THAN MERELY SIMILAR. The two native
+ * modules are written independently — `android/src/.../rn/PdfCanvasModule.java`
+ * and `ios/Sources/PdfCanvasBridge/PdfCanvasModule.mm` — so the one thing that
+ * can silently diverge is the shape of the maps they resolve with. Sharing this
+ * file makes a divergence a compile error on one side or a failing marshalling
+ * test on the other, instead of a wrong image on one platform.
+ *
+ * `globalThis` is the only ambient thing this file reads, and it is universal —
+ * the `__pdfCanvasTakePixels` lookup finds nothing under vitest and the adapter
+ * carries on.
+ */
+import { PdfError } from '../types.js';
+import type { AlphaEncoding, PageGeometry, PageRasterizer, PdfSource, PixelFormat, RasterizerCapabilities, RasterizerHandle, RasterTransport } from '../types.js';
+/**
+ * Whether this DEVICE draws a page carrying `/Rotate` upright.
+ *
+ * A THREE-STATE ANSWER BECAUSE ANDROID GENUINELY HAS THREE. API 24 reports the
+ * rotated DIMENSIONS but draws the content unrotated and clipped, while 31 and
+ * 33 are correct, and the verdict is measured on device rather than derived from
+ * `Build.VERSION` — see `PdfPlatformQuirks`. iOS answers `'supported'`
+ * unconditionally: CoreGraphics applies the transform this backend hands it, and
+ * `ios/Sources/PdfCanvasCore/PdfCanvasPageTransform.mm` is where `/Rotate`
+ * becomes part of that transform, so there is no device variable to probe.
+ *
+ * It stays on the shared wire format rather than being an Android extension
+ * precisely so a host does not have to know which platform it is on to ask.
+ */
+export type NativeRotationSupport = 'supported' | 'unsupported' | 'unknown';
+export interface NativePdfPage {
+    index: number;
+    width: number;
+    height: number;
+    /**
+     * The page's `/Rotate`, in degrees, or 0.
+     *
+     * THE TWO BACKENDS REPORT THIS DIFFERENTLY AND BOTH ARE RIGHT, which is worth
+     * knowing before treating a difference as a bug. `PageGeometry.rotation` is
+     * informational — `width` and `height` are already post-rotation on every
+     * backend, and no consumer applies a further rotation — so:
+     *
+     *  - iOS reports the real `/Rotate` (`CGPDFPageGetRotationAngle`), matching
+     *    the web PDFium backend.
+     *  - Android reports 0, because `PdfRenderer` exposes no way to read `/Rotate`
+     *    below API 35. That is an inability, not a policy.
+     */
+    rotation: number;
+}
+export interface NativeOpenResult {
+    handle: number;
+    pageCount: number;
+    pages: NativePdfPage[];
+    rotationSupport: NativeRotationSupport;
+}
+export interface NativeRenderResult {
+    /**
+     * Raw pixels, base64. Present on the FALLBACK transport only.
+     *
+     * Exactly one of `base64` and `pixelsSlot` is set; neither native side ever
+     * sends both, because building the string is the single largest cost the fast
+     * path exists to delete.
+     */
+    base64?: string;
+    /**
+     * The JSI slot holding this raster's bytes, on the fast transport.
+     *
+     * A number rather than the bytes themselves because a bridge result map has no
+     * binary type — that is the whole problem, and it is the same problem on both
+     * platforms (measured: RN's `convertObjCObjectToJSIValue` handles NSString,
+     * NSNumber, NSDictionary, NSArray and nothing else, so `NSData` converts to
+     * `undefined`). The number is a receipt: JS redeems it once, synchronously,
+     * through `__pdfCanvasTakePixels`, which hands back an ArrayBuffer wrapping the
+     * native memory and forgets the slot.
+     */
+    pixelsSlot?: number;
+    width: number;
+    height: number;
+    rowBytes: number;
+    format: PixelFormat;
+}
+export interface NativeRenderRequest {
+    page: number;
+    x: number;
+    y: number;
+    width: number;
+    height: number;
+    scale: number;
+    annotations: boolean;
+    background: 'white' | 'transparent';
+}
+export interface NativeSource {
+    uri?: string;
+    base64?: string;
+    password?: string;
+}
+export interface PdfCanvasNativeModule {
+    open(source: NativeSource, poolSize: number): Promise<NativeOpenResult>;
+    render(handle: number, request: NativeRenderRequest, token: number): Promise<NativeRenderResult>;
+    /** Best-effort. Cannot interrupt a render already inside the platform engine. */
+    cancel(handle: number, token: number): void;
+    close(handle: number): void;
+    /**
+     * Installs the JSI host function and parks a probe raster. Returns its slot,
+     * or a negative number if the fast transport is unavailable.
+     *
+     * OPTIONAL, and its absence is the normal case for an older app binary whose
+     * native module predates the transport. `negotiateTransport` treats a missing
+     * method exactly as it treats a refusal.
+     */
+    installJsiTransport?(): number;
+    /** Arms or disarms the fast transport. Returns what is now live. */
+    enableJsiTransport?(enabled: boolean): boolean;
+}
+/**
+ * `globalThis.__pdfCanvasTakePixels`, installed from C++.
+ *
+ * Redeems a slot for the ArrayBuffer holding that raster, exactly once. Throws
+ * if the slot is empty — which is a lost raster, never an empty one, because a
+ * zero-length buffer would reach Skia and draw a black tile.
+ *
+ * ONE NAME FOR BOTH PLATFORMS, deliberately. The two installers are different
+ * files in different languages, but a runtime only ever has one of them, and a
+ * shared name is what lets `lookupTakePixels` be platform-blind.
+ */
+export type TakePixels = (slot: number) => ArrayBuffer;
+/**
+ * React Native's `promise.reject(code, message)` surfaces `code` as a string
+ * property on the rejection, which is why `PdfErrorCode`'s members are the wire
+ * format on the native side too (`PdfErrorCode.wire()` in Java,
+ * `PdfCanvasErrorCodeWire()` in Objective-C). No translation table exists in
+ * between, deliberately: a table is a place for the lists to silently drift
+ * apart.
+ */
+export declare function toPdfError(error: unknown, fallback: string): PdfError;
+/**
+ * Hand-rolled rather than `atob` or `Buffer`.
+ *
+ * `Buffer` is a node global that RN does not ship, and `atob` — added to Hermes
+ * relatively recently — decodes to a STRING, so recovering bytes means a second
+ * pass building a Uint8Array from char codes, doubling the peak footprint of a
+ * buffer that is already megabytes. This writes straight into the output array,
+ * and being pure means the padded-stride and odd-length cases are covered in
+ * vitest instead of on a device.
+ */
+export declare function decodeBase64(input: string): Uint8Array;
+/**
+ * Mirrors `PdfCanvasPixelBridge.PROBE_BYTES` on the Java side and
+ * `kPdfCanvasProbeBytes` in `ios/Sources/PdfCanvasBridge/PdfCanvasSlots.mm`.
+ *
+ * The three lists are restated rather than derived, which is the point: they are
+ * the only places the transport's byte fidelity is asserted, and if one is edited
+ * without the others the probe fails and that platform degrades to base64 rather
+ * than shipping a shear.
+ *
+ * The contents are chosen, not arbitrary. 0x00 and 0xFF pin both ends of the
+ * range; 0xFD/0xFE/0xFF are above 0x7F, where Java's SIGNED byte and a
+ * JS `Uint8Array` disagree unless every step of the copy is right. (On iOS the
+ * sign-extension hazard does not exist — the whole path is `uint8_t` — but the
+ * probe's other job does: it proves the runtime will build an ArrayBuffer over
+ * external memory at all, which is a claim about a JS engine version and not
+ * about a language.)
+ */
+export declare const TRANSPORT_PROBE_BYTES: readonly number[];
+/**
+ * Reads the installed host function off the global.
+ *
+ * Through `globalThis`, which is universal — unlike `react-native`, whose import
+ * is what this whole file is written to avoid. So the pure core still loads
+ * under vitest and in a browser: the lookup simply finds nothing.
+ */
+export declare const lookupTakePixels: () => TakePixels | null;
+/**
+ * The resolved transport, and the function that redeems a slot on it.
+ *
+ * `take` is non-null if and only if `kind` is `jsi-arraybuffer`, which is what
+ * lets the render path branch once on a value it can trust.
+ */
+export interface NativeTransport {
+    readonly kind: RasterTransport;
+    readonly take: TakePixels | null;
+}
+/**
+ * Decides ONCE, at construction, which transport this rasterizer uses — and
+ * proves the fast one before choosing it.
+ *
+ * THE PROBE IS THE POINT. Every step below can fail on a real device for a
+ * reason no type system sees: the app binary may predate the native transport
+ * (no `installJsiTransport`), the build may lack the native library for this ABI
+ * or slice (install returns -1), the runtime may refuse a host function, or the
+ * JS engine may not support an ArrayBuffer backed by external memory at all —
+ * Hermes does, but "does" is a claim about a version. So instead of inferring
+ * availability from any of those, the negotiation moves eight known bytes across
+ * the real transport and compares them. Only a byte-for-byte match arms it.
+ *
+ * Every failure returns `base64`, and none of them throws. A build that cannot
+ * do this fast renders exactly as it did before.
+ */
+export declare function negotiateTransport(native: PdfCanvasNativeModule, lookup?: () => TakePixels | null): NativeTransport;
+export declare function toPageGeometry(page: NativePdfPage): PageGeometry;
+/**
+ * Turns one native render result into bytes, on whichever transport produced it.
+ *
+ * Branches on the RESULT rather than on the negotiated transport, because the
+ * two can disagree for exactly one render: a native side clears its own flag
+ * when a slot store fails and falls that tile back to base64 mid-flight. What
+ * arrived is the only thing that can be believed.
+ */
+export declare function bytesFromResult(result: NativeRenderResult, transport: NativeTransport): {
+    bytes: Uint8Array;
+    payloadChars: number;
+    used: RasterTransport;
+};
+/**
+ * Surfaced so a host can decide what to do about a device that does not draw
+ * rotated pages upright — warn, fall back, or accept it.
+ */
+export interface NativeRasterizerHandle extends RasterizerHandle {
+    readonly rotationSupport: NativeRotationSupport;
+}
+export declare function createNativeHandle(native: PdfCanvasNativeModule, opened: NativeOpenResult, transport: NativeTransport, alpha: AlphaEncoding, label: string): NativeRasterizerHandle;
+export interface NativeRasterizerSpec {
+    /** Surfaced as `PageRasterizer.id`, so a bug report names a backend. */
+    id: string;
+    /**
+     * Everything except `maxConcurrentRenders` and `transport`, both of which are
+     * resolved here — the first from the pool size actually asked for, the second
+     * from the negotiation.
+     */
+    capabilities: RasterizerCapabilities;
+    /** What this platform's bitmaps encode. Never defaulted — see `AlphaEncoding`. */
+    alpha: AlphaEncoding;
+    /** Clamped concurrent renders, already resolved by the caller. */
+    poolSize: number;
+    /** Named in the "handle is closed" message. */
+    label: string;
+    toNativeSource: (source: PdfSource) => NativeSource;
+    lookupTakePixels?: () => TakePixels | null;
+}
+/**
+ * Wraps a native module in a `PageRasterizer`.
+ *
+ * The native module is INJECTED rather than imported so this file stays pure.
+ * `getDefaultRasterizer()` in `./index.native.ts` supplies the real one.
+ */
+export declare function createNativeRasterizer(native: PdfCanvasNativeModule, spec: NativeRasterizerSpec): PageRasterizer;