Print File Handling

print file handling — api reference for external integrators overview purple dam supports print ready file variants (psd, tiff, ai, eps, indd) alongside standard web images, and additionally keeps the full resolution original of standard web images (jpeg, png, gif, webp) that exceed the online downscaling threshold editors can upload these files directly or attach them to existing online images only psd and tiff files are automatically converted into a web friendly image (webp, with jpeg fallback) for use in online articles; other print formats (ai, eps, indd) cannot be converted and use a placeholder as the online image instead standard web images need no conversion at all the downscaled copy goes online and the original upload becomes the print variant in all cases, the original file is preserved and exposed via the rest api as a separate variant this document describes the resulting api field and how a client (e g an indesign plugin) should consume it this entire feature is behind a feature toggle it only exists on a given hub if explicitly enabled for that hub; where it is not enabled, the api and media behavior are unchanged from today, and the print image field will not appear at all background print formats such as psd/tiff were previously classified with generic mime types (e g application/octet stream) and treated as media type "file" rather than images, making them undiscoverable through image specific queries the new print image field solves this by exposing print files with their correct, format specific mime type (e g image/vnd adobe photoshop) through the standard image endpoint — no separate endpoint or mime type workaround required endpoint no new endpoint is introduced the print variant is exposed as an additional field on the standard wordpress media endpoint get /wp json/wp/v2/media/{id} example curl https //example com/wp json/wp/v2/media/41 api field print image every image object returned by the rest api now includes a print image object in addition to the existing online file data (webp/png/jpeg, etc ) the field is only populated when print image handling is enabled on the dam side (settings → purple dam → filters → enable print images) if the feature is disabled, media responses are unchanged from today's behavior field type description exists boolean whether a print variant is attached to this image id integer id of the print file present only when exists is true url string download url of the original print file present only when exists is true mime type string correct mime type of the print file, e g image/vnd adobe photoshop present only when exists is true filename string original filename of the print file present only when exists is true filesize integer file size in bytes present only when exists is true example image with a print variant "print image" { "exists" true, "id" 46, "url" "http //example com/uploads/datei psd", "mime type" "image/vnd adobe photoshop", "filename" "datei psd", "filesize" 1926287 } example image without a print variant "print image" { "exists" false } required client behavior when placing an image, the client should check whether print image exists is true if true, download and place the file at print image url, using print image mime type to handle the format correctly if false, fall back to the standard online image file as before — no change in behavior needed no changes to the existing online image workflow are required beyond this check supported print formats currently psd, tiff, ai, eps, indd — each returned with its correct native mime type (e g image/vnd adobe photoshop for psd) standard web image formats (jpeg, png, gif, webp) also get print file handling when such an image is uploaded above the resolution threshold used for online downscaling (default 2560px), a downscaled version is created for online use, and the original high resolution upload becomes its print image — the same mechanism already used for psd/tiff in that case print image mime type is a standard image type (e g image/jpeg) rather than a print specific one, so clients must not infer the format from a fixed list of print extensions always read print image mime type manually attached image print versions an image format can also be attached as a print variant by hand such a print version is not required to exceed the resolution threshold, and it may show something other than the online image it is attached to upload path (for reference) print files can reach the dam in three ways attached to an existing web image via the media library (recommended workflow) uploaded directly (e g a print file sent from indesign via a plugin) for psd and tiff, the dam automatically converts the file to a web image (webp, jpeg fallback, max 1920 px on the longest side, 85% quality — less if the hub's resolution limit is set below 1920 px) and attaches the original as its print image if conversion fails, the upload fails with an explicit error rather than producing an empty or broken image — clients should surface that error rather than retry silently for formats that cannot be converted (ai, eps, indd), a placeholder is used as the online image and the original file is attached as print image derived automatically from an oversized upload of a standard web image (jpeg, png, gif, webp) no conversion is involved the downscaled copy becomes the online image, and the untouched original becomes its print image upload size limit up to 100 mb per print file this ceiling applies to print formats regardless of the per file type upload limit configured for the hub, and is enforced in the media library upload, the print version upload and the client side pre check alike notes automatic conversion to a web image (webp, max 1920 px, 85% quality, jpeg fallback) only happens for psd and tiff other print formats (ai, eps, indd) use a placeholder as the online image, since they cannot be converted print files are never exposed as browser renderable images, so there is no risk of them being inserted directly into online articles this also holds for a print variant that is itself a jpeg or png print attachments are excluded from media library queries, so they cannot be picked or inserted as an online image the media library additionally offers filtering by print variant status (all / with print variant / without print variant) and visual indicators for images with print variants, though this is editor facing and not part of the api contract the whole feature is gated behind a toggle per hub installation, so integrators should always check print image exists rather than assuming the field is present status & outlook the print image field is live in the current purple dam plugin and deployed to dev/staging and demo environments for integration testing the underlying implementation is expected to evolve in a future purple dam version the print image field contract described here is intended to remain stable across that migration, but integrators should expect a follow up notice if anything changes a planned improvement will keep an image mime type on the underlying psd/tiff asset itself (instead of it flipping to a generic "file" type), so uploaded and transformed assets stay linked as the same object print file handling for standard image formats that exceed the online downscaling threshold is live where exif/iptc metadata is read from and written to for such an image pair is still being finalised, so integrators should not yet rely on metadata being present on one specific file of the pair please confirm whether the described print image check can be implemented on your side, and flag any concerns before general rollout