Print-ready graphics: what a printer actually needs from your logo

Sending a logo to print surfaces three concerns that are easy to mix up - resolution, file format, and color space - and the fix for each is a short command-line conversion, not a redesign. This is the reference for what a printer actually needs and how to produce it from a vector source you already have.

TL;DR

SVG is a vector format. It has no resolution. “Not high-res enough” is a category error - a vector scales to a 2 m banner and a business card from the same file.
The PNG half of the complaint is real. A raster logo has fixed pixels; blown up to banner size it softens. That is the only legitimate part.
“We need .ai” is a format preference, not a quality requirement. Print shops standardise on Adobe tooling and their prepress pipeline may not ingest SVG cleanly. A print-ready PDF carries the same vectors.
CMYK conversion is the vendor’s job, not yours - and converting it yourself with a generic profile can make color accuracy worse.
Two commands (rsvg-convert, then optionally ghostscript) produce everything a printer needs. The one thing that will silently break the result is a <text> element referencing a font the converter does not have.

The three things being conflated

Concern	What it actually is	Who owns it
Resolution	Vector (SVG, PDF) has none; raster (PNG) has a fixed pixel grid	You, only if the source is raster
File format	`.ai` / `.eps` / PDF vs SVG - a tooling-pipeline preference	Vendor converts, or you convert to PDF
Color space	RGB (screen) vs CMYK (ink) - a real print concern	The printer, at their RIP, with their ICC profile

A pull-up banner at roughly 850 x 2000 mm is the case vector was built for. Hand the printer a vector PDF and they place it at any size with no resampling. The “high-res” framing usually means “we don’t want to deal with an SVG.”

Why the PNG complaint is real but the SVG one is not

A PNG at 1000 px wide printed across a 300 mm logo area is about 85 DPI - visibly soft. That is a genuine limitation of a raster source. But the fix is not “send a bigger PNG”; it is “use the vector.” Upscaling a PNG with a resampling tool interpolates pixels and still looks soft at the edges where a vector stays crisp.

The SVG has no such floor. It is a list of paths and curves; the renderer rasterises it at whatever resolution the output device needs. A print RIP at 2400 DPI and a web browser at 96 DPI both render the same SVG correctly.

Why “we need .ai” is a format ask, not a quality ask

.ai is Adobe Illustrator’s native format. Modern .ai files are PDF-compatible containers with Illustrator-private metadata on top. Print vendors ask for it because their prepress tooling (pre-flight, imposition, trapping) is built around Adobe products and historically handled .ai/.eps/PDF natively while treating SVG as a web format.

The practical consequence: a print-ready PDF is accepted by essentially every print workflow and carries the identical vector data. The formal press-ready forms are the ISO-standardised PDF/X variants - X-1a for older workflows, X-4 for modern ones¹ - which constrain fonts, color, and transparency so the file is predictable at the RIP. A plain vector PDF is usually enough for a logo asset, because it gets placed into the banner layout rather than going to press on its own. If a vendor insists on .ai specifically, the conversion is opening the PDF or SVG in Illustrator and re-saving - a minute of work, and it is their minute.

The real print gotchas in an SVG

These are legitimate things that go wrong when an SVG goes to print. None of them are about resolution.

Fonts. If the logo text is a live <text> element referencing a font, the converter and the printer both need that font installed, or the text renders as a fallback. This is the one silent failure. The fix is to convert text to outlines (paths) before handoff - most brand logos are already distributed this way. Check first:

grep -c '<text' logo.svg    # 0 = all paths, no font dependency. Good.

RGB color space. SVGs are authored in RGB (sRGB). A press prints in CMYK. Left to the RIP this converts automatically; done carelessly by hand it can shift a brand color. This is the one place “send it to print” needs real care - covered below.

Effects and transparency. SVG filters (blur, blend modes) do not always translate to PDF cleanly. Flat logos with solid fills are unaffected; if the logo uses filters, render a proof before sending.

Bleed. Bleed and trim are properties of the banner document, not the logo asset. The designer places the logo into the banner layout and sets bleed there - the PDF/X presets exist for exactly that composite step.² A logo file never carries bleed.

CMYK: who converts, and why it is usually not you

A press uses CMYK ink; a screen uses RGB light. Some conversion must happen before ink hits vinyl. The question is whose conversion is accurate.

The printer’s RIP converts using an ICC profile matched to their specific press, ink set, and substrate. That conversion is more accurate than anything you produce generically, because it is calibrated to the actual hardware. Converting to CMYK yourself with a generic profile (e.g. Ghostscript’s default) bakes in a conversion tuned for no particular press - and if the vendor’s RIP then re-converts, the color drifts twice.

So the default answer is: hand over the RGB vector and let the printer convert. Convert to CMYK yourself only when the vendor explicitly asks for a CMYK file, and say in that case that the conversion is generic.

The exception worth raising is a brand color that must match exactly. Some vivid colors fall outside the CMYK gamut and cannot be reproduced by process ink at all. If exact match matters on a long print run, the answer is a spot color (Pantone) - a pre-mixed ink on its own plate - not a CMYK conversion. That is a decision to hand to the printer, with the brand hex value in hand.³

Producing the print pack from the command line

From an SVG source, two tools cover the deliverables. rsvg-convert (librsvg) turns SVG into PDF or PNG at any size; Ghostscript handles the optional CMYK pass.

# Vector PDF - the master quality deliverable
rsvg-convert -f pdf -o logo.pdf logo.svg

# High-res transparent PNG fallback (~300 DPI at 30 cm printed width)
rsvg-convert -w 3600 -f png -o logo-3600px.png logo.svg

# CMYK variant - only if the vendor explicitly asks for CMYK
gs -dBATCH -dNOPAUSE \
   -sColorConversionStrategy=CMYK -dProcessColorModel=/DeviceCMYK \
   -sDEVICE=pdfwrite -o logo-cmyk.pdf logo.pdf

Verify the outputs rather than trusting the commands. Check the vector PDF has no font dependencies (so it cannot break on the printer’s machine) and that a CMYK file really is CMYK:

pdffonts logo.pdf            # empty table = all outlines, no fonts. Good.
gs -o - -sDEVICE=inkcov logo-cmyk.pdf   # "0.08 0.03 0.08 0.01 CMYK OK" = real CMYK
strings logo-cmyk.pdf | grep -oE '/DeviceCMYK|/DeviceRGB' | sort | uniq -c
# want only /DeviceCMYK; a leftover /DeviceRGB means the conversion missed something

What to actually send

A sensible handoff bundle for a vendor asking for a “high-res logo”:

The vector PDF (RGB) - the master. Say this is the preferred file and that their RIP will handle color.
The CMYK PDF - for the color-critical variant only, and only if they ask.
A high-res transparent PNG - as a raster fallback for tooling that truly cannot take vector.
The original SVG - the source of truth.
A README stating the brand color hex, that there are no fonts (all outlines), and that bleed is set on the banner document, not this asset.

That answers every legitimate version of the request, and the README quietly corrects the category error without a fight.

References

Hybrid Helix, “PDF/X-1a vs PDF/X-4: What’s the difference - and which should you use in 2025?” https://blog.hybridhelix.com/pdf-x-1a-vs-pdf-x-4-whats-the-difference-and-which-should-you-use-in-2025/ ↩
Allied Printing, “File Setup 101: How to Send Us Print-Ready Artwork.” https://alliedprintinghsv.com/file-setup-101-print-ready-artwork/ ↩
PrintingForLess, “Complete Guide to Creating Press Ready Print Files.” https://www.printingforless.com/resources/complete-guide-to-creating-press-ready-print-files/ ↩