Print files

A print is a one-time production unit made from an approved design: the print-ready file and a job ticket that says what to make and how to cut it. The studio calls a print a print file and lists them under Print files, newest first; a design’s page lists its own, each with its orders.

Only an approved design can be printed. See Designs.

Making a print

Your server prints an approved design with its secret key (a connected store, with its integration key). In the studio, Create print file on an approved design’s page, or New print file under Print files, does the same; it takes the prints:create permission, which only admins hold unless a custom role grants it.

A print is rendered at the size the design was committed at, so creating one asks for no size. Creating one places no order: a print is sent to a printshop only when you order it.

A print does not say how many copies to make, nor whose order it is for. Those are each order’s — its quantity and your reference — so one print can be ordered any number of times, each order with its own, without rendering again. A request that still sends a quantity or a reference with the print is refused and names where it now goes.

Approving a design does not print it: a print is made only when your server or someone in your workspace asks for one.

A print is created at once and renders afterwards: your server’s request is answered as soon as the print is reserved, and in the studio the print file opens straight away and shows it rendering until it is done. A print’s status in the studio is one of:

• Rendering — the print has been started and is rendering.
• Ready — its files are ready.
• Failed — it could not be rendered, and says why and whether the design is at fault. A print renders until it is done; a render that fails for a reason of ours, or that is still running half an hour after it began, is tried once more, and fails the print only if it fails again.

A failed print can be rendered again in place, under the same id and from the design revision it was made from: submitting again an order that failed with it does so (see Orders). Each try at its render is kept on the print, in GET /v1/prints/{id}’s attempts: when it ran, how it ended and why it failed, so a failed try stays visible after a later one succeeds.

When many prints are waiting to render, a Pro or Business workspace’s go first. A Free or Starter workspace’s print still renders after a short, bounded wait, however many of theirs keep arriving.

Each of these is also reported to your webhook endpoints. See the webhooks guide.

Getting a print’s files

Making a print is free and counts nothing. Its files leaving Pixonaut without an order count as an order, the first time only: the first Get print files in the studio, which downloads every file of the print as one zip, or the first fetch through the API, with any key, of GET /v1/prints/{id}/file or GET /v1/prints/{id}/bundle (the same zip: every file as stored, and the files for any machine profile or output settings you add). Getting them again, adding files for another machine profile or settings, and retries are free. The studio asks before the first time, and a print that has been counted says when and by whom.

A print you have ordered through Pixonaut counts nothing when you get its files afterwards, and the files an order hands out (to its printshop, on its job page, through /v1/orders/{id}/job/files) count nothing either. A print whose files you got and then order counts once more, for the order. Nor do the print files in a workspace export, which takes every print’s files out with the rest of the workspace’s data.

Past the orders your plan includes this month, getting a print’s files is refused rather than held: on Free with 403 plan_limit_reached and limit: "orders"; on a paid plan it uses one order from your order balance, and is refused with 403 order_balance_empty while the balance is empty.

Making prints has a fair-use limit of its own, on prints made without an order each month: 250 on Free, 2,500 on Starter, 10,000 on Pro and 40,000 on Business. Past it, POST /v1/prints is refused with 403 plan_limit_reached and limit: "printsMadePerMonth". A sandbox’s prints count toward its live workspace’s, and a sandbox has smaller caps of its own (see Test with a sandbox).

The preview

GET /v1/prints/{id}/preview is a PNG for a screen, not for press: its long edge is the print’s long edge, bleed included, at 150 DPI, never below 1200 px nor above 1920 px. A 50 mm sticker is 1200 px, A4 1754 px, A3 and larger 1920 px.

The print file

The print file is a PDF made for press: in CMYK with an ICC profile, at a stated resolution, including bleed so that ink runs past the cut line. It is rendered at the print size the design was committed at.

The CMYK is converted through the output profile of the machine the order prints on: ISO Coated v2 (FOGRA39) unless the machine picks another, such as GRACoL 2013 or a CMYK output profile the workspace uploaded for its own press. The job ticket names the profile the file went through.

A printshop reaches the file through a link that expires. It is a different link from a proof’s: a proof link is for customers, a print file link is for the printshop, and neither can fetch the other.

Flat, layered or live text

A print file is flat by default: every layer drawn into one picture and every letter as a shape. A layered print file keeps each printed layer as its own optional content group, named by the layer, so a printshop can switch a background or a white underbase off in Acrobat or Illustrator, its letters still shapes. Layered with live text makes plain text live as well, which can be selected, searched and corrected. A layer left out of print is absent from all three.

The form is chosen at three levels, the most specific winning: the workspace’s setting (in the settings’ Printing and proofs card, flat by default), a connected store’s, and a template’s (in its Output section). Each of the narrower two follows the one above it until it is set. The print records the form it was made in when it is reserved.

Unedited, a layered file prints exactly as the flat one. Live text prints as the flat one outside text, and within the print’s text tolerance at text edges: how far from its outline it may lie, entered in pixels or millimetres and chosen at the same three levels, one device pixel by default. Ghostscript draws large glyphs a little short of their outlines, so large text may need more; the tolerance field has a comparison of a word at your size, drawn both ways. Every file that keeps layers is checked against the flat one before it is handed out, and the print says how far its live text measured (textDeviationPx, textDeviationMm). A file in live text that differs by more, or cannot be made, is made layered, and one that fails too is flat, the print saying why (liveTextFallback, layeredFallback). After an edit to the file, nothing is guaranteed.

Some text stays shapes even with live text on: a gradient fill; an outline or a shadow; text on a curve; a character no font has; a font whose licence forbids embedding, one with PostScript outlines, or one not held whole; every copy after the first of text drawn more than once (the bleed’s mirror, a scatter); and text inside a repeat’s tile.

A print’s file can also be had in another form: from the print’s page, or with form=flat, form=layered or form=layered_live_text on GET /v1/prints/{id}/file and /v1/prints/{id}/files. It is made from the same print on its first get, which takes a few seconds, and kept. A form that keeps layers and cannot be made is refused with 422 print_not_layered and the reason, never served as another in its place. Making it failing this time, which says nothing of the next, answers 503 print_form_failed, to ask again. Getting it counts as getting the print’s files.

The job ticket

The job ticket travels with the print file to the printshop. The ticket a printshop is handed is built for each order, so it holds:

• the order’s reference and quantity, and who it is for and where it ships when the order says;
• the artwork — which template version it came from;
• the print area — width, height and bleed in millimetres, and the cut shape, the outline the finisher cuts to;
• the file — its format, colour space, ICC profile, resolution, whether it includes bleed, and any spot colours;
• a record of exactly what produced the file, so the same print can be traced later.

Cut to the print area on the ticket: it is the geometry the file was rendered against.

Any order details your shop attached to the design are handed on with the order too.

One print, several orders

A print is the thing rendered; an order is one attempt to have it made. If a printshop turns an order down, the same print can be ordered again without rendering it again.

A standing design’s orders share its print

Nothing about an order changes the pixels, so an order of a standing design reuses the print of its current version, ready or still rendering, and makes a new one only when there is none or the last one failed. A correction makes a new version, whose next order makes one new print. A customer’s design ordered by naming it gets a print of its own for each order.

Related

• Orders
• Design to order