---
date: 2021-11-20T22:21:00Z
---
tilde.town has a digital zine which releases new issues on a roughly annual basis. As I've been helping with production, I'm posting some comments here about my workflow using tools like Inskcape and Scribus, on the chance it might motivate others interested in getting involved, or want to make their own zine.
Please keep in mind this is just one way to make a zine PDF and it may not even be a good method. I had never done zine layouts prior to the town zine, but faced with a folder of new submissions and the possibility of the zine ceasing publication, decided to try, at least whenever I had the time and energy.
There are three main parts to the zine file: cover design, document setup and export, and layout of contributors' works. Usually I start with the cover design and wait for zine submissions to accumulate before doing both document setup and layout in conjunction. The design includes front/back covers (no spine) and a title page.
I've been using Inkscape for issues #3-4 because vector graphics is very suited to the flat illustration style on the covers, but many applications can be used for designs with a bit of adaptation and creativity. The important thing is to start the new image at a semi-decent resolution (96-150 dpi for web, 300 dpi for print), unless the image is intentionally left blurry or pixelated for stylistic effect. The town zine for example is A5 in size (148 x 210 mm), which is approximately 1748 x 2480 px at 300 dpi.
uploads/2021-11-20-zine-workflow/01-inkscape-cover-design.png
Issue #3 cover design in Inkscape. The editor has axonometric grids that make it easier to build up streetscape scenes.
Each design gets its own layer, or a layer group if it's more detailed. Sometimes I let shapes extend beyond the page borders since they can be clipped during export anyway by setting the export area to the page size. However, the extra "bleed" can be useful for leaving some buffer around the edges to ensure minute shifts during printing won't affect the final result. When saving a copy as PDF in Inkscape, there is an option to set the bleed right before saving, Comparing the resulting PDF after adding a small amount of bleed, the area surrounding the page borders would be visible in the PDF. For the zine, I reserve 6.35 mm bleed on all four sides. The amount of bleed varies among printers (around 5 mm or ⅛ inch is usually adequate for A4/A5 documents), though if you're printing from home and can tolerate some shifting, you can probably skip this step.
uploads/2021-11-20-zine-workflow/02-inkscape_cover-bleed.png
Exported cover design, without bleed (left) and with bleed (right).
The reason for exporting to another file format like PDF or PNG instead of importing the SVG itself elsewhere is because some SVGs don't display consistently among applications (e.g. missing fills for grouped objects or filter effects not displaying), while other formats import mostly intact, in worse cases at the cost of effects being rasterised. Try importing the SVG first before falling back to another format. However, it shouldn't be a problem for a small zine considering the mixed formats and variable resolution of images that might be submitted.
As more submissions roll in, it's time to create the zine layout. My predecessor used Pages, and the logical alternative for Linux would be LibreOffice, which I'd still like to try using for zine-making sometime. However, I was more familiar with Inkscape at the time and liked being able to move objects around on a grid, so after laying out each page on its own layer, I looked for a way to batch export all the layers to PDFs then merge them.
There's a utility called InkscapeSlide for presentations that can output a PDF from a SVG file with each SVG layer as a page. To use it, a layer named "content" is added with a text box that lists all the names of the other layers by order of appearance in the PDF file. Then the PDF can be generated with the simple command `inkscapeslide file.svg`. The exporting works well if you don't need any particular settings for print. Unfortunately it's a Python 2 package that hasn't been updated in years.
uploads/2021-11-20-zine-workflow/03-inkscape-layout-layers.png
A list of layers in Inkscape to be parsed by InkscapeSlide. Each layer except the "content" layer is a page in the resulting PDF.
After the first PDF with InkscapeSlide I switched to Scribus, which I started using for cards and leaflets. I have a very basic template for the zine with the document size and bleed presets, along with a few pages for the front/back covers, title page, table of contents and content page. Images for the covers and title page are imported into the document.
uploads/2021-11-20-zine-workflow/04-scribus-template-cover.png
A Scribus template with a placeholder image frame for the front cover.
uploads/2021-11-20-zine-workflow/05-scribus-cover-set.png
The front cover with the image loaded. The inner red border is the page border.
Next are the contributors' works. They come in a variety of file formats — plaintext files (e.g. Markdown, source code), images (JPG, PNG) or some combination of the two (e.g. PDF with text and images). Each piece is positioned manually onto a new page, which is fairly easy to do with accuracy in Scribus using grids and guides, or by setting coordinates from the object properties panel that can be kept open.
uploads/2021-11-20-zine-workflow/06-scribus-page-set.png
A sample content page with text frames.
Prose can generally be copied as-is and allowed to re-flow unless they are hard-wrapped, in which case they are treated like other layout-sensitive text such as visual poetry and indented code, where the font size might be scaled for the text to fit the page width. Articles with pre-arranged layouts can be a little tricky, especially if the necessary fonts aren't already embedded in the document. Scribus will prompt for a selection if it cannot find the referenced font, and in some cases other fonts can be swapped without much adverse effect on alignment and style. Where possible, I also try to use fonts with open licenses, and would rather convert the text to vector paths than embed a non-free font. The downside is it renders the text unselectable and the inconsistency between mixing text and paths might be puzzling to readers. However, the authors' originals are available in the zine archive, so in the worst scenario people can still download the source files to follow along in articles containing code snippets.
Once all submissions are in and the pages are rearranged in order, I fill in the table of contents with the titles of works and page numbers. At this point it's almost ready. Before exporting, Scribus does a preflight check for potential problems, e.g. text don't overflow from their frames, no missing images, colours aren't out of gamut if a colour profile is set, etc. and it'll warn about any problems found:
uploads/2021-11-20-zine-workflow/07-scribus-export-preflight.png
A sanity check before exporting.
This is really handy for catching things like broken image links when they're not embedded into the file for a smaller file size, or text that got cut off while re-flowing paragraphs across multiple pages. Clicking on an item in question will switch the document view to the page where the object is located so it can be fixed. Occasionally the items flagged are harmless, e.g. an invalid glyph that is part of the piece, and the error can be ignored.
After clearing the preflight check, the export dialog will appear a few important settings to mention:
uploads/2021-11-20-zine-workflow/08-scribus-export-general.png
PDF export general settings.
uploads/2021-11-20-zine-workflow/09-scribus-export-pre-press.png
Setting the document bleed before exporting.
Generally I export the PDF two or three times to check image quality and skim for any other problems. There's also another setting I haven't mentioned, namely colour output, but it's another topic in itself as well as a conversation best had with the print shop where you're getting the zine printed. They may recommend certain colour profiles to help align as much as possible the colours you see on screen with the colours in print. For e-zines it might not matter that much, while low-res graphics can be part of a publication's retro vibes. Hopefully this overview provided a starting point for making fun and simple zines.
