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

package/android/src/main/java/tools/reekon/pdfcanvas/PdfRendererPool.java

@@ -1,234 +0,0 @@
-package tools.reekon.pdfcanvas;
-
-import android.graphics.pdf.PdfRenderer;
-import android.os.ParcelFileDescriptor;
-
-import java.io.File;
-import java.io.IOException;
-import java.util.ArrayList;
-import java.util.List;
-import java.util.concurrent.ArrayBlockingQueue;
-import java.util.concurrent.BlockingQueue;
-
-/**
- * A fixed set of {@link PdfRenderer} instances over the same file, leased one at
- * a time.
- *
- * WHY A POOL EXISTS AT ALL. {@code PdfRenderer} permits exactly ONE open page
- * per instance: {@code openPage} throws {@code IllegalStateException}
- * ("Current page not closed") if another is already open. That is a per-instance
- * rule, not a per-process one, so the thing that does not work is TWO THREADS ON
- * ONE RENDERER — not two renderers. Renderer-per-concurrent-render is the only
- * way to have more than one raster in flight, and it is what this class hands
- * out. Nothing in here makes a single renderer thread-safe, and nothing should
- * try: the lease is the mutual exclusion.
- *
- * WHY NOT {@code ParcelFileDescriptor.dup()}. It is the obvious way to give each
- * renderer its own fd, and it is wrong here. {@code dup()} is {@code dup(2)},
- * which produces a new descriptor onto the SAME open file description — and the
- * file offset lives in the description, so two dup'd fds share one seek
- * position. AOSP's PdfRenderer reads through an {@code FPDF_FILEACCESS} callback
- * that seeks then reads, so two renderers reading concurrently through dup'd fds
- * are racing on that offset. Today AOSP happens to serialise every PdfRenderer
- * native call behind a process-wide PDFium lock, which hides it; that is a
- * property of one implementation, not of the API. Opening the file afresh per
- * renderer costs one extra {@code open(2)} and gives each renderer an
- * independent file description, which is the invariant the code actually needs.
- */
-final class PdfRendererPool {
-
-  /**
-   * Ceiling on renderers. Each one holds an fd and PDFium's parsed document
-   * structure for the same file, so the memory cost is per-instance and real on
-   * a large sheet. Two in flight is already enough to keep a detail raster from
-   * queueing behind a base raster, which is the only concurrency the cadence
-   * ever asks for.
-   */
-  static final int MAX_POOL_SIZE = 4;
-
-  private final File file;
-  private final List<PdfRenderer> all;
-  private final BlockingQueue<PdfRenderer> free;
-  private final int pageCount;
-  private volatile boolean closed;
-
-  private PdfRendererPool(File file, List<PdfRenderer> renderers, int pageCount) {
-    this.file = file;
-    this.all = renderers;
-    this.free = new ArrayBlockingQueue<>(renderers.size());
-    this.free.addAll(renderers);
-    this.pageCount = pageCount;
-  }
-
-  static PdfRendererPool open(File file, String password, int requestedSize)
-      throws PdfRasterException {
-    // ORDER IS LOAD-BEARING. Preflight runs before anything can construct a
-    // PdfRenderer, because on API 24 a throwing constructor poisons PDFium for
-    // the whole process — see PdfPreflight for the measurement. The latch then
-    // covers files preflight cannot judge.
-    PdfPlatformQuirks.requireUsablePdfium();
-    PdfPreflight.check(file);
-    if (password != null) {
-      // compileSdk 34 has no `android.graphics.pdf.LoadParams`, which is where
-      // a password became expressible (API 35). Below that the platform class
-      // offers no way to supply one at all, so accepting the argument and
-      // silently ignoring it would turn "wrong password" into "corrupt file".
-      throw new PdfRasterException(
-          PdfErrorCode.UNSUPPORTED,
-          "A password was supplied, but android.graphics.pdf.PdfRenderer cannot "
-              + "accept one below API 35 (LoadParams). Use a PDFium backend for "
-              + "encrypted documents.");
-    }
-
-    int size = Math.max(1, Math.min(MAX_POOL_SIZE, requestedSize));
-    List<PdfRenderer> renderers = new ArrayList<>(size);
-    int pages = 0;
-    try {
-      for (int i = 0; i < size; i++) {
-        renderers.add(openRenderer(file));
-      }
-      pages = renderers.get(0).getPageCount();
-    } catch (PdfRasterException | RuntimeException e) {
-      closeAll(renderers);
-      throw e;
-    }
-
-    if (pages <= 0) {
-      closeAll(renderers);
-      throw new PdfRasterException(
-          PdfErrorCode.CORRUPT, "Document reports " + pages + " pages.");
-    }
-    return new PdfRendererPool(file, renderers, pages);
-  }
-
-  private static PdfRenderer openRenderer(File file) throws PdfRasterException {
-    ParcelFileDescriptor pfd = null;
-    try {
-      pfd = ParcelFileDescriptor.open(file, ParcelFileDescriptor.MODE_READ_ONLY);
-      // PdfRenderer takes ownership of the descriptor and closes it in close().
-      return new PdfRenderer(pfd);
-    } catch (SecurityException e) {
-      // Reaching here means preflight missed an encryption scheme it does not
-      // recognise. The damage on an affected build is already done — the
-      // half-built PdfRenderer is unreachable and finalizable — so all that is
-      // left is to stop the next open walking into the segfault.
-      PdfPlatformQuirks.recordFailedNativeOpen();
-      closeQuietly(pfd);
-      // The platform's documented signal for "this file requires a password or
-      // uses a security scheme we do not support". No password could have been
-      // supplied (open() rejects that above), so this is always "required".
-      throw new PdfRasterException(
-          PdfErrorCode.PASSWORD_REQUIRED,
-          "The document is encrypted: " + file.getName() + ".",
-          e);
-    } catch (IOException e) {
-      PdfPlatformQuirks.recordFailedNativeOpen();
-      closeQuietly(pfd);
-      throw new PdfRasterException(
-          PdfErrorCode.CORRUPT,
-          "Not a readable PDF: " + file.getName() + " (" + e.getMessage() + ").",
-          e);
-    } catch (RuntimeException e) {
-      // IllegalArgumentException ("file descriptor not seekable") and anything
-      // else the constructor can throw land here. Same reasoning as above: the
-      // constructor threw, so the process is on borrowed time.
-      PdfPlatformQuirks.recordFailedNativeOpen();
-      closeQuietly(pfd);
-      throw new PdfRasterException(
-          PdfErrorCode.BACKEND_FAILURE,
-          "PdfRenderer refused " + file.getName() + ": " + e.getMessage(),
-          e);
-    }
-  }
-
-  int pageCount() {
-    return pageCount;
-  }
-
-  File file() {
-    return file;
-  }
-
-  int size() {
-    return all.size();
-  }
-
-  /**
-   * Blocks until a renderer is free. The wait is where a cancel most often lands
-   * — a superseded detail raster typically queues behind a base raster — so the
-   * caller re-checks its signal on the far side of this call.
-   */
-  PdfRenderer lease() throws PdfRasterException {
-    if (closed) {
-      throw new PdfRasterException(
-          PdfErrorCode.BACKEND_FAILURE, "Document handle is closed.");
-    }
-    try {
-      PdfRenderer renderer = free.take();
-      if (closed) {
-        // close() raced us. Do not hand out a renderer that close() has already
-        // closed, and do not put it back either — closeAll owns it now.
-        throw new PdfRasterException(
-            PdfErrorCode.BACKEND_FAILURE, "Document handle was closed while waiting.");
-      }
-      return renderer;
-    } catch (InterruptedException e) {
-      Thread.currentThread().interrupt();
-      throw new PdfRasterException(
-          PdfErrorCode.CANCELLED, "Interrupted waiting for a PdfRenderer.", e);
-    }
-  }
-
-  /** Always call from a finally: a leaked lease deadlocks every later render. */
-  void release(PdfRenderer renderer) {
-    if (renderer != null) {
-      free.offer(renderer);
-    }
-  }
-
-  /**
-   * Closes every renderer, including ones currently leased.
-   *
-   * The leased case is deliberate and it is the only honest option: close() is
-   * called from JS when a document unmounts, and blocking the caller until an
-   * in-flight ARCH-D render finishes is worse than the alternative. The renderer
-   * whose {@code render()} is mid-flight is not closed out from under it —
-   * {@code closed} is set first, {@code PdfCanvasRasterizer} re-checks it, and
-   * the renderers are closed after. The remaining window is the same one every
-   * native handle has.
-   */
-  void close() {
-    if (closed) {
-      return;
-    }
-    closed = true;
-    free.clear();
-    closeAll(all);
-  }
-
-  boolean isClosed() {
-    return closed;
-  }
-
-  private static void closeAll(List<PdfRenderer> renderers) {
-    for (PdfRenderer renderer : renderers) {
-      try {
-        renderer.close();
-      } catch (RuntimeException ignored) {
-        // close() throws IllegalStateException if a page is still open. There is
-        // nothing useful to do about it during teardown, and letting it escape
-        // would skip closing the remaining renderers and leak their fds.
-      }
-    }
-  }
-
-  private static void closeQuietly(ParcelFileDescriptor pfd) {
-    if (pfd != null) {
-      try {
-        pfd.close();
-      } catch (IOException ignored) {
-        // Nothing to salvage; the throwing path already has the real cause.
-      }
-    }
-  }
-}

package/android/src/main/java/tools/reekon/pdfcanvas/RasterCancellation.java

@@ -1,47 +0,0 @@
-package tools.reekon.pdfcanvas;
-
-import java.util.concurrent.atomic.AtomicBoolean;
-
-/**
- * Best-effort cancellation, and the emphasis is on BEST-EFFORT.
- *
- * {@code PdfRenderer.Page.render} is synchronous and uninterruptible once
- * entered. There is no cancel token, no progress callback, and no safe way to
- * kill the thread — PDFium is mid-way through writing into a Bitmap this process
- * owns. So this class cannot stop a render; it can only stop the NEXT one
- * starting, which is the same shape the TS contract already assumes for PDFKit
- * ({@code RasterPolicy.minEpochIntervalMs} exists because of it).
- *
- * Concretely, a cancel is observed at four points and no others:
- * on entry, after the pool lease (the wait can be long when every renderer is
- * busy), immediately before {@code render()}, and immediately after it. The last
- * one does not save any work — the pixels are already drawn — it only stops a
- * superseded raster being handed back and ingested into Skia. The
- * {@code cancelDuringAnInFlightRenderIsObservedOnlyAfterItFinishes} test asserts
- * that shape rather than pretending otherwise. (It was named here as
- * {@code cancellationCannotInterruptAnInFlightRender}, which does not exist.)
- */
-public final class RasterCancellation {
-
-  private final AtomicBoolean cancelled = new AtomicBoolean(false);
-
-  public void cancel() {
-    cancelled.set(true);
-  }
-
-  public boolean isCancelled() {
-    return cancelled.get();
-  }
-
-  /**
-   * @param stage named in the message so a cancellation reported from the
-   *     post-render check is distinguishable from one that saved real work.
-   */
-  static void throwIfCancelled(RasterCancellation signal, String stage)
-      throws PdfRasterException {
-    if (signal != null && signal.isCancelled()) {
-      throw new PdfRasterException(
-          PdfErrorCode.CANCELLED, "Render cancelled (" + stage + ").");
-    }
-  }
-}

package/android/src/main/java/tools/reekon/pdfcanvas/RasterPixels.java

@@ -1,143 +0,0 @@
-package tools.reekon.pdfcanvas;
-
-import tools.reekon.pdfcanvas.jsi.PdfCanvasPixelBridge;
-
-/**
- * A finished raster, mirroring {@code RasterPixels} in {@code src/types.ts}.
- *
- * {@link #rowBytes} is STATED, never assumed to be {@code width * 4}. It is read
- * back from {@code Bitmap.getRowBytes()}, because a wrong stride does not fail —
- * it shears the image, one pixel further per row, which reads as a plausible
- * skew rather than an error.
- *
- * HOW FAR THAT IS PROVEN, precisely. {@code rowBytesIsReportedNotAssumed} checks
- * the value against the stride the platform itself chose for an identically
- * sized {@code ARGB_8888} bitmap, at seven widths including odd and prime ones.
- * What it CANNOT show is the difference between reading the stride and assuming
- * {@code width * 4}: {@code Bitmap.createBitmap} allocates through
- * {@code SkImageInfo::minRowBytes()}, which is exactly {@code width * 4} with no
- * alignment, so on API 24, 31 and 33 every measured stride is tight and the two
- * implementations produce identical output. The padded case is exercised on the
- * JS side instead, where the fake backend pads on demand. Reading the value is
- * therefore the correct thing to do and is what happens here — but treat "we
- * read it" as a design decision that the device suite agrees with, not as
- * something the device suite could have falsified.
- *
- * <h3>Where the pixels actually are</h3>
- *
- * ONE OF TWO PLACES, and {@link #bytes} being null is how you tell:
- *
- * <ul>
- *   <li>ON THE JAVA HEAP — {@code bytes} is the raster and {@link #slot} is
- *       {@link #NO_SLOT}. Every caller that reads pixels wants this, and it is
- *       what {@link PdfCanvasRasterizer#render} returns.
- *   <li>IN A NATIVE SLOT — {@code bytes} is null and {@code slot} names a buffer
- *       in {@code pdfcanvas-jsi.cpp} waiting to become a JS {@code ArrayBuffer}.
- *       Only {@link PdfCanvasRasterizer#renderToNativeSlot} produces this, only
- *       the React binding asks for it, and NOTHING can read the pixels back from
- *       Java — the whole point is that they never touch the Java heap.
- * </ul>
- *
- * That is a deliberately awkward shape rather than two classes, because the one
- * caller that asks for a slot has to handle both anyway: the native store is
- * allowed to refuse (see
- * {@link PdfCanvasPixelBridge#nativeStoreFromBitmap}) and the heap is the
- * fallback, so a slot request can legitimately come back heap-backed.
- * {@link #channel} and {@link #offsetOf} therefore fail LOUDLY and by name on a
- * slot-backed raster instead of throwing a bare NPE from somewhere further in.
- *
- * <h3>Who frees the slot</h3>
- *
- * Normally nobody here: the buffer is taken exactly once by
- * {@code __pdfCanvasTakePixels} and freed when the JS {@code ArrayBuffer} is
- * collected. {@link #release()} exists for the paths where the raster is
- * ABANDONED after it was filled — a cancellation observed after the draw, or a
- * throw between the render finishing and the promise resolving. Without it those
- * megabytes would sit in the slot map until the next
- * {@code nativeReleaseAll()}, which only happens on a reload.
- */
-public final class RasterPixels {
-
-  /**
-   * The only format this backend emits.
-   *
-   * {@code Bitmap.Config.ARGB_8888} is named for the packed 32-bit int that
-   * {@code getPixel} returns, but the IN-MEMORY byte order is R, G, B, A —
-   * which is what {@code copyPixelsToBuffer} produces and what Skia calls
-   * {@code kRGBA_8888}. The name and the layout disagree, which is precisely the
-   * kind of thing that gets assumed instead of checked, so it is measured.
-   */
-  public static final String FORMAT_RGBA_8888 = "rgba8888";
-
-  /** {@link #slot} when the pixels are on the Java heap. Never a real slot id. */
-  public static final long NO_SLOT = 0L;
-
-  /** The raster, or null when it is in a native slot. See the class note. */
-  public final byte[] bytes;
-  public final int width;
-  public final int height;
-  public final int rowBytes;
-  public final String format;
-  /** {@link #NO_SLOT}, or the native slot holding the raster. */
-  public final long slot;
-
-  RasterPixels(byte[] bytes, int width, int height, int rowBytes, String format) {
-    this(bytes, width, height, rowBytes, format, NO_SLOT);
-  }
-
-  private RasterPixels(
-      byte[] bytes, int width, int height, int rowBytes, String format, long slot) {
-    this.bytes = bytes;
-    this.width = width;
-    this.height = height;
-    this.rowBytes = rowBytes;
-    this.format = format;
-    this.slot = slot;
-  }
-
-  static RasterPixels inNativeSlot(
-      long slot, int width, int height, int rowBytes, String format) {
-    return new RasterPixels(null, width, height, rowBytes, format, slot);
-  }
-
-  /** Whether the pixels are in native memory and unreadable from Java. */
-  public boolean isInNativeSlot() {
-    return slot != NO_SLOT;
-  }
-
-  /**
-   * Frees the native slot if this raster is in one. Idempotent, and a no-op for
-   * a heap-backed raster.
-   *
-   * Call this on any path that DROPS the raster after it was produced. A taken
-   * slot is already gone from the map, so releasing after a successful take is
-   * harmless — {@code nativeRelease} is a lookup that finds nothing.
-   */
-  public void release() {
-    if (isInNativeSlot() && PdfCanvasPixelBridge.isLoaded()) {
-      PdfCanvasPixelBridge.nativeRelease(slot);
-    }
-  }
-
-  /** Byte offset of pixel (x, y), honouring the real stride. */
-  public int offsetOf(int x, int y) {
-    requireHeapBacked();
-    return y * rowBytes + x * 4;
-  }
-
-  /** One channel of one pixel, as an unsigned 0..255 value. */
-  public int channel(int x, int y, int channel) {
-    requireHeapBacked();
-    return bytes[offsetOf(x, y) + channel] & 0xff;
-  }
-
-  private void requireHeapBacked() {
-    if (bytes == null) {
-      throw new IllegalStateException(
-          "This raster's pixels are in native slot " + slot + ", not on the Java "
-              + "heap, so they cannot be read from Java. Ask "
-              + "PdfCanvasRasterizer.render() for a heap-backed raster instead of "
-              + "renderToNativeSlot().");
-    }
-  }
-}

package/android/src/main/java/tools/reekon/pdfcanvas/RasterRequest.java

@@ -1,95 +0,0 @@
-package tools.reekon.pdfcanvas;
-
-/**
- * One raster to produce, mirroring {@code RasterRequest} in {@code src/types.ts}.
- *
- * The doc rect is in PAGE-LOCAL points — y-down, origin at the page's top-left,
- * already post-rotation (see {@link PageGeometry}). It is NOT in whatever
- * document-wide space the JS layout function laid the pages out in; the TS
- * adapter subtracts the page origin before it gets here. A backend that had to
- * know the page layout would be a backend the layout function could break.
- */
-public final class RasterRequest {
-
-  /** Fill the bitmap opaque white before drawing. */
-  public static final int BACKGROUND_WHITE = 0;
-  /**
-   * Leave the bitmap cleared to transparent before drawing.
-   *
-   * This means the CALLER accepts undrawn area coming back transparent. It is
-   * emphatically NOT a claim that {@code PdfRenderer.render} clears anything —
-   * spike S1 measured that it does not (finding 3): untouched pixels keep
-   * whatever the caller left in the bitmap. The {@code eraseColor} call happens
-   * on both paths; only the colour differs.
-   */
-  public static final int BACKGROUND_TRANSPARENT = 1;
-
-  public final int page;
-  public final float docX;
-  public final float docY;
-  public final float docWidth;
-  public final float docHeight;
-  /** Device pixels per PDF point. */
-  public final float scale;
-  /**
-   * Whether PDF-embedded annotations should be drawn.
-   *
-   * RECORDED, NOT HONOURED — and it cannot be. {@code PdfRenderer.Page.render}
-   * takes a render MODE ({@code FOR_DISPLAY} / {@code FOR_PRINT}) and no
-   * annotation switch; PDFium's {@code FPDF_ANNOT} flag is not reachable through
-   * the platform class at any API level. Annotations are always composited.
-   * {@code FOR_PRINT} is not a suppression flag either — it selects an
-   * annotation's /Print appearance stream, which is still an appearance.
-   *
-   * The consequence for the package is real and belongs in the open: an app that
-   * draws its OWN copy of a PDF-embedded annotation on the Skia layer will see it
-   * twice on Android. The fix is a PDFium backend, not a different mode here.
-   */
-  public final boolean annotations;
-  public final int background;
-
-  public RasterRequest(
-      int page,
-      float docX,
-      float docY,
-      float docWidth,
-      float docHeight,
-      float scale,
-      boolean annotations,
-      int background) {
-    this.page = page;
-    this.docX = docX;
-    this.docY = docY;
-    this.docWidth = docWidth;
-    this.docHeight = docHeight;
-    this.scale = scale;
-    this.annotations = annotations;
-    this.background = background;
-  }
-
-  /**
-   * Destination width in device pixels.
-   *
-   * ROUND, not ceil, and at least 1 — the same rule the deterministic fake
-   * backend documents. The half-pixel this can shave off the far edge is
-   * absorbed by the fact that a raster is drawn to fill its doc rect; going the
-   * other way (ceil) would make two rasters requested at the same scale
-   * disagree on size for rects of equal width, which the cache keys off.
-   */
-  public int pixelWidth() {
-    return Math.max(1, Math.round(docWidth * scale));
-  }
-
-  /** Destination height in device pixels. See {@link #pixelWidth()}. */
-  public int pixelHeight() {
-    return Math.max(1, Math.round(docHeight * scale));
-  }
-
-  @Override
-  public String toString() {
-    return "RasterRequest{p=" + page + " rect=" + docX + "," + docY + " "
-        + docWidth + "x" + docHeight + " @" + scale + " -> "
-        + pixelWidth() + "x" + pixelHeight()
-        + " bg=" + (background == BACKGROUND_WHITE ? "white" : "transparent") + "}";
-  }
-}

package/dist/rasterizer/android.d.ts

@@ -1,121 +0,0 @@
-/**
- * The TypeScript half of the Android backend.
- *
- * THIN, AND IT USED TO BE THE WHOLE THING. Everything that is not
- * Android-specific — error mapping, page-geometry marshalling, the transport
- * negotiation, the base64 decode, the cancellation wiring, the phase timings —
- * moved to `./native-bridge.ts` when the iOS backend landed, because the two
- * platforms speak the identical wire format and the spec's claim for the iOS step
- * is that the seam is a seam. What is left here is the four things that are
- * genuinely Android's: the id, the capabilities, the alpha encoding, and what
- * `PdfSource` it can accept.
- *
- * The names exported from `./native-bridge.ts` are re-exported below under their
- * original `Android*` spellings, so nothing that imported them from here breaks.
- *
- * PURE ON PURPOSE. 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 the real one, and it does
- * nothing except hand it to `createAndroidRasterizer`.
- *
- * The native side is `android/src/main/java/tools/reekon/pdfcanvas/`, a
- * React-free Android library that is proven on device by
- * `./gradlew connectedDebugAndroidTest`. That split is the reason a bug here is
- * a bug in marshalling and never a bug in rasterizing.
- */
-import type { NativeRasterizerHandle, NativeRotationSupport, NativeOpenResult, NativePdfPage, NativeRenderRequest, NativeRenderResult, NativeSource, NativeTransport, PdfCanvasNativeModule } from './native-bridge.js';
-import type { PageRasterizer } from '../types.js';
-export { TRANSPORT_PROBE_BYTES, bytesFromResult, decodeBase64, lookupTakePixels, negotiateTransport, toPageGeometry, } from './native-bridge.js';
-export type { NativeRasterizerHandle, NativeRotationSupport, NativeOpenResult, NativePdfPage, NativeRenderRequest, NativeRenderResult, NativeSource, NativeTransport, PdfCanvasNativeModule, TakePixels, } from './native-bridge.js';
-/**
- * ALIASES, NOT COPIES. These were the shipped names before the wire format was
- * shared with iOS, and a consumer that imported one should not have to care that
- * a second backend now speaks it too.
- */
-export type AndroidRotationSupport = NativeRotationSupport;
-export type AndroidNativePage = NativePdfPage;
-export type AndroidNativeOpenResult = NativeOpenResult;
-export type AndroidNativeRenderResult = NativeRenderResult;
-export type AndroidNativeRenderRequest = NativeRenderRequest;
-export type AndroidNativeSource = NativeSource;
-export type AndroidPdfNativeModule = PdfCanvasNativeModule;
-export type AndroidTransport = NativeTransport;
-export type AndroidRasterizerHandle = NativeRasterizerHandle;
-export interface AndroidRasterizerOptions {
-    /**
-     * Concurrent renders. Clamped to [1, 4] natively — each slot is one more
-     * `PdfRenderer` holding a file descriptor and a parsed document.
-     *
-     * ONE. It is also what the rasterizer reports as
-     * `RasterizerCapabilities.maxConcurrentRenders`, so raising it does two things
-     * at once: it opens more native renderers AND it widens the controller's lane
-     * bound. Both of those are measured below and both come out negative.
-     *
-     * THE POOL DOES NOT PARALLELISE PDFium. AOSP serialises `PdfRenderer` behind a
-     * process-wide PDFium lock, and the lock does not merely serialise, it CONVOYS.
-     * On an LG V60 (Snapdragon 865, 8 cores, API 33) at the field report's scale of
-     * 131.25 device px/pt with 1024 px tiles, over a real field-measure drawing,
-     * four threads inflate the per-tile PDFium phases `openPage` 16.2x,
-     * `PdfRenderer.render` 10.9x and `recycle+close` 33.6x, for a whole-tile
-     * inflation of 5.84x, against 1.1x-5.3x for every non-PDFium phase. On a dense
-     * electrical schematic it is worse still: `render` 30.9x, `openPage` 11.2x.
-     * A pure-Java control on the same threads scales 2.8x. So the native calls do
-     * not overlap, and contending for them makes each one dramatically slower.
-     *
-     * NOTHING ABOUT THIS CARRIES OVER TO iOS, and the iOS option says so on its own
-     * doc comment: the lock being measured here is AOSP's, in
-     * `android_graphics_pdf_PdfRenderer.cpp`, and CoreGraphics has no counterpart
-     * to it that anyone has measured.
-     *
-     * WHY THIS WAS 2, AND WHY THAT REASON IS GONE. The second slot never existed to
-     * rasterize in parallel; it existed to PIPELINE, hiding the JS thread's
-     * `decodeBase64` (~1005 ms per tile, 90.6% of the tile) behind the next tile's
-     * native work. The JSI transport deleted that cost outright — the JS thread's
-     * whole share is now a pointer wrap — so there is nothing left to hide. Worse,
-     * deleting the base64 ENCODE from the Java side deleted the only phase that was
-     * genuinely parallel: on the real drawing a tile was 72.7% parallelisable work
-     * (19.3 ms of encode inside 30.6 ms) and is now 35.6% (4.6 ms of bitmap fill,
-     * pixel copy and JNI store inside 13.0 ms), with the PDFium-serialised part
-     * risen from 25.5% to 60.2%. Amdahl caps that at 1.67x before the convoy is
-     * counted, and the convoy is what turns the remaining headroom negative.
-     *
-     * MEASURED, on the JSI transport, by `laneScheduleOnTheJsiTransport` in
-     * `PdfCanvasPhaseTimingTest` — N lanes over one shared cursor of 6 plan items,
-     * which is the schedule the controller actually runs, 21 interleaved rounds per
-     * lane count. Mean epoch wall clock relative to one lane, higher is better:
-     *
-     *   - real field-measure drawing, 4 independent passes:
-     *     2 lanes 0.82x / 0.81x / 0.95x / 0.76x,
-     *     3 lanes 0.54x / 0.61x / 0.85x / 0.58x,
-     *     4 lanes 0.59x / 0.58x / 0.92x / 0.55x. One lane is never beaten.
-     *   - dense electrical schematic: 2 lanes 0.48x, 3 lanes 0.41x, 4 lanes 0.38x.
-     *   - THE TAIL IS WHERE IT HURTS MOST, and the tail is what a user sees as a
-     *     stutter. Worst-of-21 on the drawing: 126-172 ms at one lane against
-     *     177-238 ms at two. On the schematic: 134 ms against 321 ms.
-     *
-     * ONE IS ALSO THE CHEAPER OBJECT: one file descriptor and one parsed document
-     * instead of two, which on a large drawing is the larger of the two costs.
-     *
-     * DO NOT READ THE SYNTHETIC FIXTURE'S NUMBERS AS AGREEING OR DISAGREEING. With
-     * no `customer.pdf` pushed, `PdfCanvasPhaseTimingTest` falls back to a
-     * vector-rects-and-lines page whose `PdfRenderer.render` is 0.8 ms rather than
-     * 6.5 ms; that shrinks the serialised fraction, and two lanes duly measure
-     * 1.06x-1.25x there. The fixture warns that it is an optimistic bound, and this
-     * is exactly the decision it would have inverted. Push a real drawing before
-     * re-running this.
-     */
-    poolSize?: number;
-    id?: string;
-    /**
-     * How to find the installed JSI host function. Injected only by tests; the
-     * default reads `globalThis`.
-     */
-    lookupTakePixels?: () => import('./native-bridge.js').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 createAndroidRasterizer(native: AndroidPdfNativeModule, options?: AndroidRasterizerOptions): PageRasterizer;