What a print shop actually checks before it prints your file

Fonts — the check that fails most often

If a font is not embedded in the file, the printer cannot print what you designed. They can only print what they have. Their machine carries its own fonts, and a missing one gets substituted — usually by something with a similar name and different letter widths, which reflows every line of text while the layout around it stays exactly where you put it.

Four situations turn up in practice, and only one of them is genuinely safe.

• Embedded and subsetted — safe. Only the glyphs actually used are stored. This is both smaller and entirely sufficient.
• Embedded in full — safe but wasteful. Occasionally several megabytes of glyphs nobody will ever render.
• Not embedded, but one of the fourteen standard faces every reader must supply — technically legal. This is the trap that catches people. Readers substitute these smoothly, so the file looks perfect on your screen, and a printer can still refuse it because there is no way to know which version of Helvetica you meant.
• Not embedded and not a standard face — the file is broken. Your viewer has been quietly borrowing a stand-in, and what you have been looking at is not what would print.

There are two ways out. Embedding the fonts is the correct fix and needs the application that made the file. Outlining the text — turning every glyph into filled vector shapes — is the fallback that always works, because drawings do not need fonts installed on the other machine. The trade-off is that the text is no longer text: it cannot be edited, searched, or read aloud by a screen reader afterwards. That is why shops ask for it on final artwork and never on a working file.

Outlining is a one-way operation. Keep the editable original and treat the outlined file as a separate artefact for the printer, exactly as you would keep a project file alongside an exported PDF. The text-to-outlines tool does this locally.

Colour — RGB is a screen space, and a press is not a screen

A press does not have red, green and blue ink. It has cyan, magenta, yellow and black, and every colour in your file has to be expressed as quantities of those four. Some RGB colours do not exist in ink at all: a saturated screen blue or a vivid green sits outside what CMYK can reproduce, and when it is converted, something has to give.

• An RGB file gets converted by the printer, using whatever profile and rendering intent their workflow specifies. You have no say in the result, and no chance to see it before it is on paper.
• A CMYK file arrives already converted, so what you saw in your design application is much closer to what comes out.
• Spot colours are separate inks rather than process colours. Leaving them in place is a deliberate choice and should be flagged to the printer; converting them silently is a decision that should be made on purpose.

Nothing on this site converts colour space, and no browser tool does it properly — the conversion needs a colour management engine and a profile for the specific press and paper. If your file is RGB and it is going to a printer, the right move is to convert it in a design application before sending, or to ask the printer to convert it and to accept their proof.

Resolution is not the number in the file — it is the number after scaling

An image has a pixel count. What a printer cares about is its effective resolution: the pixels available per inch of printed page. Place a 300 dpi image at the size it was scanned at and you have 300 effective dpi. Scale that image to double size on the page and you have 150, because the same pixels are now spread across twice the width. This is the most common resolution error in submitted artwork, and it cannot be spotted from the file properties — only from the placed size.

The test is arithmetic, not guesswork: divide the image pixel width by the width it occupies on the page. Below 300, that image is contributing less than it could.

Bleed, and the four rectangles that make a page

A PDF page is not one rectangle. It is up to five, nested, and each one means something different to a printing workflow. Most people have never seen them, and this is where artwork files quietly go wrong.

• MediaBox — the physical sheet, including any area the printer cannot reach.
• CropBox — what a viewer or an office printer should show. This is the one most PDF tools, including ours, change when you crop.
• BleedBox — how far artwork extends past the trim, so that cutting tolerance does not leave a white sliver at the edge of the sheet.
• TrimBox — the finished size of the page after cutting. This is the rectangle the printer actually works to.
• ArtBox — an optional rectangle for placing the page inside a larger layout. Rarely used, occasionally the cause of confusing output.

Bleed is what most supplied files get wrong. If a design has a colour that runs to the edge of the page, that colour has to extend about 3 mm past the trim on every side so the guillotine has something to cut through. A file whose artwork ends exactly at the page edge has no bleed, and after trimming every sheet can show a hairline of bare paper at one edge. That is not a printer error — it is a file error, and it cannot be fixed downstream.

There is a practical consequence for cropping. Cropping a file in a browser changes the visible area, and on an artwork file that almost certainly breaks the relationship between the crop box and the trim box. Crop proofs, internal documents and scanned paperwork freely. Do not crop a file that is headed for a commercial press unless you know the page geometry is already wrong and you are rebuilding it deliberately.

Transparency, flattening, and what PDF/X is really asking for

Transparency is normal in a design application and awkward for a RIP, which has to flatten overlapping transparent objects into something a press can render. Flattening is a real conversion with real consequences: it can rasterise vector art, change overprint behaviour, and shift the colour of anything that was subtly transparent.

This is why print workflows ask for PDF/X. It is a family of constrained subsets of PDF, designed so that a file is unambiguous. PDF/X-1a requires everything in CMYK or spot colour, all fonts embedded, and no live transparency, because it must be flat. PDF/X-4 permits live transparency but requires an output intent naming the colour profile the file assumes. When a printer asks for PDF/X, they are asking you to remove ambiguity, not to change your design.

A browser cannot export PDF/X, and a tool offering one-click PDF/X conversion deserves scepticism. What you can do locally is the part that matters most: embed or outline the fonts, keep the text as vector, and send the file at the right resolution in the right page geometry.

Sending a file the printer will not have to ask about

• Ask for their specification before you export. Every shop has one and it is usually a single page: page size, bleed, colour space, minimum resolution, whether they want PDF/X.
• Export text as vector, never as a picture. A screenshot of a document is the most common reason a file described as print-ready comes straight back.
• Check the smallest text and the thinnest line. Reversed-out text below roughly 6 pt and hairlines below about 0.25 pt tend to fill in on press.
• Keep the pages in one document unless you have been asked for separate files.
• Send a low-resolution proof alongside the print file, and say clearly which one is which.
• If a font cannot be embedded because the original application is gone, outline the text — and keep an editable copy for yourself, because the outlined version is final.

Most preflight failures are not design failures. They are the gap between what a screen shows and what a press can do, and nearly all of them are visible in advance if you know which six things to look at.