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

package/ios/Sources/PdfCanvasCore/include/PdfCanvasRasterPixels.h

@@ -1,111 +0,0 @@
-#import <Foundation/Foundation.h>
-
-#import "PdfCanvasPixelSink.h"
-
-NS_ASSUME_NONNULL_BEGIN
-
-/**
- * The only format this backend emits: 8 bits per channel, R G B A in memory.
- *
- * It is `kCGImageAlphaPremultipliedLast | kCGBitmapByteOrder32Big`, which is
- * what Skia calls `kRGBA_8888` and what `PixelFormat` in `src/types.ts` calls
- * `'rgba8888'`. Matching Android's byte order rather than reaching for the
- * Apple-native BGRA is deliberate: cost is flat in scale on this engine
- * (measured: a 512² tile costs 0.49 / 0.39 / 0.43 / 0.39 ms at scale 1 / 2 / 4 /
- * 8), so rasterizing dominates and the byte order is not where the time goes —
- * whereas one byte order across both native backends is one fewer thing for a
- * cross-platform pixel test to have to account for.
- */
-FOUNDATION_EXPORT NSString *const PdfCanvasFormatRGBA8888;
-
-/**
- * A finished raster, mirroring `RasterPixels` in `src/types.ts`.
- *
- * `rowBytes` is STATED, never assumed to be `width * 4` by whoever reads it — 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. On this backend it is
- * tight by construction, because this library chooses the stride it hands
- * `CGBitmapContextCreate`; the value still travels because
- * `imageFromPixels` needs it and because "tight today" is a fact about today.
- *
- * MEASURED, and it constrains what a future alignment change may do:
- * `CGBitmapContextCreate` REFUSES a `bytesPerRow` that is not a multiple of 4 at
- * 32 bits per pixel (`width * 4 + 1`, `+ 2`, `+ 3` and `+ 15` all return NULL;
- * `+ 0`, `+ 4`, `+ 8`, `+ 12`, `+ 16`, `+ 64` are accepted). So row padding is
- * expressible if it ever pays for itself, but only in whole pixels.
- *
- * <h3>Where the pixels actually are</h3>
- *
- * ONE OF TWO PLACES, and `bytes` being nil is how you tell:
- *
- *  - ON THE HEAP — `bytes` is the raster and `slot` is 0. Every caller that reads
- *    pixels wants this, and it is what a nil sink produces.
- *  - IN A NATIVE SLOT — `bytes` is nil and `slot` names a buffer in
- *    `PdfCanvasSlots.mm` waiting to become a JS `ArrayBuffer`. Nothing can read
- *    the pixels back from Objective-C; the whole point is that they were written
- *    once, by CoreGraphics, and are never copied again.
- *
- * That is a deliberately awkward shape rather than two classes, because the one
- * caller that asks for a slot has to handle both anyway: a sink is allowed to
- * refuse its reservation, and the heap is the fallback. `-channelAtX:y:channel:`
- * therefore fails LOUDLY and by name on a slot-backed raster instead of throwing
- * a bare exception from somewhere further in.
- *
- * <h3>Who frees the slot</h3>
- *
- * Normally nobody: the buffer is taken exactly once by `__pdfCanvasTakePixels`
- * and freed when the JS `ArrayBuffer` is collected. `-releaseSlot` exists for the
- * paths where the raster is ABANDONED after it was drawn — a cancellation
- * observed after the draw, or a throw between the render finishing and the
- * promise resolving. Without it those megabytes sit in the slot map until the
- * next teardown, which on a dev build is the next Fast Refresh and in a release
- * build is never.
- *
- * NOT NAMED `-release`. ARC forbids declaring that selector, and a category
- * hiding a retain-count method behind a domain meaning would be a trap even if it
- * were allowed.
- */
-@interface PdfCanvasRasterPixels : NSObject
-
-/** The raster, or nil when it is in a native slot. See the class note. */
-@property(nonatomic, readonly, nullable) NSData *bytes;
-@property(nonatomic, readonly) NSInteger width;
-@property(nonatomic, readonly) NSInteger height;
-@property(nonatomic, readonly) NSInteger rowBytes;
-@property(nonatomic, readonly, copy) NSString *format;
-/** 0, or the native slot holding the raster. */
-@property(nonatomic, readonly) int64_t slot;
-
-- (instancetype)initWithSink:(id<PdfCanvasPixelSink>)sink
-                        slot:(int64_t)slot
-                       bytes:(nullable NSData *)bytes
-                       width:(NSInteger)width
-                      height:(NSInteger)height
-                    rowBytes:(NSInteger)rowBytes
-                      format:(NSString *)format NS_DESIGNATED_INITIALIZER;
-- (instancetype)init NS_UNAVAILABLE;
-
-/** Whether the pixels are in native memory and unreadable from here. */
-@property(nonatomic, readonly) BOOL isInNativeSlot;
-
-/**
- * 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.
- */
-- (void)releaseSlot;
-
-/** Byte offset of pixel (x, y), honouring the real stride. */
-- (NSInteger)offsetOfX:(NSInteger)x y:(NSInteger)y NS_SWIFT_NAME(offset(x:y:));
-
-/** One channel of one pixel, as an unsigned 0..255 value. */
-- (NSInteger)channelAtX:(NSInteger)x
-                      y:(NSInteger)y
-                channel:(NSInteger)channel
-    NS_SWIFT_NAME(channelAt(x:y:channel:));
-
-@end
-
-NS_ASSUME_NONNULL_END

package/ios/Sources/PdfCanvasCore/include/PdfCanvasRasterRequest.h

@@ -1,85 +0,0 @@
-#import <CoreGraphics/CoreGraphics.h>
-#import <Foundation/Foundation.h>
-
-NS_ASSUME_NONNULL_BEGIN
-
-typedef NS_ENUM(NSInteger, PdfCanvasBackground) {
-  /** Fill the buffer opaque white before drawing. */
-  PdfCanvasBackgroundWhite = 0,
-  /**
-   * Leave the buffer cleared to transparent before drawing.
-   *
-   * This means the CALLER accepts undrawn area coming back transparent. It is not
-   * a claim that CoreGraphics clears anything: a `CGBitmapContext` draws into
-   * whatever memory it was handed, so both backgrounds are an explicit fill and
-   * only the value differs. The transparent case happens to be free, because both
-   * destinations this library allocates arrive zeroed.
-   */
-  PdfCanvasBackgroundTransparent = 1,
-};
-
-/**
- * One raster to produce, mirroring `RasterRequest` in `src/types.ts` and
- * `RasterRequest.java` on Android.
- *
- * The doc rect is in PAGE-LOCAL points — y-down, origin at the page's top-left,
- * already post-rotation (see `PdfCanvasPageGeometry`). 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.
- *
- * `double` rather than Android's `float`, because the values arrive from JS as
- * doubles and narrowing them buys nothing. It matters in one place: at a large
- * doc offset and a high scale, `docX * scale` in float has a quantum well above a
- * pixel, and that offset is exactly what the detail layer is made of.
- */
-@interface PdfCanvasRasterRequest : NSObject
-
-@property(nonatomic, readonly) NSInteger page;
-@property(nonatomic, readonly) double docX;
-@property(nonatomic, readonly) double docY;
-@property(nonatomic, readonly) double docWidth;
-@property(nonatomic, readonly) double docHeight;
-/** Device pixels per PDF point. */
-@property(nonatomic, readonly) double scale;
-/**
- * Whether PDF-embedded annotations are drawn.
- *
- * HONOURED, unlike on Android. YES routes the render through PDFKit
- * (`-[PDFPage drawWithBox:toContext:]`, which composites annotation appearance
- * streams); NO routes it through `CGContextDrawPDFPage`, which draws the content
- * stream and nothing else. That makes iOS the only backend where the tile path
- * — which passes NO for every tile — genuinely does not double-draw an
- * annotation the app is also rendering on its Skia layer.
- */
-@property(nonatomic, readonly) BOOL annotations;
-@property(nonatomic, readonly) PdfCanvasBackground background;
-
-- (instancetype)initWithPage:(NSInteger)page
-                        docX:(double)docX
-                        docY:(double)docY
-                    docWidth:(double)docWidth
-                   docHeight:(double)docHeight
-                       scale:(double)scale
-                 annotations:(BOOL)annotations
-                  background:(PdfCanvasBackground)background
-    NS_DESIGNATED_INITIALIZER;
-- (instancetype)init NS_UNAVAILABLE;
-
-/**
- * Destination width in device pixels.
- *
- * ROUND, not ceil, and at least 1 — the same rule `planner.ts` applies
- * (`Math.max(1, Math.round(pageRect.width * scale))`), the deterministic fake
- * backend documents, and `RasterRequest.java` implements. The three have to agree
- * exactly: the planner declares the pixel size in the `RasterPlanItem` the cache
- * is keyed on, and a backend that rounded the other way would return a raster of
- * a different size than the plan promised.
- */
-@property(nonatomic, readonly) NSInteger pixelWidth;
-/** Destination height in device pixels. See `pixelWidth`. */
-@property(nonatomic, readonly) NSInteger pixelHeight;
-
-@end
-
-NS_ASSUME_NONNULL_END

package/ios/Sources/PdfCanvasCore/include/PdfCanvasRasterizer.h

@@ -1,163 +0,0 @@
-#import <Foundation/Foundation.h>
-
-#import "PdfCanvasCancellation.h"
-#import "PdfCanvasErrorCode.h"
-#import "PdfCanvasPageGeometry.h"
-#import "PdfCanvasPixelSink.h"
-#import "PdfCanvasRasterPixels.h"
-#import "PdfCanvasRasterRequest.h"
-
-NS_ASSUME_NONNULL_BEGIN
-
-/**
- * The iOS page rasterizer. CoreGraphics and PDFKit, and NOTHING from React
- * Native, JSI or Nitro — so it builds and is proven by `swift test` from
- * `ios/Package.swift` on a Mac, with no device, no simulator and no app around
- * it. That is the same split `android/src/main` draws against
- * `android/src/reactnative`, and it exists for the same reason: a bug in the
- * binding must never be able to hide as a bug in rasterizing.
- *
- * Shaped to serve `RasterizerHandle` in `src/types.ts`: `pageCount`,
- * `pageGeometry(index)`, `render(request, signal)`, `close()`.
- * `ios/Sources/PdfCanvasBridge/PdfCanvasModule.mm` is a marshalling layer over
- * this and adds no behaviour.
- *
- * ------------------------------------------------------------------------
- * HOW A TILE IS DRAWN
- * ------------------------------------------------------------------------
- *
- * `PdfCanvasDocToRasterTransform` composed with `PdfCanvasPdfToDocTransform`, into
- * a `CGBitmapContext` of exactly `pixelWidth` x `pixelHeight`. MEASURED: a tile
- * rendered that way is pixel-identical to the same region cropped out of a
- * full-page render — 0 of 41,984 pixels differing, max channel delta 0, for a
- * 64x41pt tile at doc (37, 23) at scale 4 against an 800x400 whole-page raster.
- * That is the same property spike S1 measured for Android's `PdfRenderer` and S3
- * for PDFium on web, so the off-page-origin transform the whole detail layer
- * depends on is now exact on all three engines.
- *
- * ALSO MEASURED: cost is FLAT IN SCALE. A 512² tile of a dense 540-line ARCH-D
- * page costs 0.49 / 0.39 / 0.43 / 0.39 ms at scale 1 / 2 / 4 / 8 (best of five, on
- * an Apple-silicon Mac). CoreGraphics clips rather than rasterizing the page and
- * discarding most of it — which is what makes a viewport-sized detail raster
- * constant in zoom, the premise the entire render model rests on, and it now holds
- * on every engine this package has.
- *
- * ------------------------------------------------------------------------
- * TWO ENGINES, SELECTED BY `annotations`
- * ------------------------------------------------------------------------
- *
- * `annotations: NO` — every tile — draws with `CGContextDrawPDFPage`, which
- * composites the page's content stream and not its annotation appearance streams.
- * `annotations: YES` draws with `-[PDFPage drawWithBox:toContext:]`, which
- * composites both. On a page with no annotations the two agree byte-for-byte
- * (0 of 1,280,000 bytes differing, maxDelta 0, at scale 4), which is what makes
- * choosing per render safe: the geometry does not move, only what is composited.
- *
- * The two need DIFFERENT transforms, because PDFKit applies `/Rotate` and the
- * crop-box origin itself and CoreGraphics applies neither. See
- * `PdfCanvasPageTransform.h`, which has the measurements and the trap.
- */
-@interface PdfCanvasRasterizer : NSObject
-
-/**
- * Refuse absurd rasters instead of dying on an allocation failure.
- *
- * 64 Mpx is 256 MB at 4 bytes per pixel — already past what a device will hand
- * out in one allocation, so anything above it is a planner bug, and a named error
- * against a raster key is a far better diagnostic than a jetsam kill with no key
- * attached. The TS policy has its own, much lower, ceilings (`maxRasterPixels`);
- * this is the backstop for a request that reaches here anyway. Same number as
- * `PdfCanvasRasterizer.MAX_RASTER_PIXELS` on Android.
- */
-@property(class, nonatomic, readonly) NSInteger maxRasterPixels;
-
-/**
- * @param password nil unless the document needs one. Unlike Android — which
- *     rejects any password with `unsupported`, because `LoadParams` landed at API
- *     35 — encrypted documents genuinely work here.
- * @param poolSize concurrent renders, clamped to [1, `kPdfCanvasMaxPoolSize`].
- */
-+ (nullable instancetype)openFileURL:(NSURL *)url
-                            password:(nullable NSString *)password
-                            poolSize:(NSInteger)poolSize
-                               error:(NSError *_Nullable *_Nullable)error
-    NS_SWIFT_NAME(open(fileURL:password:poolSize:));
-
-/**
- * Opens from bytes, with NO spool file.
- *
- * Android's equivalent must write a temp file first — `PdfRenderer` needs a
- * seekable descriptor and reads through a seek-and-read callback — and deletes it
- * in `close()`. `CGPDFDocumentCreateWithProvider` needs no file at all.
- *
- * Reachable only from a caller that already has the bytes in memory. The JS
- * binding deliberately does NOT expose it: getting bytes across the bridge means
- * base64-encoding the whole document, which the spec's measured rules forbid.
- */
-+ (nullable instancetype)openData:(NSData *)data
-                         password:(nullable NSString *)password
-                         poolSize:(NSInteger)poolSize
-                            error:(NSError *_Nullable *_Nullable)error
-    NS_SWIFT_NAME(open(data:password:poolSize:));
-
-@property(nonatomic, readonly) NSInteger pageCount;
-/** How many renders can genuinely be in flight at once. */
-@property(nonatomic, readonly) NSInteger poolSize;
-@property(nonatomic, readonly, getter=isClosed) BOOL closed;
-
-/**
- * An array read.
- *
- * Every page's geometry is probed ONCE, at open. The `RasterizerHandle` contract
- * says `pageGeometry` is cheap and "must not load a page", and reading a page's
- * crop box and rotation means asking CoreGraphics for a `CGPDFPageRef` — so the
- * asking happens at open and this becomes a lookup. Note that a `CGPDFPageRef` is
- * built from the page DICTIONARY and parses no content stream, so the open cost is
- * proportional to the page tree rather than to what is drawn.
- */
-- (nullable PdfCanvasPageGeometry *)pageGeometryAtIndex:(NSInteger)index
-                                                  error:
-                                                      (NSError *_Nullable
-                                                           *_Nullable)error
-    NS_SWIFT_NAME(pageGeometry(at:));
-
-/**
- * Renders one raster.
- *
- * @param sink where the bytes go. Nil means the heap, which is what every
- *     pixel-reading caller wants and what the whole Swift suite uses. A non-nil
- *     sink is the zero-copy transport: CoreGraphics writes straight into the
- *     buffer that becomes a JS `ArrayBuffer`. A sink is allowed to REFUSE its
- *     reservation, in which case this falls through to the heap and the result is
- *     heap-backed — so check `isInNativeSlot` on the way out rather than assuming.
- *
- * @return nil on failure, with `error` carrying a `PdfCanvasErrorCode`. A
- *     cancellation observed AFTER the draw finished releases the sink itself
- *     before returning; every abandon path after this method returns belongs to
- *     the caller.
- */
-- (nullable PdfCanvasRasterPixels *)render:(PdfCanvasRasterRequest *)request
-                              cancellation:
-                                  (nullable PdfCanvasCancellation *)signal
-                                      sink:(nullable id<PdfCanvasPixelSink>)sink
-                                     error:(NSError *_Nullable *_Nullable)error;
-
-- (void)close;
-
-- (instancetype)init NS_UNAVAILABLE;
-
-/**
- * Whether this platform draws a page carrying `/Rotate` upright.
- *
- * Always `@"supported"`, and it is a constant rather than a probe because there is
- * no device variable: `PdfCanvasPdfToDocTransform` applies the rotation and
- * PDFKit applies its own, on every OS version this library builds for. It exists
- * only because it is part of the shared wire format — Android has to probe it,
- * since API 24 reports rotated DIMENSIONS while drawing the content unrotated and
- * clipped, and a host should not have to know which platform it is on to ask.
- */
-@property(class, nonatomic, readonly) NSString *rotationSupport;
-
-@end
-
-NS_ASSUME_NONNULL_END

package/ios/Sources/PdfCanvasSlots/PdfCanvasSlots.mm

@@ -1,297 +0,0 @@
-#import "PdfCanvasSlots.h"
-
-/*
- * TWO BUILDS, ONE FILE — the same split `android/src/jsi/cpp/pdfcanvas-jsi.cpp`
- * draws, and for the same reason.
- *
- *   jsi.h present  — the podspec's build. The host function is installed onto the JS
- *                    global and a taken slot becomes a `jsi::ArrayBuffer` over the
- *                    very bytes CoreGraphics wrote.
- *   jsi.h absent   — the SwiftPM build (`ios/Package.swift`), which has no React
- *                    Native and no `jsi.h` to include. `PdfCanvasSlotsInstall`
- *                    reports NO and the slot storage compiles on its own.
- *
- * That second configuration is not a stub for its own sake: it is what lets
- * `SlotsTests.swift` prove ON A LAPTOP that the bytes which become the ArrayBuffer
- * are the bytes CoreGraphics wrote, that a slot is taken exactly once, and that every
- * abandon path frees. Those are the failure modes that are a leak or a
- * use-after-free rather than a wrong pixel, and a device session does not show them.
- * The storage under test is the production storage — the only thing the two builds do
- * not share is the JSI call itself.
- */
-#if __has_include(<jsi/jsi.h>)
-#define PDFCANVAS_WITH_JSI 1
-#import <jsi/jsi.h>
-#endif
-
-#import <atomic>
-#import <cstdint>
-#import <cstring>
-#import <memory>
-#import <mutex>
-#import <string>
-#import <unordered_map>
-#import <vector>
-
-namespace {
-
-#ifdef PDFCANVAS_WITH_JSI
-using SlotBufferBase = facebook::jsi::MutableBuffer;
-#else
-/**
- * The two methods `jsi::MutableBuffer` declares, restated so the SwiftPM build
- * compiles the identical storage code with no JSI header in sight.
- *
- * If these ever drift from `jsi.h` the podspec build stops compiling, which is the
- * failure mode worth having — a silent divergence would mean the tested storage and
- * the shipped storage were different types.
- */
-struct SlotBufferBase {
-  virtual ~SlotBufferBase() = default;
-  virtual size_t size() const = 0;
-  virtual uint8_t *data() = 0;
-};
-#endif
-
-/**
- * One raster's bytes, owned outright, and shaped so Hermes can wrap it.
- *
- * `std::vector<uint8_t> bytes_(size)` VALUE-initialises, so constructing this
- * zeroes the whole raster. On Android the equivalent line carries a long note
- * about that being a second full-raster pass whose only justification is an
- * invariant; here it is not optional and not merely an invariant — the
- * `PdfCanvasPixelSink` contract promises zeroed memory, and that promise is what
- * makes `background: 'transparent'` free. Removing it would break a documented
- * behaviour rather than shaving a pass.
- */
-class SlotBuffer final : public SlotBufferBase {
- public:
-  explicit SlotBuffer(size_t size) : bytes_(size) {}
-
-  size_t size() const override { return bytes_.size(); }
-  uint8_t *data() override { return bytes_.data(); }
-
- private:
-  std::vector<uint8_t> bytes_;
-};
-
-/**
- * Slots are published on a render worker and taken on the JS thread, so the map is
- * guarded. The lock is held only around the map operation itself — never across an
- * allocation, never across a fill, and never across a JSI call.
- */
-std::mutex g_slotsMutex;
-std::unordered_map<int64_t, std::shared_ptr<SlotBuffer>> g_slots;
-
-/**
- * Slot ids, from one counter per PROCESS.
- *
- * Starting at 1 because 0 is `PdfCanvasRasterPixels`' "heap-backed" sentinel. It is
- * a process-wide `std::atomic` rather than per-module state for the reason
- * Android's equivalent is `static`: React Native builds a fresh set of native
- * modules on every reload while the outgoing one may still have rasters parked, and
- * a per-module counter starting at 1 would hand the SAME id to two modules. The
- * second store would silently replace the first module's buffer and that module's
- * take would return ANOTHER tile's pixels — a wrong image, not an error.
- */
-std::atomic<int64_t> g_nextSlot{1};
-
-std::shared_ptr<SlotBuffer> takeSlot(int64_t slot) {
-  std::lock_guard<std::mutex> lock(g_slotsMutex);
-  auto found = g_slots.find(slot);
-  if (found == g_slots.end()) {
-    return nullptr;
-  }
-  std::shared_ptr<SlotBuffer> buffer = std::move(found->second);
-  g_slots.erase(found);
-  return buffer;
-}
-
-}  // namespace
-
-/* ------------------------------------------------------------------ *
- * The sink
- * ------------------------------------------------------------------ */
-
-@implementation PdfCanvasSlotSink {
-  /**
-   * Held HERE and nowhere else until `pdfCanvasPublish`. That is the whole safety
-   * property: until the buffer is in `g_slots` it is unreachable from
-   * `PdfCanvasSlotsReleaseAll`, which runs on another thread on every Fast
-   * Refresh, so a reload landing mid-draw cannot free memory CoreGraphics is
-   * writing into.
-   */
-  std::shared_ptr<SlotBuffer> _buffer;
-  int64_t _slot;
-  BOOL _published;
-  BOOL _reserved;
-}
-
-- (nullable void *)pdfCanvasReserveBytes:(NSUInteger)length {
-  if (_reserved || length == 0) {
-    return NULL;
-  }
-  _reserved = YES;
-  try {
-    _buffer = std::make_shared<SlotBuffer>(static_cast<size_t>(length));
-  } catch (...) {
-    // `std::bad_alloc` for a multi-megabyte raster under memory pressure. Reported
-    // as a refusal rather than propagated: the rasterizer falls straight through to
-    // a heap sink and the tile still goes out, which is the point of refusing
-    // BEFORE anything is drawn. A C++ exception escaping into ARC-managed
-    // Objective-C would also be a very bad way to say "no memory".
-    _buffer = nullptr;
-    return NULL;
-  }
-  // Allocated next to the map it goes into, from a process-wide counter, so a
-  // collision at publish is unrepresentable. See the class note in the header.
-  _slot = g_nextSlot.fetch_add(1, std::memory_order_relaxed);
-  return _buffer->data();
-}
-
-- (int64_t)pdfCanvasPublish {
-  if (_buffer == nullptr || _published) {
-    return 0;
-  }
-  {
-    std::lock_guard<std::mutex> lock(g_slotsMutex);
-    // ASSIGNMENT, not `emplace`, and it cannot collide: the id came from the
-    // process-wide counter a moment ago. Android's equivalent has to refuse a
-    // collision because its ids are handed in from Java.
-    g_slots[_slot] = _buffer;
-  }
-  _published = YES;
-  // The map holds the only reference this object needs to care about from here on.
-  // Dropping the local one means a successful take is the sole owner, so the buffer
-  // dies with the JS ArrayBuffer rather than with this sink.
-  _buffer = nullptr;
-  return _slot;
-}
-
-- (void)pdfCanvasAbandon {
-  if (_published) {
-    // Already in the map. Taking it back out is what frees it — and finding
-    // nothing is the normal case when JS has already redeemed it, which is why
-    // this is a lookup rather than an assertion.
-    takeSlot(_slot);
-    _published = NO;
-    _slot = 0;
-    return;
-  }
-  // Never published: the buffer is still ours and the shared_ptr frees it.
-  _buffer = nullptr;
-}
-
-@end
-
-/* ------------------------------------------------------------------ *
- * The probe
- * ------------------------------------------------------------------ */
-
-NSData *PdfCanvasSlotsProbeBytes(void) {
-  // Chosen, not arbitrary. 0x00 and 0xFF pin both ends of the range, and
-  // 0xFD/0xFE/0xFF sit above 0x7F where a signed-byte slip would show up. The
-  // sign-extension hazard does not exist on this platform — the whole path is
-  // `uint8_t` — but the list is shared with Android and with the TS side, and
-  // three copies that agree are worth more than one that is locally optimal.
-  static const uint8_t bytes[] = {0x00, 0x01, 0x02, 0xFD, 0xFE, 0xFF, 0x2A, 0x07};
-  return [NSData dataWithBytes:bytes length:sizeof(bytes)];
-}
-
-int64_t PdfCanvasSlotsStoreProbe(void) {
-  NSData *probe = PdfCanvasSlotsProbeBytes();
-  PdfCanvasSlotSink *sink = [[PdfCanvasSlotSink alloc] init];
-  void *bytes = [sink pdfCanvasReserveBytes:probe.length];
-  if (bytes == NULL) {
-    return -1;
-  }
-  std::memcpy(bytes, probe.bytes, probe.length);
-  return [sink pdfCanvasPublish];
-}
-
-/* ------------------------------------------------------------------ *
- * Install
- * ------------------------------------------------------------------ */
-
-BOOL PdfCanvasSlotsInstall(void *runtimePointer) {
-#ifdef PDFCANVAS_WITH_JSI
-  if (runtimePointer == nullptr) {
-    return NO;
-  }
-  auto &runtime = *reinterpret_cast<facebook::jsi::Runtime *>(runtimePointer);
-  try {
-    auto name =
-        facebook::jsi::PropNameID::forAscii(runtime, "__pdfCanvasTakePixels");
-    auto take = facebook::jsi::Function::createFromHostFunction(
-        runtime, name, 1,
-        [](facebook::jsi::Runtime &rt, const facebook::jsi::Value &,
-           const facebook::jsi::Value *args,
-           size_t count) -> facebook::jsi::Value {
-          if (count < 1 || !args[0].isNumber()) {
-            throw facebook::jsi::JSError(
-                rt, "__pdfCanvasTakePixels(slot): slot must be a number.");
-          }
-          const auto slot = static_cast<int64_t>(args[0].asNumber());
-          std::shared_ptr<SlotBuffer> buffer = takeSlot(slot);
-          if (buffer == nullptr) {
-            // Every slot is taken exactly once, so this means the render that
-            // filled it was torn down (a reload drains every slot) or the same
-            // slot was taken twice. Named rather than silently empty: an empty
-            // ArrayBuffer would reach Skia and draw a black tile.
-            throw facebook::jsi::JSError(
-                rt,
-                "__pdfCanvasTakePixels: no raster is waiting in slot " +
-                    std::to_string(slot) +
-                    ". It was already taken, or the module was invalidated.");
-          }
-          // The ArrayBuffer BORROWS this buffer and the shared_ptr keeps it alive;
-          // the slot map has already dropped its reference, so JS is now the sole
-          // owner and the GC is what frees it.
-          return facebook::jsi::Value(
-              rt, facebook::jsi::ArrayBuffer(rt, std::move(buffer)));
-        });
-    runtime.global().setProperty(runtime, name, take);
-    return YES;
-  } catch (...) {
-    // A runtime that refuses to install a host function is a runtime this package
-    // will not use. The JS side falls back to base64.
-    return NO;
-  }
-#else
-  // The SwiftPM build. There is no runtime to install into and nothing that could
-  // call the host function, so this is the honest answer rather than a stub.
-  (void)runtimePointer;
-  return NO;
-#endif
-}
-
-/* ------------------------------------------------------------------ *
- * Teardown and diagnostics
- * ------------------------------------------------------------------ */
-
-void PdfCanvasSlotsRelease(int64_t slot) {
-  takeSlot(slot);
-}
-
-void PdfCanvasSlotsReleaseAll(void) {
-  std::unordered_map<int64_t, std::shared_ptr<SlotBuffer>> drained;
-  {
-    std::lock_guard<std::mutex> lock(g_slotsMutex);
-    drained.swap(g_slots);
-  }
-  // Freed outside the lock. Dropping several megabytes of buffers is not something
-  // to do while the JS thread might be waiting on the same mutex.
-}
-
-NSInteger PdfCanvasSlotsCount(void) {
-  std::lock_guard<std::mutex> lock(g_slotsMutex);
-  return static_cast<NSInteger>(g_slots.size());
-}
-
-NSData *_Nullable PdfCanvasSlotsTakeForTest(int64_t slot) {
-  std::shared_ptr<SlotBuffer> buffer = takeSlot(slot);
-  if (buffer == nullptr) {
-    return nil;
-  }
-  return [NSData dataWithBytes:buffer->data() length:buffer->size()];
-}