{"id":317,"date":"2026-06-03T20:08:05","date_gmt":"2026-06-03T20:08:05","guid":{"rendered":"https:\/\/memoria-cards.fr\/?page_id=317"},"modified":"2026-06-21T10:12:35","modified_gmt":"2026-06-21T10:12:35","slug":"building-memoria-cards-how-i-rewrote-my-software-pipeline-three-times-and-finally-got-it-right","status":"publish","type":"page","link":"https:\/\/memoria-cards.fr\/?page_id=317","title":{"rendered":"Building Memoria Cards \nHow I Rewrote My Software Pipeline Three Times (And Finally Got It Right)"},"content":{"rendered":"\n

<\/p>\n\n\n\n

Making physical trading cards at home sounds simple enough. Design a template, add some art, print it out. But if you want to do it right<\/em> with consistent quality, scalable production, and clean print output the software side turns out to be a rabbit hole of its own. Here’s how my pipeline evolved over two years, from shaky Photoshop experiments to a fully parametric SVG factory.<\/p>\n\n\n\n

<\/p>\n\n\n\n

Phase 1: The Idea Takes Shape in Photoshop<\/h3>\n\n\n\n

It started with a familiar itch: I wanted video game\u2013themed trading cards. Nothing commercial existed that quite scratched it, so I figured I’d make my own.<\/p>\n\n\n\n

I opened Photoshop and started building templates. The vibe was right, the illustrations clicked into place, the DNA of what would become Memoria Cards was already there. Then I stopped. Life moved on, the files sat idle.<\/p>\n\n\n\n

But there was a deeper problem I hadn’t fully admitted yet: I am genuinely disorganized in Photoshop. Layer structures would drift. Each new card became a slightly different version of the template. Nothing was standardized. The moment I’d want to change a font, a color, a layout element… I’d have to hunt it down manually across a dozen separate files. It wasn’t sustainable for even a small run of cards, let alone a real catalog.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

<\/p>\n\n\n\n

Phase 2: A Python Pipeline with Pillow<\/h3>\n\n\n\n

The itch came back, stronger this time, and with it a new idea: automate the whole thing with Python.<\/p>\n\n\n\n

I built a set of scripts using the Pillow imaging library. Cards were generated programmatically, each one assembled from components: illustrations, rounded rectangles, stat bars, text layers. I added small visual touches like noise effects and soft drop shadows. A masking and cropping system kept the card frame crisp. For the first time, I could generate a card from a YAML description without touching any image editor.<\/p>\n\n\n\n

It felt like a real step forward. I even got a batch printed through MPC, and they looked… decent.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n
\"\"<\/figure>\n\n\n\n

But the pipeline had real structural problems:<\/p>\n\n\n\n

    \n
  • Maintenance was painful.<\/strong> Pillow is a low-level raster library. Every visual tweak meant digging back into pixel-math code. There was no template in any meaningful sense : just a very long script.<\/li>\n\n\n\n
  • Typography was terrible for print.<\/strong> The only way to get sharp text was to render at 3\u00d7 resolution and downscale. This is a hack, and it showed. Print-ready files need true vector text, not downsampled raster approximations. The whole approach was fundamentally misaligned with what high-quality printing actually requires.<\/li>\n<\/ul>\n\n\n\n

    The printed cards were fine for a prototype. But I knew this wasn’t the foundation to build on.<\/p>\n\n\n\n

    <\/p>\n\n\n\n

    Phase 3: SVG Changes Everything<\/h3>\n\n\n\n

    Then a thought clicked: SVG is just XML. I can manipulate it programmatically.<\/em><\/p>\n\n\n\n

    I rebuilt the entire pipeline from scratch around Inkscape and SVG. The shift in approach was total.<\/p>\n\n\n\n

    Now, I design my card template in Inkscape like a proper designer with full visual control, proper typography, clean geometry. Every element that needs to vary gets a unique id<\/code>. Then a Python script walks the SVG tree, swaps out attribute values and text nodes, injects illustration paths, and writes a new file. SVG 2 also offers a handful of native filter effects (noise, blur, color transforms) that replace all my old Pillow hacks with clean, resolution-independent declarations.<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    The result is a Template Factory<\/strong>: a parametric system where each card is a rendered instance of a model, not a hand-crafted Photoshop file. The same mechanism generates print sheets multiple cards laid out on a single page, ready to send to the printer.<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    <\/p>\n\n\n\n

    The gains are significant:<\/p>\n\n\n\n

      \n
    • Vector quality all the way to output.<\/strong> No resolution decisions until the very last step. The SVG stays sharp at any size, and my print files are genuinely print-ready.<\/li>\n\n\n\n
    • Fine-grained print control under Linux.<\/strong> I drive my color laser printers directly with lp<\/code>, tuning every parameter, page size, duplex mode, color profile, from the command line. No guesswork, no driver dialogs.<\/li>\n\n\n\n
    • Unified color correction.<\/strong> Color adjustments are applied once, consistently, across every card in a run. No more per-file tweaking.<\/li>\n<\/ul>\n\n\n\n

      What I Learned<\/h3>\n\n\n\n

      The jump from Photoshop to Pillow was about gaining automation<\/em>. The jump from Pillow to SVG was about gaining correctness<\/em>. Both were necessary and I don’t think I could have seen the SVG solution without having lived through the Pillow limitations first.<\/p>\n\n\n\n

      If you’re building something similar and wondering where to start: design your template in a real vector tool, give your elements meaningful IDs, and let code handle the rest. The separation between design<\/em> and data<\/em> is what makes the whole thing scale.<\/p>\n\n\n\n

      <\/p>\n","protected":false},"excerpt":{"rendered":"

      Making physical trading cards at home sounds simple enough. Design a template, add some art, print it out. But if you want to do it right with consistent quality, scalable production, and clean print output the software side turns out to be a rabbit hole of its own. Here’s how my pipeline evolved over two […]<\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-317","page","type-page","status-publish","hentry"],"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/memoria-cards.fr\/index.php?rest_route=\/wp\/v2\/pages\/317","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/memoria-cards.fr\/index.php?rest_route=\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/memoria-cards.fr\/index.php?rest_route=\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/memoria-cards.fr\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/memoria-cards.fr\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=317"}],"version-history":[{"count":6,"href":"https:\/\/memoria-cards.fr\/index.php?rest_route=\/wp\/v2\/pages\/317\/revisions"}],"predecessor-version":[{"id":415,"href":"https:\/\/memoria-cards.fr\/index.php?rest_route=\/wp\/v2\/pages\/317\/revisions\/415"}],"wp:attachment":[{"href":"https:\/\/memoria-cards.fr\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=317"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}