Building a Print-First SVG Gallery: Lessons in CSS, PDFs, and Progressive Enhancement

#css #webdev #frontend #design

A printable gallery looks like a fairly ordinary content website until you try to make the same drawing behave predictably in three places: the gallery thumbnail, the full artwork page, and a real sheet of paper. Those are three different presentation problems.

Here are implementation lessons from working on a static, print-first coloring-page library. The useful parts apply to worksheets, diagrams, maps, patterns, and any site where visitors want to take a visual asset from the browser to a printer.

1. Start with the artifact, not the thumbnail

A thumbnail is only a preview. If the underlying asset has tiny gaps, overlapping contours, or unexpected clipping, enlarging the preview will not fix it. Keep the complete original artwork in a stable coordinate system, and let the browser scale it.

For a vector drawing, this starts with a viewBox:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 600 720" role="img" aria-labelledby="drawing-title">
  <title id="drawing-title">Simple printable flower</title>
  <circle cx="300" cy="340" r="80" fill="white" stroke="black" stroke-width="6"/>
  <path d="M300 420 V600" fill="none" stroke="black" stroke-width="6"/>
</svg>

The example is intentionally simple. In production, inspect both the whole composition and its smallest colorable regions at printed size. An SVG is resolution-independent, but it is not automatically good to color.

2. Letter and A4 are not interchangeable

US Letter is 8.5 × 11 inches. A4 is 210 × 297 mm. These page shapes are similar, not identical. A fixed frame or page margin that looks fine on Letter can cut into artwork on A4.

If visitors can download PDFs, prepare and inspect separate paper sizes instead of assuming that a browser's Fit setting solves every case. Validate the resulting PDFs, not merely the script that creates them. In particular, verify MediaBox dimensions, number of pages, and actual visible margin clearance.

3. Give print CSS its own layout

Do not make visitors print the navigation bar, search box, category filters, cookie controls, and related-content cards. Print is a separate presentation context:

@media print {
  header, nav, footer, .toolbar, .download-panel { display: none !important; }
  main { margin: 0; padding: 0; }
  .print-art { width: 100%; max-height: 95vh; object-fit: contain; }
}
@page { margin: 12mm; }

This is a starting pattern, not a guarantee: actual printable areas depend on the PDF/viewer, browser, and hardware. Always check print preview and at least one real output size.

4. Downloads should still work without JavaScript

A gallery can use JavaScript for searches, difficulty filters, and quick previews. A visitor should not need JavaScript to reach the actual download.

<a href="/assets/example.svg" download>Download the original SVG</a>
<a href="/assets/example-letter.pdf" download>Download Letter PDF</a>
<a href="/assets/example-a4.pdf" download>Download A4 PDF</a>

Keep true asset URLs in the HTML, use descriptive links, and make preview dialogs and filters enhancements rather than the only navigation path. This improves resilience for slow devices and assistive technology.

5. Avoid accidental thin pages

When every drawing has its own URL, a catalogue can accumulate many similar pages. A useful detail page should answer practical questions: what the picture shows, how detailed it is, which files are available, whether personal or classroom use is permitted, and where third-party artwork came from. A title plus a download button alone is not much help.

For an example of a live print-oriented artwork catalogue, I have been working on Coloring Petal. The main lesson is that the PDF/SVG itself and the quality of the print workflow should come before flashy interface controls.

A lightweight verification checklist

Before shipping another group of printables, check:

[ ] SVG opens, scales, and preserves the entire drawing.
[ ] Letter and A4 PDFs have expected page dimensions and real visible artwork.
[ ] The primary download links work without JavaScript.
[ ] The print view hides interface chrome without hiding the drawing.
[ ] Detail pages describe difficulty and source/usage constraints accurately.
[ ] Mobile visitors can still reach the same downloads.

Treat these as release checks, not assumptions made from filenames. A print-first site succeeds when the printed sheet matches what users thought they were getting.

DEV Community