Convert SVG to TIFF

An SVG has no resolution. It is a list of shapes, and a renderer can produce it at 100 pixels or 10,000 with the same fidelity, which is why the file works equally well on a business card and on a building. A TIFF has exactly one resolution, chosen at the moment it is written, and every later use is a scaling of that grid.

So this conversion is a one-way door and the width you pick is the width you have. Rendering too small cannot be undone — enlarging a TIFF afterwards interpolates pixels that were never drawn — and rendering too large is merely wasteful. Get the number before you convert, not after the proof comes back.

The arithmetic is short. Take the printed width in millimetres, divide by 25.4 to get inches, and multiply by the dots per inch the job is specified at. A mark printed 100 mm wide at 300 dpi needs 1,181 pixels; at 600 dpi it needs 2,362.

The scale setting is how you land on it. The default renders 1,024 pixels wide, which is 86.7 mm at 300 dpi or 43.3 mm at 600 — a fair size for a logo on a page and much too small for a poster. Scale runs from 0.1 to 10, so the widest available is 10,240 pixels, which is 867 mm at 300 dpi.

Nothing is compressed and each pixel carries four samples, so the size is arithmetic rather than a surprise: width times height times four, plus about a kilobyte of directory. A 1,024-pixel square comes to 4,194,304 bytes of image data, and the measured file was 4,195,304 — from a 140-byte SVG.

Scaling up costs the square of the factor. At scale 3 the same drawing is 3,072 pixels and 37.7 megabytes; at scale 10 it is 10,240 pixels and 419 megabytes, which is enough to exhaust a phone’s memory before the file is written. Render to the size the job needs and no further.

TIFF is less a format than a filing system for images, and its readers agree on less than the name suggests. LZW is patent-free and universally supported; Deflate is not; JPEG-in-TIFF is a different image inside a TIFF wrapper and defeats the reason most people ask for one. The uncompressed baseline is the single variant everything accepts.

Somebody converting to TIFF is almost always feeding something particular — a RIP, a scanner’s software, an ingest folder — and a file that one link in that chain refuses costs far more than disk space does. That is the trade this converter makes, and it is stated here rather than discovered later.

This is the point at which a prepress operator should stop and read. The TIFF written here has red, green and blue channels plus alpha. A press has cyan, magenta, yellow and black inks, and the conversion between the two is not a formula — it depends on the paper, the press and the ink limit, which is why it is done with a profile rather than automatically.

Do that conversion in prepress with the right profile rather than expecting the file to arrive ready. Two colours worth watching: a saturated RGB blue and a bright RGB green have no CMYK equivalent at all and will come back duller than the screen showed. If those are brand colours, the vector should be specified in spot colours and the drawing should not be going through a raster step at all.

The byte count says four samples per pixel, so the transparency from the drawing is in the file rather than discarded. That much is certain from the arithmetic.

What varies is the reader. Some applications composite the alpha against white on import, some present it as a selectable channel, and some ignore it entirely and show the colour underneath — which for a rendered SVG is black, since nothing was drawn there. Open the result in the application that will place it before assuming a cut-out will behave as one, and if in doubt render onto an explicit background rectangle in the drawing.

For print this is worth a question before it is worth a conversion. A PDF keeps the drawing as vectors, so there is no resolution to get wrong, no file-size arithmetic to do, and the press prints it at its own precision rather than at whatever grid somebody chose in a browser. It is also what most design and prepress software would prefer to receive.

Where the pipeline genuinely requires raster — some large-format RIPs, some textile and ceramic processes, some document archives — the TIFF here is the right answer and the resolution arithmetic above is the work. Where it does not, converting a vector to a four-megabyte grid of pixels is throwing away the property that made the file useful.

SVG stores text as text and names a typeface rather than containing it. Anything not embedded is substituted at render time, so a wordmark can arrive with different letterforms and different spacing, and on a print job that is discovered late and expensively.

Convert text to outlines or paths before exporting the SVG. The letters become shapes, nothing can substitute them, and the file becomes safe to hand to a supplier who has none of your fonts. This is standard practice for anything going to print and it costs one menu item.

Drop the folder and every file is rendered at the same scale, which keeps a set of marks consistent with each other — usually more important on a printed sheet than any single one being individually ideal. The results come back as a ZIP.

Watch the total. Twenty drawings at the default scale is over eighty megabytes of TIFF before the ZIP, and uncompressed image data does not shrink much inside one. If the set is going to a supplier over email, that number is the reason to render at the size the job needs rather than the size that felt safe.