Daniel sent us this one — he works with digital printers here in Jerusalem, he's on Linux, not a graphic designer, and printers keep asking him for PDFs. His question is basically: why PDF? What makes it the universal language of print, especially when most people think of it as a final document format, not a production format? And then the deeper layer — once you're sending that PDF, there's all this invisible metadata around color, fonts, bleed, and resolution that determines whether your file actually prints properly or comes back looking like a laundered receipt. Large-format stuff especially. Let's start with the question that's been bugging him — why PDF? What makes it the universal language of print?
The short answer is that PDF isn't actually a format the way most people think about formats. It's a container. The specification — ISO 32000 — covers both vector and raster content inside the same file. So you can have a PDF that's a hundred percent vector geometry, a hundred percent embedded photographs, or any hybrid you want. When you send a printer a PDF, you're basically handing them a shipping container that they can inspect before unpacking. That's the fundamental thing most people miss. They hear "PDF" and think it's like a PNG but fancier. It's really an envelope with a manifest attached.
The TIFF or the PNG is the cargo loose on the dock, and the PDF is the sealed container with paperwork.
And that paperwork matters. A PDF has objects inside it — fonts, images, color profiles, page geometry, a rendering model that tells the software how to interpret all of it. That's why printers won. Back in the nineties and early two thousands, the industry fought a format war. EPS files, native Adobe Illustrator and InDesign dumps, TIFF workflows, QuarkXPress, CorelDRAW — every shop had its own stack. And predicting whether a file from one workflow would crash someone else's RIP was basically palm reading. PDF solved that because the specification includes predictable rendering: you can verify, before committing ink to expensive coated stock, that what you see in preflight is what you'll get on press.
I want to pause on that preflight word, because I think it's one of those terms that sounds like airline procedure but actually describes something very concrete. What does a preflight check actually look at inside a PDF?
Preflight software — and this is built into Acrobat Pro, into dedicated tools like PitStop, into the RIP itself sometimes — walks through every object in that container and asks a checklist of questions. Are all the fonts present and embedded, or at least accounted for? Do the images meet a minimum effective resolution threshold? Are there any RGB objects that should be CMYK? Is the page geometry correct with the bleed box defined? Does the total ink coverage in any area exceed what the paper stock can handle? That last one is subtle — if you lay down four hundred percent ink coverage because you stacked cyan, magenta, yellow, and black all at a hundred percent, the paper literally can't absorb it. It turns into a soggy mess on press. Preflight catches that before you're standing next to a pallet of ruined five-thousand-sheet runs.
It's like a building inspector walking through before anyone moves in, rather than discovering the staircase doesn't connect to the second floor when you're already carrying furniture up it.
And the preflight report is what the printer is reading when they email you back saying "we found seventeen issues with your file." They're not being difficult. They're reading the inspector's clipboard.
Tell me about the RIP, because I've heard printers use that term and it sounds like they're talking about something that happens after a tragic industrial accident.
Raster Image Processor. The RIP is the piece of software — or sometimes a dedicated hardware box — that takes your PDF and converts every object in it into the actual dots of ink or toner that the print engine can lay down. This is where things go wrong if your PDF isn't properly constructed. The RIP looks at your file and asks: what color profile am I working with? Are these fonts in the bag? Where is the ink supposed to stop? What's the resolution? If the PDF answers all those questions cleanly, the RIP produces a corrected final dot map and your banner looks right. If the PDF is silent on any of them, the RIP guesses. And guess who pays when the guess is wrong?
You do, standing there with a roll-up banner that makes your conference booth look like a bootleg DVD menu.
Here's the irony for the Linux user who sent this prompt. A lot of small print shops — including plenty here in Jerusalem — actually run their RIP software on Linux. Caldera, ONYX, and specialty RIP boxes often use Linux under the hood. So the person who denied your PNG is staring at a Linux terminal right now. It's not a platform snub, it's a pipeline requirement. They need that container metadata. A raster file on its own doesn't answer the questions.
Which makes Daniel's situation almost poetic. He's on Linux. The printer's RIP is on Linux. They should be best friends, but the PNG is standing between them like a bad translator at a diplomatic summit.
The PNG is handing over a single photograph of the cargo and saying "figure it out." The RIP needs the manifest.
We've established that a PDF is a mailbox, not a photograph. Now step back and walk me through something more basic, because the prompt specifically asks about DPI and resolution, especially for large-format prints. What actually matters?
Alright, let's untangle three letters that graphic designers and print shops love to use interchangeably even though they aren't. DPI: dots per inch. PPI: pixels per inch. LPI: lines per inch. DPI describes the print device's output — how many physical ink dots the machine can physically spray or fuse in a linear inch. PPI describes your source image — how many pixels you packed into each inch of the original file. LPI is the halftone screen frequency, which is basically how many rows of halftone dots you're laying down per inch in offset printing. They're three different stages in the chain. Most people memorize "three hundred" and never question where the number comes from.
The fact that every print tutorial says "three hundred DPI for print" like it was delivered from a mountaintop on stone tablets. But if DPI and PPI are different things, which one is the three hundred referring to?
They mean PPI, and they're using the wrong term while they say it. The three hundred refers to pixels per inch in your source file. The actual DPI of the output device is usually much higher — a typical digital press might be two thousand four hundred DPI, but each of those dots is a single color droplet. It takes many dots clustered together to reproduce one pixel of your image. So the device resolution and your file resolution operate at completely different scales. When someone says "save at three hundred DPI," what they should be saying is "make sure your image has three hundred pixels for every inch of the final printed size.
That distinction alone would prevent a lot of heartbreak. Someone hears "three hundred DPI" and resamples their two-thousand-pixel-wide image to three hundred dots per inch in software, and the software just changes a metadata tag without adding any actual pixels, and now the printer thinks it's receiving a postage stamp.
That's the classic metadata-resample confusion. Changing the number in the file header doesn't invent new image data. If you started with two thousand pixels across and you need seventy-nine inches of banner, you've got about twenty-five pixels per inch. Tagging it as three hundred in the file properties doesn't summon the missing seventy-five pixels per inch out of the ether. The RIP does the math and the math is unforgiving.
Here's where that number came from. You mentioned it traces back to offset printing and human vision.
For offset printing on glossy coated paper at standard reading distance — call it roughly thirty centimeters from your eyeballs — the human eye stops resolving individual halftone dots at around one hundred fifty lines per inch. The rule of thumb is that to avoid aliasing artifacts you double the LPI to get your PPI. One-fifty times two gives you three hundred. That's the whole origin of three hundred PPI for print. It's reading distance, one-fifty line screen, Nyquist-ish doubling, done.
What happens when reading distance stops being thirty centimeters? Say I'm printing a two-meter roll-up banner that people will see from across the conference hall, or a billboard viewed from ten meters away on a highway?
Then the PPI requirement drops through the floor, and this is what most people designing for large-format get wrong. The math goes like this. Human visual acuity is measured in cycles per degree — how much detail your eye can resolve at a given viewing angle. At ten meters, a "retina display" equivalent requires maybe twenty PPI. At two meters for a conference banner, a hundred fifty PPI is already overkill — the print shop will probably recommend one hundred PPI and nobody will notice. The physical ink resolution of most modern large-format inkjet printers sits in the seven hundred to two thousand four hundred DPI range, but that's dot density for color blending — not what your source file needs.
All those people fussing over whether their traveling banner is three hundred PPI are just committing computation.
The real tragedy is that resolution actually means doing math nobody does. Let's take a two-meter-wide banner. That's about seventy-nine inches across. At a hundred fifty PPI — already luxurious for viewing at arm's length at a show — that's about eleven thousand eight hundred pixels wide. At seventy-nine inches tall, that's another nearly six thousand pixels. Talk to anyone who has been given a grab from a website header that's two thousand pixels wide and asked to blow it up to five times across. Diagonal visible resolution on that banner works out to roughly...
Let me stop you before you use the word diagonal on a podcast. What'll it yield?
Roughly seventy megapixels. Virtually no one brings a file that big and most people are shocked when you tell them the number.
Like realizing you've been asked to furnish a room with furniture you don't own in a house you haven't built.
Hence the awkward conversation standing at the print shop counter. And here's the practical takeaway for Daniel on Linux. If you're designing a large-format piece and your source image is only a few thousand pixels wide, don't panic and upscale it in GIMP or ImageMagick and hope nobody notices. That just invents blur. Instead, think about viewing distance honestly. If your banner is going to be seen from three meters away at a trade show, you can get away with sixty to eighty PPI. Do the math: width in inches multiplied by your target PPI. That's the pixel dimensions you need. If you don't have them, either redesign with vector elements that scale infinitely, or have a frank conversation with the client about what their logo JPEG from 2007 can realistically do.
Let's talk about color because the prompt called this out specifically, and if there is one thing that will make marginalia of your nice project, it's ignoring color metadata. Why does an sRGB PDF come back looking flat and washed out, or worse, mustard-toned in the whites?
Alright, so we have to talk about gamuts — the total set of colors a given color space can represent. sRGB, which is the default color space for most consumer applications and virtually all Linux desktop toolkits, was designed in the late nineties by HP and Microsoft. It mapped the color capabilities of an average CRT monitor. The monitors were the target. This is important — every professional monitor since has been larger. The sRGB gamut is the spatial equivalent of a studio apartment. Adobe RGB adds about fifty percent more coverage in the cyan-greens, but it's still an RGB color space working with additive light. Print is subtractive — CMYK is putting cyan, magenta, yellow, and black ink onto paper that absorbs ambient light.
Mapping sRGB directly into ink is a game of telephone ending in mud.
The telephone translation happens inside the RIP. If you send a PDF that is tagged sRGB — or even worse, completely untagged, which is the default in nine out of ten quick-export workflows — the printer has no output intent. The RIP goes, well, someone has to take a stand, and it guesses based on whatever default profile the print shop configured. Most of the time that default is a CMYK press profile developed by FOGRA, the German graphic arts research institute, or something like GRACoL2006 used in North American commercial printing. The destination gamut is not just smaller than sRGB — it's shaped differently. The really punchy greens and electric blues on your screen have no analog in commercial CMYK. The RIP's color management module has to compress all those out-of-gamut colors into something reproducible, and that compression is happening blind. You didn't tell it how.
Which brings us to that infamous discovery when the bright college blue on a nonprofit's logo returns from the printer looking suspiciously like municipal sewer department teal.
That is a color space translation failure and it spikes when you work in applications that produce PNG in an sRGB default — so basically GIMP if you never changed the defaults. The PNG has no concept of CMYK. Convert it into a PDF wrapper with a magic incantation, e.using LibreOffice or ImageMagick, and the color tag inside the resulting PDF is still going to be sRGB. The printer's RIP processes what it receives, not what you intended. Professionals work in a target CMYK profile from the beginning. For commercial sheetfed offset here, that's frequently FOGRA thirty-nine. For large-format rollups on coated vinyl, many shops here accept sRGB tagged PDFs but maintain an ICC substitution pipeline inside their workflow that applies an aggressive cyan-green shift of less than two percent — well, the engineering limits on that lane.
There's the phrase "substitution pipeline" getting a truly disproportionate emotional response from me. We stow that. But let me ask a practical follow-up here. If you're on Linux, and you're not running Adobe Creative Suite, what's the actual workflow for making sure your colors translate? Daniel's using open-source tools. He's got GIMP, Inkscape, Scribus maybe. Can he even generate a proper CMYK PDF?
He can, but it requires being intentional in ways that commercial software hides from you. Scribus, which is the open-source page layout application, actually has quite robust color management. You can set up a document with a CMYK target profile from the start, assign FOGRA thirty-nine or whichever profile your printer specifies, and export a PDF/X-4 that embeds that output intent. The key is doing it at document creation, not as an afterthought during export. Inkscape can work in CMYK with some plugin assistance, but its native color space is sRGB. GIMP's CMYK support has historically been limited — recent versions are better, but you still need to be deliberate about soft-proofing, which means previewing on screen how the colors will shift when converted. The fundamental advice for Daniel: ask the print shop which ICC profile they want, set that as your working space before you place a single pixel, and never assume that what looks bright on your monitor will survive the translation to ink without a conversation.
That's the kind of advice that sounds tedious until you've paid for a run of five hundred brochures that came back the color of regret.
Regret has a specific CMYK value. It's approximately forty percent cyan, sixty percent magenta, eighty percent yellow, and a hundred percent lesson learned.
Now the other visual airbag: fonts. Someone tells an overseas printer, "Sure, I converted everything to outlines. One shape, one path, foolproof." What is being lost when you do that?
Let me lay it plainly. When you convert text to outlines, you're taking the font data — which includes not just the shapes of the letters but also something called hinting instructions — and you're discarding the instructions, keeping only the raw vector paths. Hinting is a set of rules embedded in the font file that tells the renderer how to adjust letter shapes at small sizes so they remain legible. At large display sizes, hinting doesn't matter much. But if your document has any small text — think footnotes, captions, fine print on a poster, anything below about seven or eight points — the hinting data is what keeps the thin vertical strokes of a letter from disappearing when printed.
When you outline fonts, the RIP loses the ability to make those micro-adjustments.
The RIP has to render the raw outline geometry exactly as it is, scaled down to whatever size the text appears. Without hinting, a thin stroke that should be one pixel wide might land exactly between two pixel rows. The RIP has to decide whether to round it up to two pixels — making the letter look bloated — or round it down to zero pixels, making that part of the letter vanish entirely. You get gaps in letterforms. The crossbar on a lowercase "e" closes up. The bowl of a lowercase "a" fills in. It's not a cosmetic issue; it's a legibility failure.
Yet "convert to outlines" is standard advice in a lot of online forums. Why does that advice persist?
Because it solves a different problem. The original problem outlines solve is font licensing. If you embed a font in a PDF, you're technically distributing a copy of that font file to the printer. Some commercial font licenses prohibit that. Converting to outlines sidesteps the licensing question entirely — there's no font left to embed, just shapes. The second problem it solves is missing fonts. If you send a PDF that references a font you didn't embed, and the printer doesn't own that font, the RIP substitutes something else — usually a generic fallback — and your layout reflows. Outlines prevent that. So the advice isn't wrong for those two problems. It's just that it trades them for a third problem that only shows up at small sizes.
The real rule is: embed fonts when your license allows it, outline only as a fallback, and if you must outline, check every piece of small text in the proof at actual size before approving the run.
And for Daniel on Linux, the font licensing landscape is actually friendlier. If you're using open-source fonts — Google Fonts, Libertine, the TeX Gyre family — the licenses almost universally allow embedding in PDFs. You can embed freely, preserve hinting, and never touch the outline command. The licensing headache mostly applies to commercial foundry fonts with restrictive EULAs.
That's a rare case where the open-source ecosystem gives you a cleaner path than the proprietary one. Usually we're the ones doing workarounds.
The tables turn occasionally. And speaking of workarounds, there's one more piece of the PDF specification that Daniel should know about, because it directly addresses the problems we've been discussing. That's the PDF/X family of standards.
I've seen the checkbox in export dialogs. What does the X actually enforce?
PDF/X is a subset of the full PDF specification designed specifically for blind exchange in print production. The X stands for exchange. The idea is that a PDF/X file makes certain guarantees that eliminate the guesswork we've been describing. The most common variants are PDF/X-1a, which requires all color data to be in the final output color space — usually CMYK — and PDF/X-4, which allows RGB and LAB color but requires an output intent profile to be embedded so the RIP knows how to convert. Both variants require fonts to be embedded. Both require the page geometry boxes to be explicitly defined, including the bleed box. Both prohibit things like transparency that can choke older RIPs unless they're properly flattened. When a printer says "send us a PDF," what they often mean — and don't always articulate — is "send us a PDF/X-4 with these specific settings.
It's the difference between saying "send me a document" and "send me a document formatted according to this specific template that I know my system can ingest without human intervention.
And the human intervention is the expensive part. If your file needs a prepress operator to open it, diagnose what's wrong, fix color spaces, outline fonts, and re-export, that's billable time. A clean PDF/X file can go straight from email attachment to RIP with no human in between. That's the holy grail of print workflow.
Which brings us to the last piece of invisible metadata that the prompt mentioned: bleed. I've heard the term. I've nodded along when printers asked if I included it. But what actually is bleed, and why does a PDF need to know about it?
Bleed is the extra image area that extends beyond the trim edge of your final printed piece. When a print job comes off the press, it's printed on a larger sheet and then cut down to final size with a guillotine cutter. That cutter has a mechanical tolerance — typically about one and a half to three millimeters of variation. If your design stops exactly at the trim edge and the cutter blade lands a millimeter to the left, you get a thin white sliver along the edge of your print. Bleed prevents that by extending your background color or image past the trim line, usually by three millimeters on all sides. The bleed box in the PDF specification tells the RIP exactly where that extended area begins and ends, separate from the trim box and the media box.
It's margin for error, literally. But the PDF has to communicate which margin is which.
A properly constructed PDF for print has multiple nested boxes defined in the page geometry. The media box is the full physical sheet size. The bleed box is slightly inside that, defining where the extended image area stops. The trim box is where the cutter blade is supposed to land. And the art box or crop box defines the visible area of the final piece. If your PDF doesn't define these boxes, the printer has to guess where the trim is supposed to be. And as we've established, when the printer guesses, you pay.
We've got a pretty complete picture now. A PDF that's ready for print is a container with embedded fonts, tagged color profiles, an output intent, defined page geometry boxes including bleed, and images at appropriate resolution for the viewing distance. That's a lot of invisible structure that a PNG simply cannot carry.
That's the answer to Daniel's question. The printer isn't being difficult. The printer is running a pipeline that expects answers to a dozen questions, and a PDF is the only common format that can answer all of them in a single file. A PNG answers exactly one question: what do the pixels look like? Everything else is silence, and silence in a print pipeline is expensive.
Daniel, if you're listening from your Linux terminal in Jerusalem, the short version is: your printer's RIP is almost certainly running Linux too, it wants to be your friend, but you've got to speak its language. That language is PDF/X, with embedded fonts, a declared color profile, and enough pixels to match your viewing distance. Now you know why.
Now you know enough to have the conversation with the print shop in their terms. Ask them which PDF/X variant they prefer, which ICC profile they're targeting, and what bleed they need. They'll probably be so surprised by the questions that they'll treat your file with extra care.
That's the real cheat code. Sound like you know what you're doing, and suddenly everyone wants to help you succeed. Thanks for the question, Daniel. And thanks for walking us through the invisible machinery, Herman.
Always a pleasure to talk about the things nobody sees until they're wrong.
