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

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

@@ -1,122 +0,0 @@
-#import <CoreGraphics/CoreGraphics.h>
-#import <Foundation/Foundation.h>
-#import <PDFKit/PDFKit.h>
-
-#import "PdfCanvasErrorCode.h"
-
-NS_ASSUME_NONNULL_BEGIN
-
-/** Ceiling on pooled documents. Mirrored by `MAX_POOL_SIZE` in `src/rasterizer/ios.ts`. */
-FOUNDATION_EXPORT const NSInteger kPdfCanvasMaxPoolSize;
-
-/**
- * One lane's worth of parsed document: a `CGPDFDocumentRef` and, once something
- * asks for annotations, a `PDFDocument`.
- *
- * THE PDFKit HALF IS LAZY, and that is the whole reason the two live in one
- * object. Every tile the controller asks for passes `annotations: NO` and goes
- * through CGPDF, so a `PDFDocument` opened eagerly at `open()` would parse a
- * second copy of an ARCH-E sheet that the common path never touches. It is opened
- * on the first `annotations: YES` render in this lane and kept, because a thumbnail
- * strip asks repeatedly.
- *
- * ONE LANE, ONE PARSE OF EACH. Neither `CGPDFDocumentRef` nor `PDFDocument` is
- * documented thread-safe, and sharing one across lanes would mean a lock this
- * library owns — which buys nothing over just leasing. Opening the file once per
- * lane is the same argument `PdfRendererPool` makes for opening afresh rather than
- * `dup(2)`-ing a descriptor: independent state is the invariant the code needs,
- * and one extra parse is what it costs.
- */
-@interface PdfCanvasDocumentLease : NSObject
-
-/** Never NULL for a live lease. Owned by this object and released on dealloc. */
-@property(nonatomic, readonly) CGPDFDocumentRef cgDocument;
-
-/**
- * The PDFKit document for this lane, opening it if this is the first ask.
- *
- * Fails with `corrupt` if PDFKit refuses a document CoreGraphics accepted, and
- * with `password-required` / `password-incorrect` if it cannot be unlocked — the
- * two engines keep separate locks, so the password has to be presented twice.
- */
-- (nullable PDFDocument *)pdfKitDocumentWithError:
-    (NSError *_Nullable *_Nullable)error;
-
-- (instancetype)init NS_UNAVAILABLE;
-
-@end
-
-/**
- * A fixed set of parsed documents over the same bytes, leased one at a time.
- *
- * ------------------------------------------------------------------------
- * CLOSE-WHILE-LEASED IS SAFE HERE, AND ON ANDROID IT IS NOT.
- * ------------------------------------------------------------------------
- *
- * `PdfRendererPool.close()` closes every renderer including the ones currently
- * leased, and its own comment calls that "the only honest option": `close()` comes
- * from JS when a document unmounts, and blocking until an in-flight ARCH-D render
- * finishes is worse. It leaves a window.
- *
- * There is no window here, because CoreFoundation refcounts. A lease OWNS its
- * `CGPDFDocumentRef` and releases it in `dealloc`, so `close` dropping the pool's
- * references cannot free a document a render worker is still drawing from — the
- * worker holds the lease, and the last reference goes away when it returns the
- * lease to a closed pool. `close` is therefore non-blocking AND has no
- * use-after-free, which is strictly better than the Android behaviour rather than
- * a different trade.
- */
-@interface PdfCanvasDocumentPool : NSObject
-
-/**
- * @param password nil unless the document needs one. Both engines are unlocked
- *     with it — CGPDF eagerly, PDFKit on first use — and a wrong one is
- *     `password-incorrect` rather than `corrupt`.
- * @param size clamped to [1, `kPdfCanvasMaxPoolSize`].
- */
-+ (nullable instancetype)openFileURL:(NSURL *)url
-                            password:(nullable NSString *)password
-                                size:(NSInteger)size
-                               error:(NSError *_Nullable *_Nullable)error
-    NS_SWIFT_NAME(open(fileURL:password:size:));
-
-/**
- * Opens from bytes with no spool file.
- *
- * Worth contrasting with Android, where `PdfCanvasRasterizer.openBytes` MUST
- * write a temp file first because `PdfRenderer` needs a seekable descriptor and
- * reads through a seek-and-read callback. `CGPDFDocumentCreateWithProvider` over a
- * `CFData` needs no file at all, and every lane can share the same immutable
- * `NSData` because each gets its own provider and its own parse.
- */
-+ (nullable instancetype)openData:(NSData *)data
-                         password:(nullable NSString *)password
-                             size:(NSInteger)size
-                            error:(NSError *_Nullable *_Nullable)error
-    NS_SWIFT_NAME(open(data:password:size:));
-
-@property(nonatomic, readonly) NSInteger pageCount;
-/** How many renders can genuinely be in flight at once. */
-@property(nonatomic, readonly) NSInteger size;
-@property(nonatomic, readonly, getter=isClosed) BOOL closed;
-
-/**
- * Blocks until a lane 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.
- */
-- (nullable PdfCanvasDocumentLease *)leaseWithError:
-    (NSError *_Nullable *_Nullable)error;
-
-/** Always call from a `@finally`-shaped path: a leaked lease starves every later render. */
-- (void)returnLease:(nullable PdfCanvasDocumentLease *)lease;
-
-- (void)close;
-
-- (instancetype)init NS_UNAVAILABLE;
-
-@end
-
-NS_ASSUME_NONNULL_END

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

@@ -1,80 +0,0 @@
-#import <Foundation/Foundation.h>
-
-NS_ASSUME_NONNULL_BEGIN
-
-/**
- * The eight failure kinds, mirroring `PdfErrorCode` in `src/types.ts` and
- * `PdfErrorCode.java` on Android.
- *
- * The WIRE STRINGS are the TypeScript union members verbatim. They are the
- * contract across the bridge: the binding rejects a promise with
- * `PdfCanvasErrorCodeWire()` and the TS side reconstructs a `PdfError` from it
- * with no translation table in between (`toPdfError` in
- * `src/rasterizer/native-bridge.ts`). Adding a member here without adding it
- * there produces a `PdfError` with a code no consumer can switch on, so the
- * lists have to move together — and there are now THREE of them, since Android
- * has its own copy.
- */
-typedef NS_ENUM(NSInteger, PdfCanvasErrorCode) {
-  PdfCanvasErrorCodeNotFound = 0,
-  PdfCanvasErrorCodePasswordRequired,
-  PdfCanvasErrorCodePasswordIncorrect,
-  PdfCanvasErrorCodeCorrupt,
-  PdfCanvasErrorCodeUnsupported,
-  PdfCanvasErrorCodeCancelled,
-  PdfCanvasErrorCodeOutOfMemory,
-  PdfCanvasErrorCodeBackendFailure,
-};
-
-/**
- * The `NSError` domain every failure in this library carries.
- *
- * `NSError` rather than an exception subclass, and that is not merely idiomatic:
- * Objective-C exceptions are not a control-flow mechanism ARC unwinds safely, and
- * this library allocates CoreGraphics objects on every path. Android can afford a
- * checked `PdfRasterException` because the JVM unwinds; here the `NSError **`
- * out-parameter is what keeps every `CGPDFDocumentRelease` reachable.
- */
-FOUNDATION_EXPORT NSErrorDomain const PdfCanvasErrorDomain;
-
-/** The TypeScript union member for a code. Never nil. */
-FOUNDATION_EXPORT NSString *PdfCanvasErrorCodeWire(PdfCanvasErrorCode code);
-
-/**
- * Builds an error in `PdfCanvasErrorDomain` whose `code` is the enum and whose
- * `localizedDescription` is `message`.
- *
- * The `underlying` error is always kept when there is one. A `corrupt` verdict
- * that turns out to be a truncated download is only diagnosable from whatever
- * CoreGraphics or the file system said first.
- */
-FOUNDATION_EXPORT NSError *PdfCanvasMakeError(
-    PdfCanvasErrorCode code,
-    NSString *message,
-    NSError *_Nullable underlying);
-
-/**
- * Reads a code back out of an error.
- *
- * Anything not in `PdfCanvasErrorDomain` — an `NSError` from `NSFileManager`, say
- * — reads as `PdfCanvasErrorCodeBackendFailure`, because a foreign error reaching
- * a caller that wanted a code is a mapping this library forgot rather than a new
- * kind of failure.
- */
-FOUNDATION_EXPORT PdfCanvasErrorCode PdfCanvasErrorCodeOf(NSError *error);
-
-/**
- * Assigns to an `NSError **` out-parameter if the caller supplied one, and
- * returns nil so a failing method can `return PdfCanvasFail(error, ...)`.
- *
- * Exists because the alternative — `if (error) *error = ...; return nil;` — is
- * three lines that get shortened to two on a bad day, and the line that gets
- * dropped is the assignment.
- */
-FOUNDATION_EXPORT id _Nullable PdfCanvasFail(
-    NSError *_Nullable *_Nullable out,
-    PdfCanvasErrorCode code,
-    NSString *message,
-    NSError *_Nullable underlying);
-
-NS_ASSUME_NONNULL_END

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

@@ -1,79 +0,0 @@
-#import <CoreGraphics/CoreGraphics.h>
-#import <Foundation/Foundation.h>
-
-NS_ASSUME_NONNULL_BEGIN
-
-/**
- * A page's intrinsic size in PDF points, mirroring `PageGeometry` in
- * `src/types.ts`.
- *
- * POST-ROTATION, per that contract: a 612x792 page carrying `/Rotate 90` reports
- * 792x612. Unlike Android — where `PdfRenderer.Page.getWidth()` happens to
- * already be post-rotation and there is no way to read `/Rotate` at all below
- * API 35 — this backend computes it, because CoreGraphics reports the raw box and
- * the raw `/Rotate` separately and applies neither.
- *
- * MEASURED, both halves: `CGPDFPageGetBoxRect(page, kCGPDFCropBox)` on a
- * `/Rotate 90` letter page returns `(0, 0, 612, 792)` — unrotated — and
- * `CGPDFPageGetRotationAngle` returns 90. So the swap below is this library's
- * arithmetic and is pinned by `pageGeometryIsPostRotation` in the Swift suite.
- *
- * `rotationDegrees` reports the page's REAL `/Rotate`, which is what the web
- * PDFium backend does and the opposite of what Android does (it reports 0,
- * because it cannot read the value). `PageGeometry.rotation` is informational to
- * this package — nothing applies a further rotation on the strength of it — and
- * `src/rasterizer/native-bridge.ts` documents the divergence at the field.
- *
- * `cropBox` is the box the raster is defined against: `kCGPDFCropBox`
- * INTERSECTED with `kCGPDFMediaBox`, in PDF user space (y-up), origin NOT
- * normalised away. It is exposed rather than kept private because it is the only
- * input `PdfCanvasPdfToDocTransform` needs, and that is what makes the transform
- * testable without a document.
- */
-@interface PdfCanvasPageGeometry : NSObject
-
-@property(nonatomic, readonly) NSInteger index;
-/** Width in PDF points, after `/Rotate`. */
-@property(nonatomic, readonly) CGFloat widthPoints;
-/** Height in PDF points, after `/Rotate`. */
-@property(nonatomic, readonly) CGFloat heightPoints;
-/** The page's `/Rotate`, normalised to 0, 90, 180 or 270. */
-@property(nonatomic, readonly) NSInteger rotationDegrees;
-/** CropBox ∩ MediaBox, in PDF user space. NOT rotated, NOT origin-normalised. */
-@property(nonatomic, readonly) CGRect cropBox;
-
-- (instancetype)initWithIndex:(NSInteger)index
-                     cropBox:(CGRect)cropBox
-             rotationDegrees:(NSInteger)rotationDegrees NS_DESIGNATED_INITIALIZER;
-- (instancetype)init NS_UNAVAILABLE;
-
-@end
-
-/**
- * Normalises any `/Rotate` value to 0, 90, 180 or 270.
- *
- * The spec allows only multiples of 90 and real files carry negatives (`-90`) and
- * out-of-range values (`450`). A value that is not a multiple of 90 after
- * normalisation is reported as 0 rather than rounded: rounding 45 to either
- * neighbour is a guess, and drawing the page unrotated is the one answer that is
- * merely wrong rather than wrong AND surprising.
- */
-FOUNDATION_EXPORT NSInteger PdfCanvasNormalizeRotation(NSInteger degrees);
-
-/**
- * CropBox ∩ MediaBox for a page, in PDF user space.
- *
- * `CGPDFPageGetBoxRect(page, kCGPDFCropBox)` already falls back to the media box
- * when there is no crop box, so the common case is a no-op — but it does NOT do
- * the intersection the PDF spec requires ("the crop box shall be intersected with
- * the media box"), and a file whose crop box overhangs its media box would
- * otherwise produce a page larger than the paper, with every rect the layout
- * function derives from it wrong by the overhang.
- *
- * A degenerate intersection falls back to the MEDIA box rather than to an empty
- * rect. A zero-area page would make `fitScale` non-finite and the planner would
- * emit nothing at all, which presents as a blank document with no error anywhere.
- */
-FOUNDATION_EXPORT CGRect PdfCanvasEffectiveCropBox(CGPDFPageRef page);
-
-NS_ASSUME_NONNULL_END

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

@@ -1,129 +0,0 @@
-#import <CoreGraphics/CoreGraphics.h>
-#import <Foundation/Foundation.h>
-
-NS_ASSUME_NONNULL_BEGIN
-
-/**
- * The three affine transforms this backend is built out of.
- *
- * THEIR OWN FILE, WITH NO DOCUMENT IN SIGHT, because they are the part that can
- * be wrong in a way that looks plausible. A rotation applied the wrong way round,
- * a crop-box origin left in, a y-flip that lands half a pixel off — none of those
- * throws, and all of them are checkable by mapping four corners with no PDF, no
- * bitmap and no CoreGraphics state. `PdfCanvasTransformTests.swift` does exactly
- * that, and only then does `PdfCanvasRasterizerTests.swift` check that a rendered
- * page agrees.
- *
- * ------------------------------------------------------------------------
- * THE THREE SPACES
- * ------------------------------------------------------------------------
- *
- * PDF USER SPACE — y-UP, origin wherever the page's boxes say. This is the space
- * `CGContextDrawPDFPage` draws in, and it applies neither the crop box's origin
- * nor `/Rotate` (both MEASURED — see the notes on each function below).
- *
- * DOC SPACE — y-DOWN, origin at the ROTATED page's top-left, units of PDF points.
- * This is the package's one coordinate system (`src/types.ts`: "PDF points,
- * y-down, origin at the page's top-left, exactly what PDFium's
- * CPDF_Page::GetDisplayMatrix() emits"). Every rect that crosses the JS boundary
- * is in it.
- *
- * RASTER SPACE — the `CGBitmapContext`'s own: y-UP from the bottom-left, units of
- * device pixels, extent exactly the request's `pixelWidth` x `pixelHeight`.
- *
- * ------------------------------------------------------------------------
- * WHY THE PIXEL HEIGHT IN THE FLIP IS THE ROUNDED ONE, AND WHY THAT IS EXACT
- * ------------------------------------------------------------------------
- *
- * `PdfCanvasDocToRasterTransform` flips through `pixelHeight`, which is
- * `round(docHeight * scale)` and therefore up to half a pixel away from
- * `docHeight * scale`. That looks like it would make two rasters requested at the
- * same scale disagree where they overlap — the property the cache and the
- * overlapping detail pieces depend on, and the one `tileMatrix` on Android has a
- * long comment about.
- *
- * It does not, and the cancellation is exact. A doc point `dy` lands at raster
- * y = `H - (dy - docY) * scale`, and a reader indexing rows from the TOP sees
- * `H - y` = `(dy - docY) * scale`. `H` cancels. So the rounding decides only how
- * much of the far edge exists at all — at most half a pixel, left showing the
- * background fill, exactly as on Android — and never where content lands relative
- * to the raster's origin. `tileTransformsAgreeWhereTheyOverlap` pins it with two
- * rects whose pixel heights round in opposite directions.
- *
- * `scale` is likewise used EXACTLY as requested and never re-derived from
- * `pixelWidth / docWidth`, for the reason `PdfCanvasRasterizer.java` gives: it is
- * what makes two rasters at the same scale agree pixel-for-pixel over their
- * overlap. Re-deriving would instead make each raster cover its doc rect to the
- * last sub-pixel, at the cost of every pair of neighbours being drawn at
- * imperceptibly different scales.
- */
-
-/**
- * PDF user space -> doc space.
- *
- * `cropBox` is CropBox ∩ MediaBox in PDF user space, origin NOT normalised away;
- * `rotationDegrees` is the page's `/Rotate`, already normalised to 0/90/180/270.
- *
- * MEASURED, and this function exists because both halves came out "no":
- * `CGContextDrawPDFPage` applies NEITHER the crop box origin NOR `/Rotate`. On a
- * `/Rotate 90` letter page, drawing with the rotation in this transform puts the
- * marker at the displayed top-right (correct) and drawing without it puts it at
- * the top-left, clipped (wrong). On a page with MediaBox `0 0 400 400` and CropBox
- * `100 150 300 350`, the `-cropBox.minX` term is what puts the crop box's own
- * top-left corner at doc (0, 0).
- *
- * Every one of the four cases has determinant -1, and that is not a bug: doc space
- * is y-down while PDF space is y-up, so a rotation in the DISPLAY sense is a
- * rotation composed with a reflection in raw coordinates. A case that came out
- * +1 would be the one to distrust.
- */
-FOUNDATION_EXPORT CGAffineTransform PdfCanvasPdfToDocTransform(
-    CGRect cropBox, NSInteger rotationDegrees);
-
-/**
- * Doc space -> raster space, for one request.
- *
- * `pixelHeight` is the destination bitmap's height in device pixels — the
- * request's own `pixelHeight`, not `docHeight * scale`. See the file note for why
- * that is exact rather than approximate.
- */
-FOUNDATION_EXPORT CGAffineTransform PdfCanvasDocToRasterTransform(
-    double docX, double docY, double scale, NSInteger pixelHeight);
-
-/**
- * Doc space -> the y-up, page-sized space PDFKit draws into.
- *
- * `pageHeightPoints` is the POST-ROTATION crop-box height, i.e.
- * `PdfCanvasPageGeometry.heightPoints`.
- *
- * ------------------------------------------------------------------------
- * PDFKit'S ASYMMETRY, MEASURED, AND IT IS A TRAP
- * ------------------------------------------------------------------------
- *
- * `-[PDFPage drawWithBox:toContext:]` DOES apply `/Rotate` and DOES normalise the
- * box origin — so, unlike the CGPDF path, nothing here may rotate anything.
- * But `-[PDFPage boundsForBox:]` does NOT apply `/Rotate`: on the same
- * `/Rotate 90` letter page it returns `(0, 0, 612, 792)` while `drawWithBox:`
- * draws a 792 x 612 landscape page. It DOES report the crop box's origin
- * (`(100, 150, 200, 200)` for the offset-crop fixture), so it is not simply
- * normalising either.
- *
- * The consequence, and the whole reason this takes the height as an argument
- * rather than reading it off the page: flipping by `boundsForBox:.size.height`
- * flips a rotated page by the WRONG number, and the result is a page drawn
- * rotated, off-centre and clipped, with no error anywhere. The height must come
- * from `PdfCanvasPageGeometry`, which computes the post-rotation size from the
- * CGPDF crop box and rotation. Widely-copied sample code — flip by
- * `page.bounds(for:).size.height`, then draw — is correct only for unrotated
- * pages.
- *
- * With the height right, the two engines agree byte-for-byte on a page with no
- * annotations: 0 of 1,280,000 bytes differing, maxDelta 0, at scale 4 over an
- * 800x400 raster. That equality is what lets `annotations` pick an engine per
- * render without the geometry moving, and it is asserted by
- * `bothEnginesAgreeOnAPageWithNoAnnotations`.
- */
-FOUNDATION_EXPORT CGAffineTransform PdfCanvasDocToPdfKitTransform(
-    double pageHeightPoints);
-
-NS_ASSUME_NONNULL_END

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

@@ -1,100 +0,0 @@
-#import <Foundation/Foundation.h>
-
-NS_ASSUME_NONNULL_BEGIN
-
-/**
- * Where a raster's bytes are to be written.
- *
- * ------------------------------------------------------------------------
- * THIS PROTOCOL IS WHY THE iOS TRANSPORT COSTS ZERO COPIES.
- * ------------------------------------------------------------------------
- *
- * Android's fast path costs ONE full-raster copy and cannot do better: a
- * `Bitmap` owns its own pixel memory, `PdfRenderer.render` writes into that, and
- * the best `nativeStoreFromBitmap` can do is one `memcpy` out of it. There is no
- * way to tell `PdfRenderer` where to put the pixels.
- *
- * `CGBitmapContextCreate` takes the destination pointer as an argument. So the
- * bytes are written ONCE, by CoreGraphics, straight into the buffer the JS
- * `ArrayBuffer` will later wrap. There is no bitmap object, no `NSData`, no
- * `memcpy`, and nothing for a garbage collector to notice.
- *
- * The core does not know what a slot is, and must not: `PdfCanvasCore` builds and
- * is tested with no React Native and no JSI anywhere near it. So the destination
- * is injected, this protocol is the seam, and
- * `ios/Sources/PdfCanvasBridge/PdfCanvasSlots.mm` is its only production
- * implementation. `PdfCanvasHeapSink` below is the default and is what every
- * pixel-reading caller — the whole Swift suite, and the base64 fallback — uses.
- *
- * ------------------------------------------------------------------------
- * THE ORDER IS RESERVE, FILL, PUBLISH, AND IT IS LOAD-BEARING.
- * ------------------------------------------------------------------------
- *
- * The Android JSI file records the bug this shape avoids, in its own words: a
- * buffer that is reachable from a process-wide map BEFORE it is filled can be
- * freed by a teardown running on another thread while a render worker is still
- * writing into it — "silent heap corruption, weeks from the change that caused
- * it". So a reserved buffer is owned by the sink object alone, held on the
- * rendering thread's stack, and becomes reachable only at `publish`.
- *
- * A REFUSAL COSTS NOTHING, because it happens before the draw. `reserveBytes:`
- * returning NULL means "no fast destination available"; the rasterizer falls
- * straight through to a heap sink and the tile still goes out. Contrast Android,
- * where the refusal can only be discovered after the raster exists.
- */
-@protocol PdfCanvasPixelSink <NSObject>
-
-/**
- * Reserve `length` bytes, zeroed, and return a pointer to them — or NULL to
- * refuse.
- *
- * Called AT MOST ONCE per sink, before anything is drawn. The returned memory
- * must stay valid and stable until `pdfCanvasPublish` or `pdfCanvasAbandon`, and
- * after a publish it must stay valid until whoever took it is done with it.
- *
- * ZEROED IS PART OF THE CONTRACT, not an accident of the implementation. It is
- * what makes `PdfCanvasBackgroundTransparent` free, and it is the invariant that
- * stops a published buffer ever handing out memory nobody wrote — the failure
- * mode there being a tile of somebody else's heap.
- */
-- (nullable void *)pdfCanvasReserveBytes:(NSUInteger)length;
-
-/**
- * Publish the reserved buffer and return the identifier a caller can redeem it
- * with, or 0 if this sink has no identifier (the heap sink).
- *
- * MUST NOT FAIL. Every reason a publish could be refused — no memory, an
- * identifier already in use — is decided at `reserveBytes:`, before the raster
- * exists. That is deliberate: Android's equivalent can refuse after the copy, and
- * the only thing a caller can do at that point is throw a finished raster away.
- */
-- (int64_t)pdfCanvasPublish;
-
-/**
- * Drop the buffer, published or not. Idempotent.
- *
- * Called on every path that ABANDONS a raster after reserving for it — a
- * cancellation observed after the draw finished, a failure between the draw and
- * the result being built. Without it each one strands a whole raster of native
- * memory that nothing will ever come looking for.
- */
-- (void)pdfCanvasAbandon;
-
-@end
-
-/**
- * The default destination: an `NSMutableData`.
- *
- * `-[NSMutableData dataWithLength:]` is documented to zero its bytes, which is
- * the `pdfCanvasReserveBytes:` contract met for free. `pdfCanvasPublish` returns
- * 0 and `data` is how the bytes are read back — which is what the base64
- * transport, every pixel-reading test, and `PdfCanvasRasterPixels.bytes` use.
- */
-@interface PdfCanvasHeapSink : NSObject <PdfCanvasPixelSink>
-
-/** The reserved buffer, or nil before `pdfCanvasReserveBytes:` / after abandon. */
-@property(nonatomic, readonly, nullable) NSMutableData *data;
-
-@end
-
-NS_ASSUME_NONNULL_END

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

@@ -1,65 +0,0 @@
-#import <Foundation/Foundation.h>
-
-#import "PdfCanvasErrorCode.h"
-
-NS_ASSUME_NONNULL_BEGIN
-
-/**
- * A cheap look at a file before CoreGraphics is asked to parse it.
- *
- * ------------------------------------------------------------------------
- * IT IS NOT A POISON GUARD, AND iOS DOES NOT NEED ONE.
- * ------------------------------------------------------------------------
- *
- * `PdfPreflight.java` exists for a hard reason: on Android API 24 a `PdfRenderer`
- * constructor that THROWS permanently poisons PDFium for the whole process — one
- * failed open plus a garbage collection and the next successful open segfaults in
- * `CPDF_Document`. So on Android, preflight is a correctness mechanism and its
- * scan window is load-bearing (a bug in it once let a 60 KB encrypted file through
- * and cascaded into eight unrelated failures).
- *
- * CoreGraphics has no such behaviour. MEASURED: `CGPDFDocumentCreateWithProvider`
- * over a `%PDF-1.7` header followed by garbage returns NULL — it logs "failed to
- * find start of cross-reference table" under `CG_PDF_VERBOSE` and returns cleanly
- * — and so does an empty buffer, and a subsequent open of a good document
- * succeeds. There is nothing to protect.
- *
- * ------------------------------------------------------------------------
- * WHAT IT IS FOR: TELLING THREE FAILURES APART.
- * ------------------------------------------------------------------------
- *
- * `CGPDFDocumentCreateWithURL` returning NULL is one signal for "no such file",
- * "no permission", "zero bytes" and "not a PDF", and those want four different
- * `PdfErrorCode`s and four different messages. A host showing "corrupt" for a path
- * that simply does not exist sends somebody looking at the wrong thing. So this
- * runs first, answers the questions the file system can answer, and gets out of
- * the way — every judgement CoreGraphics is better at (encryption, structure,
- * page count) is left to it.
- */
-@interface PdfCanvasPreflight : NSObject
-
-/**
- * Returns YES if `url` is worth handing to CoreGraphics.
- *
- * Checks, in order: the path exists, it is a file rather than a directory, it is
- * readable, it is not empty, and its first bytes contain a `%PDF-` header.
- *
- * THE HEADER SCAN IS A WINDOW, not the first five bytes. The spec allows leading
- * junk before `%PDF-` and real files carry it (an HTTP preamble, a shell wrapper),
- * and every reader in existence tolerates it; Acrobat's own limit is 1024 bytes,
- * which is the window used here. A file with no header in that window gets
- * `corrupt` with a message naming what was looked for, rather than CoreGraphics'
- * silence.
- */
-+ (BOOL)checkFileURL:(NSURL *)url
-               error:(NSError *_Nullable *_Nullable)error
-    NS_SWIFT_NAME(check(fileURL:));
-
-/** The same header test, for the in-memory `open` path. */
-+ (BOOL)checkData:(NSData *)data
-            error:(NSError *_Nullable *_Nullable)error
-    NS_SWIFT_NAME(check(_:));
-
-@end
-
-NS_ASSUME_NONNULL_END