The Self-Publisher's Cover Art Pipeline: Commissioned Art to SVG Layout to Print

The cover for The Incubator started as a massive 4000×6000 pixel illustration from the artist Emery (@emerydrawss). It ended as a 300 DPI TIFF that weighed 47 megabytes. Between those two points was a production pipeline that I built by getting it wrong first.

This is not a design tutorial. It is a pipeline specification — the file formats, the resolution requirements, and the specific things KDP rejects that you will not discover until you submit. If you are producing cover art for self-published books, here is the chain that works.

Building planning-first AI systems, one pipeline at a time. Get weekly deep dives into local AI, Rust, and agent orchestration — no fluff, no hype.

Commissioning the Art

I commissioned the cover illustration directly from an artist, Emery (@emerydrawss). The final deliverable was a single raster file — 4000×6000 pixels, 22.3 MB — more than enough resolution for any format I needed. The art was the foundation. Everything after it was layout.

SVG as a Layout Layer

Here's where the pipeline diverges from what most guides assume. My source of truth for the cover wasn't the raster art — it was an SVG file layered on top of it.

I use SVG because it is text-based, diffable in git, and editable in any text editor. Inkscape reads it. Illustrator reads it. Browsers render it. There is no lock-in. The SVG contained the text layout — title, subtitle, author name, tagline — positioned precisely over the commissioned artwork using an embedded <image> tag that referenced the raster illustration.

SVG as a layout layer means the same composition produces every downstream format. The Kindle thumbnail at 80×120 pixels and the paperback cover at 1600×2400 both come from the same SVG, rendered at different resolutions. When I updated the cover after the first print run — adjusting the spine width because the page count changed — I changed one number in the SVG and re-ran the export. Every downstream file regenerated.

The raster art stayed fixed. The SVG handled all the positioning, sizing, and text work. This separation matters because the art and the layout change at different rates and for different reasons.

The Export Chain

The production pipeline has three stages, each producing a specific file format for a specific purpose.

Stage 1: SVG to PNG (Ebook Cover)

The first export is a PNG at 300 DPI, sized to KDP's digital cover specification. For a standard 6×9 inch paperback, that is 1800×2700 pixels.

inkscape --export-type=png \
  --export-dpi=300 \
  --export-filename=cover-300dpi.png \
  cover-source.svg

This PNG is the ebook cover — the image that appears on Kindle devices and in Amazon's storefront. Amazon's Kindle Direct Publishing requires a JPEG or TIFF for the ebook cover, minimum 625×1000 pixels, ideally 1600×2560. I produce the PNG first because it is lossless, then convert to JPEG for submission.

Always export from vector to a lossless format first. Every lossy compression step degrades quality. The chain should go SVG → lossless → lossy, never lossy → lossy.

Stage 2: PNG to JPEG (Kindle Submission)

The Kindle submission file is a JPEG. Amazon recommends 1600×2560 pixels for the best display across devices. The file must be under 50MB.

convert cover-300dpi.png -resize 1600x2560 \
  -quality 90 cover-kindle.jpg

Quality 90 is the sweet spot. Below 85, JPEG artifacts appear on flat color areas (which covers often have). Above 92, file size increases with no visible improvement. The Kindle display is not a print medium — it is a screen, and screens do not benefit from lossless cover images.

Stage 3: SVG to TIFF (Paperback Print)

The print cover is where most people get rejected. KDP requires a TIFF or JPEG at 300 DPI, with specific dimensions that include the front cover, back cover, spine, and bleed. For a 6×9 inch paperback with 300 pages, the full cover is approximately 12.525×18.25 inches — which at 300 DPI is 3758×5475 pixels.

The spine width calculation depends on page count and paper type. KDP provides a formula: page count × 0.002252 inches for white paper, page count × 0.0025 inches for cream paper. Get this number wrong and the spine text is off-center. KDP will not reject the file for a wrong spine width, but the printed books will look wrong.

inkscape --export-type=png --export-dpi=300 \
  --export-filename=cover-300dpi.png \
  cover-full.svg
convert cover-300dpi.png -density 300 \
  -units PixelsPerInch \
  cover-print.tif

TIFF for print, JPEG for screen. This is not a preference. Print houses expect TIFF because it supports CMYK color space and lossless compression. KDP accepts JPEG for print covers, but TIFF is the safer choice because it avoids any question of compression artifacts on the physical press.

Full Cover Composition

The SVG source for the ebook cover only contains the front cover layout. The full print cover — front, spine, back, bleed — is composed separately. I do this in Inkscape using a second SVG that imports the front cover layout and adds the spine text, back cover copy, barcode placeholder, and bleed guides.

This two-SVG approach matters because the front cover layout changes independently of the print layout. When I adjusted the cover's color palette after the first proof, I only touched the front cover SVG. The print layout SVG — spine, back cover, barcode — stayed the same. Re-rendering the full cover was a one-command operation.

What KDP Rejects

These are the rejection reasons I have personally encountered, in order of how long they took to diagnose:

  1. Wrong dimensions. The cover file must match the trim size, spine width, and bleed exactly. A difference of 2 pixels in width is enough to trigger an automated rejection. The error message says "cover dimensions do not match" without telling you which dimension is wrong.

  2. RGB color space for print. KDP's printer expects CMYK. An RGB TIFF will sometimes pass automated checks but produce washed-out colors in print. The fix is converting to CMYK before export, which requires a tool that supports CMYK (Inkscape does not natively; Photoshop or GIMP with a plugin does).

  3. Resolution below 300 DPI. A cover that looks fine on screen at 72 DPI will be rejected for print. The automated check looks at the DPI metadata in the TIFF, not the actual pixel dimensions. A 3758×5475 pixel image tagged as 72 DPI will be rejected even though it has enough pixels.

  4. Spine text on a cover with fewer than 79 pages. KDP does not allow text on the spine of thin books. This is a content policy rejection, not a technical one — the file is fine, but the spine is too narrow for legible text.

  5. Barcode area not blank. KDP places its own barcode in the lower-right corner of the back cover. If your cover art extends into this area, the file is rejected. The barcode area is 2×1.2 inches, positioned 0.25 inches from the trim edge.

Each rejection costs 24 hours. KDP's automated review takes up to 72 hours, and a rejection restarts the clock. A cover that fails three checks takes nine days to publish — not because the fixes are hard, but because the feedback loop is slow.

The Principle

A cover art pipeline is a build system, not a design process. The design happens in the SVG layout — the art is delivered, the text is positioned, and the composition is locked. Everything after that is compilation — deterministic transforms that produce specific formats for specific targets. When the pipeline is scripted, a cover update is a single command. When it is manual, every format change is an opportunity to introduce a subtle inconsistency that shows up as a rejection three days later.

The pipeline I run now is a Makefile. One target produces the Kindle JPEG. One produces the print TIFF. One produces the web preview PNG. The source SVGs are version-controlled. When I change the cover, I commit the SVG change, run make, and submit the generated files. No manual steps, no "did I remember to resize the preview image," no guessing about which version is current.

The cover is the first thing a reader sees. It should be the last thing you worry about in the production pipeline — because by the time you are generating final files, the design should be done and the pipeline should be boring.

I wrote a science fantasy novel — The Incubator, the first book in the Etrath series. These are the lessons that came from building it.