Development preview · 0.2.0-preview.1

Affinity certificate exporter: Mac setup and compatibility.

Start with a correct, already-generated Affinity certificate document. Check the version and document requirements, preview the page-to-filename mapping, then inspect the exported PDFs before using them.

The exporter is not publicly available to download or buy. These instructions explain its setup and limits so you can evaluate the proposed workflow. No payment is collected and no release date is promised.

Preview 0.2.0-preview.1 targets unified Affinity 3.3.1.4940 on macOS. It reads a finished merge; it does not create certificates or clean a spreadsheet. Release and verification details are recorded below.

1. Check the exact target.

The runtime checks macOS and a 3.3.x application version; passing that gate is not a claim that every 3.3.x build is supported. The development target remains the exact baseline above. The exporter does not import CSV, perform Data Merge, repair a design, email certificates or verify credentials. If your document does not fit, the free external workflow may suit it better.

2. Prepare the reusable template once.

Need to create the certificate layout first? The free template and Data Merge guide explains connecting genuine name and ID fields before any exporter setup.

Work on a copy of your template. Keep one certificate on each page, with facing pages off, one page per spread and no artboards. Use ordinary page numbering starting at 1, with no custom sections. The preview cannot automatically detect that numbering condition.

Run one export at a time in its dedicated output workspace. Existing-folder and file checks reduce overwrite risk but do not lock out other apps or simultaneous exports. A partial failure keeps the files already written; it does not roll them back.

1. Connect the recipient CSV through Window → Layout → Data Merge. For the supplied example, use fixtures/Batch_A_Recipients.csv.
2. Open Window → References → Fields. Create two separate, unlinked Frame Text objects. Insert the genuine recipient-name field into one and certificate-ID field into the other.
3. In the Layers panel, label the name frame kakulu_name and the ID frame kakulu_id. Use exactly one of each per certificate. Put only the field value inside each frame, without a “Name:” or “ID:” prefix.
4. Save the template, then use Data Merge’s Generate action. Make the new, generated document active before running the script.

These frame conventions belong to Kakulu, not to Data Merge in general. Each certificate needs a unique nonempty ID using the characters above. IDs are compared without letter case, so C001 and c001 cannot identify different certificates. Two people may share a name; their IDs must remain distinct. Use the name-fit checks to review accents and long names in the generated pages.

Use the recipient CSV worksheet for a six-record example and source-preparation checks. The CSV’s column headers and the template’s layer labels are different things: insert your source fields into the frames, then give the frames the exact Kakulu layer labels.

The package’s synthetic example provides a static SVG background, not a prebuilt native Affinity template. Use its exact layout instructions if creating the example from scratch. Do not open the SVG as the final working document.

3. Install once and limit access.

Open START_HERE.html in the package. The script is exporter/Kakulu_Certificate_Exporter.js. Installation is copying that supplied source, not editing it to fit your document.

1. Open Affinity → Settings → Scripting and enable Affinity Scripting.
2. Under filesystem access, allow only the package’s Return_Output folder. This lets the script save diagnostics and PDFs, including new subfolders.
3. Open the JavaScript in a plain-text editor and copy it unchanged. In Window → Scripting → Scripts Library, create a new script and replace its starter contents with the supplied source.
4. In the Script Editor’s settings, enable filesystem access for this script. Keep network access, Canva AI and dynamic code generation off; the exporter does not need them. Save the script in the library for reuse.

Newly pasted scripts and imported packages can have different trust and permission states. Check the actual saved script, not only the global defaults. The exporter uses the open Affinity document; it does not need your whole disk or an MCP server. See the official scripting settings and script trust guidance.

4. Preview before exporting.

1. Keep the generated document active. Run the saved script. Under Action, choose Preview only — no PDFs.
2. Choose an installed PDF preset suitable for digital delivery or your printer’s specification and a Fresh PDF folder name. Keep the same preset when you export.
3. In the file chooser, select Return_Output/SELECT_THIS_FILE.txt. This marker identifies the allowed output folder.
4. Inspect each page, recipient, ID and proposed filename in the mapping. Use Rows to show for additional groups of six, then choose OK to save the reports.
5. Open the new .manifest.html file in Return_Output and compare its full values with the actual Affinity pages. The dialog shortens long names; the manifest retains them.

For Batch A, the first two pages must both show Alex Rivera, with IDs C001 and C002. The remaining IDs are C003 through C006. Check Zoë, José and Sam O’Neill too. The full expected mapping is in the package and the guide’s six-record table.

A matching preview is not proof of PDF contents. This action should write diagnostics, not PDFs. Preserve the full manifest and its script/app versions. If the values do not match, stop before export.

5. Export once, then inspect the files.

1. Run the script again and choose Export named PDFs only after every actual page matches the mapping.
2. Keep the PDF preset, choose a new output subfolder and select the same marker. Inspect the mapping and tick its confirmation before exporting.
3. Open every output PDF in Preview. Each should contain one intended certificate, with its name and ID matching the filename.
4. Check both duplicate-name records, accents, design, cropping and fonts. Retain the diagnostic with the batch.

The preview is designed to refuse existing output folders/files and to stop on the first unconfirmed export, retaining partial output. These guards have local checks; the owner’s successful-use report does not separately verify every failure case. Do not delete a previous result to make a retry fit; choose a new folder name and keep the evidence.

This download is the earlier probe’s verified synthetic output. A script success message, local check or matching filename alone cannot verify a new native export.

6. Reuse the setup; keep failures specific.

Use the next-cohort worked example to keep the old source, new records and delivery folder separate. For a later batch, return to the saved template, update its source records, generate a new document, run the saved exporter, inspect the new mapping, then export into a fresh folder. The intended benefit is reusing the template and script without bespoke repairs. The owner reported successful use, but customer repeat-use reliability and time savings have not been established.

The supplied Batch B changes all six names and IDs while keeping the same template fields. It is a diagnostic fixture, not evidence that repeat use has passed. Changing a normal recipient batch should not require source-code edits.

If the values are wrong before the exporter runs, use the source, merge and export troubleshooting guide. For finished output, use the filename-to-content and delivery checklist. The table below covers Kakulu-specific messages.

After the output marker is selected, the preview is designed to save a local full manifest and a redacted support report. Preview reports go in Return_Output; export reports go inside the new PDF folder. Nothing is sent anywhere. The full manifest can contain names, certificate IDs and local paths. Inspect any diagnostic before sharing it; use the redacted report first and synthetic data for the private experiment.

If these checks do not explain a failure, keep the exact error and diagnostic instead of modifying the script. The package includes a console fallback for cases where a file cannot be saved.

Which version has which evidence?

• Original probe v2.0.0: six Batch A PDFs independently verified after native export on Affinity 3.3.1.4940/macOS.
• Reusable exporter 0.1.0: historical local checks only; its original package was not recovered.
• Reconstructed 0.2.0-preview.1: a separate preview built from recovered source, with local checks and owner-reported successful use on 22 October 2026. It has no additional independently inspected native output. Repeated customer use and broader compatibility remain unverified.

Neither the owner’s report, local checks nor the earlier native sample establish customer demand, human time savings or willingness to pay.

Documentation sources

Kakulu · updated 23 October 2026. Affinity Help Center articles are undated; indexed official text was used where their rendered body was unavailable. These instructions combine that documentation with the recovered probe’s workflow and current preview contract. The owner’s reported successful use is recorded separately from the independent evidence.

1. Affinity — Desktop settings: Scripting — checked 22 October 2026.
2. Affinity — Trusting scripts — checked 22 October 2026.
3. Affinity — Running scripts — checked 20 October 2026.
4. Affinity — Data Merge panel — checked 22 October 2026.
5. Affinity — Fields panel — checked 20 October 2026.
6. Affinity SDK 3.3.0 beta — checked 21 October 2026.