From Browser Canvas to Fabrication File

DTF transfer printing works by ganging many pieces of artwork onto one long printable sheet. Before this system, wholesale customers ordered gangsheets the manual way: email artwork to a sales rep, wait for a layout, review it, request changes, repeat. Every round trip cost a day, and the layout work landed on staff who had better things to do than nudge rectangles.

The gangsheet builder makes that self-service. Customers upload artwork, size and duplicate it, and watch it pack onto a sheet that grows as they add more, with pricing updating live. When they submit, the system produces the actual fabrication file the press prints from, without a human in the loop.

Under the hood this is really two very different systems bolted together: an interactive geometry problem in the browser, and an industrial-scale image generation problem after submit. At print resolution, a full sheet measures in the hundreds of megapixels. The engineering story is about keeping those two halves honest with each other.

• The layout must feel instant; the print file cannot be. Packing feedback and pricing have to update as the customer works, which puts the layout math in the browser. The fabrication file, hundreds of megapixels of it, cannot be built there, and it cannot be built on the legacy business system either. It needs its own compute.
• Orders live on the legacy platform. Order records, pricing rules, and fulfillment stay on the IBM i system of record. The compositing service is deliberately dumb about commerce: it takes placements in, hands a file back.
• Customers are not prepress operators. Low resolution uploads, artwork straddling a physical page break, previews mistaken for artwork: all of it will happen. The system needs guardrails that catch bad input before a press wastes film on it.
• Artwork arrives in mixed formats. Some customers upload crisp vector files, others upload photos. The print file should preserve vector quality when it exists rather than flattening everything to pixels.

The compositor is on its third design, and the first two are what taught the constraints.

Generation one: rasterize the whole sheet in one buffer. Composite every placement into a single giant image, then hand it to the press. Simple, and it works right up until sheets get long. A single buffer at print resolution collides with the memory and pixel ceilings of every mainstream imaging library, and the failure mode is an out-of-memory error on exactly the largest, most valuable orders.

Generation two: composite in strips, then join. Slice the sheet into fixed-height horizontal strips, composite each strip under the pixel ceiling, and join the strips into the final image. This bounds memory and genuinely scales, but it doubles down on raster: vector artwork gets flattened to pixels no matter how clean it was, intermediate files are enormous, and the join step is one more place for a multi-gigabyte job to fail.

Generation three: build the print file vector-first. The chosen design assembles the fabrication file as a paged document instead of one image. Vector artwork is embedded natively, so it stays vector all the way to the press. Raster artwork is placed at its target size. Only when a vector source fails conversion does the system fall back to rasterizing it through the image CDN. Memory stays proportional to the artwork, not to the sheet, and quality is bounded by the customer's file rather than by an intermediate bitmap.

In the browser, the sheet is a rectangle bin packing problem solved live: placements are scored with and without rotation, free space is split and tracked as artwork lands, and when nothing fits the sheet grows taller in 12-inch increments, with pricing refreshing as the layout changes. Guardrails run at the same layer: low-DPI and dimension warnings flag weak artwork, page-break validation stops placements from straddling physical page boundaries, and sheet previews and finished print files are blocked from re-entering the canvas as artwork, which is exactly the kind of mistake a reorder screen invites. A manual background removal editor feeds its edited output back into the same selected-artwork pipeline as uploads.

At submit, the browser captures a placement snapshot: the final layout redrawn with no editor decoration, expressed in print-resolution coordinates. That snapshot, not the pretty preview, is the contract with the compositor. The order and its serialized layout persist to the business system; drafts survive long sessions in browser storage. Small jobs composite synchronously, while large ones queue behind a background worker that polls for completion. The job can start before the order record exists, so linking is handled in both directions: whichever of the print file and the order lands first, they find each other. The compositor re-validates page-break rules server-side rather than trusting the browser, fetches each unique artwork once per job, and writes the finished multi-page file to storage.

Reorders close the loop. When a customer reorders a sheet and the layout has not changed, the system detects it and reuses the existing print file instead of regenerating it, which turns the most common repeat purchase into the cheapest possible operation.

Wholesale buyers now lay out and submit gangsheet orders end to end on their own, and the fabrication handoff that used to be manual coordination between sales and the shop floor is a file that appears where production expects it. Repeat buyers get faster turnaround through print-file reuse, and the DPI, dimension, and page-break guardrails catch bad artwork before compositing runs, not after film is wasted.

The honest tradeoffs: compositing currently shares its compute with a general-purpose API service and holds work open for the duration of a job. That is acceptable at current volume and is the known ceiling; the durable version of this system puts the compositor behind a queue on dedicated workers, where a burst of giant sheets cannot crowd anything else. The vector fallback is the other soft spot: when a vector file fails conversion, the sheet still prints, but from a rasterized copy, and today the customer is not told. Failing loudly there, and versioning print files explicitly instead of implicitly, are both on the do-differently list.

The larger lesson mirrors the compositor's own history: twice, "how do we generate a several-hundred-megapixel file" forced a redesign. The third design survives because it stopped fighting the size problem with bigger buffers and changed the representation instead. When a system keeps failing at scale, the fix is usually not more memory; it is a different shape.