Parsing Spatial Data

The Fork PDF engine generates a binary Protobuf file (data.pb) containing exact layout mappings. The way you access this data depends on whether you are running a server-side validation test or parsing a downloaded bundle locally.

Server-Side (Test Cases)

When writing a testCase validation script to validate spatial constraints during generation, you only have CommonJS available. However, you do not need to initialize or load the data.pb file manually. The engine pre-initializes the spatial document and injects it directly into your script as the doc object. Note: The injected doc object has its pierceShadowDOM configuration strictly locked to false, meaning your server-side queries will always ignore Shadow DOM elements.

// Inside your generate() testCase string:
// The 'doc' object is already initialized for you.
const title = doc.querySelector('h1');

if (!title) {
    return { success: false, reason: "Missing title" };
}
return { success: true };

Client-Side (Local SDK)

When you set spatial: true during generation, you receive a local ZIP bundle or in-memory buffers (when using unzip: true). You can use the SDK's SpatialDocument class to decode the spatial protobuf data into a queryable DOM tree by providing either a local file path string or an in-memory Buffer directly.

const { SpatialDocument } = require('forkpdf');

const doc = new SpatialDocument();

// Option A: Load directly from a file path
await doc.load('./output/data.pb', { pierceShadowDOM: true });

// Option B: Load directly from an in-memory Buffer (e.g., from client.generate with unzip: true)
await doc.load(response.binaryBuffer, { pierceShadowDOM: true });

import { SpatialDocument } from 'forkpdf';

const doc = new SpatialDocument();

// Option A: Load directly from a file path
await doc.load('./output/data.pb', { pierceShadowDOM: false });

// Option B: Load directly from an in-memory Buffer
await doc.load(response.binaryBuffer as Buffer, { pierceShadowDOM: false });