Writing Articles

This page tries to address two questions:

  1. What kind of topics are accepted into our zine?
  2. How to technically prepare the article?

For the overview of the full process, please see the Call for pages! subpage.

If you have additional questions, or e.g. feel your topic isn't exactly what Paged Out! usually publishes but there are reasons why we might want to publish it anyway, send us an e-mail at articles@pagedout.institute.

Please note that we're using the singular form "author" on this page, but it actually applies to all authors of a given article in case it is co-created by multiple people.

Example articles


Feel free to use these templates for the articles. Feel free also to NOT use them and create your own layout (it's enough to just set the margins)!

Template donations for other software / other layouts are always welcome!

Article topics

Paged Out! is a deeply technical zine about computer related stuff - this includes the software side and the hardware side. When thinking about Paged Out!, the following keywords come to our minds: "demoscene", "hacking", "security/hacking", "retro computers", "modern GPUs", "FPGAs", "Software Defined Radio", "code golfs", "constrained programming", "hand drawn pixelart", "procedurally generated graphics/music", "satellites", etc. - this list is not exhaustive by any means, but it should give you a general idea.

So, naturally, the articles should fall into the above theme(s).

Example topic ideas that are aligned with Paged Out! profile (when in doubt - e-mail us):

  • "16-bit pixelart art from this game I worked on"
  • "How to draw NES art in the current year 2032"
  • "My solution to 256-byte boot-sector game competition"
  • "SNES cartridge backup with Arduino"
  • "How data was stored on cassette tapes in Atari 8-bit computers"
  • "Exploiting CVE-2042-1234"
  • "Inside of a Samsung Smart TV"
  • "Benchmark results of JSON parsers for Java"
  • "PCB/BOM/firmware for a simple remote"
  • "Receiving SSTV image from a satellite using Linux"
  • "Undocumented ARMv15 instructions"
  • "How to procedurally generate water texture"
  • "A really cool pixel shader for cyberpunk-theme games"
  • "RISC-V code reverse-engineering cheat-sheet"
  • "IRC server in 20 lines of (unreadable) C++ code"
  • "Changes in CPython bytecode between version 4.5 and 4.6"
  • "10 monitoring commands you should run on your Gentoo server"
  • "Everything you need to know about the PNG file format"
  • "Most hilarious thing I found while analyzing this firmware"
  • "Weird but amazing graphical mode in CGA cards"
  • "Analysis of the best code golf submission"
  • "CTF task writeup"
  • "10 attacks on typical RSA mistakes"
  • "Documenting failure: how NOT to design a high-frequency circuit"
  • "What your phone broadcasts about you"
  • "Quick intro to compression algorithms"
  • "Using TensorFlow to play Starcraft 3"

Example topic ideas that are NOT aligned with Paged Out! profile and probably won't get published (some exceptions are noted next to the examples; when in doubt - email us):

  • "10 page C tutorial" - while we are fine with content about basics, all articles must be exactly one page.
  • "One-page C tutorial, part 1" - we don't do "parts" here - each article must be self-contained; it's OK to do a series of such articles though, as long as each of them is valid as a separate article.
  • "How to bake really good cookies" - probably too far away from the profile of the zine (unless these are stack cookies with chocolate chips?); we might consider really good and fun to read articles like these from time to time as a fun addition though.
  • "ThisAmazingCryptoCOIN - you must invest!!1" - while we're fine with technical articles on how cryptocurrency/smart contracts/blockchains/etc. work, we will reject any content that even remotely tries to give out financial advice.
  • "0-day for BestServerPro 1.2.3" - it depends, see below
  • "Create the best malware!" – it depends, see below

0day topic policy

When determining whether to publish articles about 0-days, we'll use the following rules:

  • If information about a vulnerability is made public before the given issue of Paged Out! is published, then we're fine with publishing the article.
  • If a fix is made available (e.g. in publicly accessible repositories, or as part of automatic binary updates), we consider the vulnerability to be public after 7 days from this event.
  • If no fix is available and the vulnerability was in fact reported to the vendor/maintainers under the 90-day policy, we're fine with publishing the article after 90+14 days.
  • If no fix is available, but the vulnerability was reported under a different disclosure policy, we're fine publishing the article if the deadline agreed on by author/reporter and vendor/maintainer is not met (but not sooner than after 90+14 days), or after 12 months of reporting the vulnerability if no deadline was set.

Please note that regardless of what is written above, it still has to be a good article about an interesting bug in a high-profile target (sorry, no RandomPHPScript 0.0.1 LFIs, unless there is something really innovative in it).

Malware topic policy

When it comes to malware, the lead rule for us is for the article to neither normalize creating malware, nor encourage creating it. Note that we're treating the word "malware" literally, meaning any sort of software that was created with malicious intentions in mind. This definition explicitly excludes, e.g., redteaming or pentesting tools, which are created for security professionals to use, with the final goal being the improvement of security posture of the target (yes, we realize that these tools can be used for more nefarious purposes as well, but that's not their intended use).

As such, when determining whether to publish articles about malware, we'll be using the following rules:

  • Articles that can be read as "this is how you make [components of] malware" or stories like "this is how I made [components of] malware" will be rejected.
  • Articles that discuss existing [components of] malware for historic / documenting / research / archival / other reasons will likely be accepted.
  • Articles that are discussing potential future malware developments, but ARE NOT instructions on how to do that and DO NOT showcase how to do that, will likely be accepted, as long as the target audience are the defenders (and not malware authors).
  • Articles that are framed in a way that makes it obvious that they are discussing a redteam/penetration test tool*, will likely be accepted.

While some offensive security tools have a lot in common with malware, there are differences as well. For example, a professional offensive security tool has no need for features like "wipe the disk" or "encrypt all important files, then display a ransom message". There are many other differences of course.

Article technicalities

Paged Out! is an experimental zine, which means we have an unconventional approach to how an article must look like when submitted. Two key elements of our approach are:

  • One article must be contained on exactly one page.
  • Article layout is custom and must be provided by the author.
This basically means that while the article is restricted to only one page, the author can actually use most of the page as they like.

Artificial Intelligence Clause

Here at Paged Out!, we are aware of the growing popularity and use of AI. Thus, here is our stance regarding articles prepared using various kinds of AI.

  • What's allowed and accepted:
    • use of AI when polishing the language or deciding how to rewrite or formulate individual sentences;
    • use of AI output in articles about AIs which generated said output or which generate similar output.
  • What's not allowed and won't be accepted:
    • articles that have been partially or fully written or more aptly generated using prompts in AI (like ChatGPT/Bard);
    • images generated by AI other than what's mentioned in the "allowed" section.

Cases not covered and borderline cases will be decided on on a case-by-case basis. When in doubt – e-mail us.

Layout and page size

An article in Paged Out! isn't limited to a typical "2-3 columns of text" layout (though that's an option too of course) - the authors can be more creative about the layout if they think it will benefit the article (think about cool posters, cheat sheets, infocharts, etc.).

Article page layout diagram

One more important thing to note is how we define a page (see also the image above).

In case of our zine a page (or rather the usable area of a full page) is 174mm x 253mm or 6.85" x 9.96" or 493 pts x 717 pts (or 182mm x 253mm aka 7.71" x 9.96" or 515 pts x 717 pts if you really need more horizontal space).


When writing the article, ideally set the paper size to the above dimensions. If your editor supports only standard paper sizes, but no custom sizes, you can try setting margins instead (note: this is only to help you visualize what the article would look like on the page, it is more important for the article to have the correct size):

  • Margins for A4 paper:
    Top: 16mm or 0.63"
    Bottom: 20mm or 0.78"
    Left/Right (ideal): 18mm or 0.71"
    Left/Right (max): 14mm or 0.55"

Note: Page footer will contain the name of the author, as well as links to blogs / web pages / other social media (as per the Author's wish), so you don't have to include this in the article.

Tools (Editors / DTP / etc)

Basically any tool that can generate the proper output format (i.e. ideally a PDF with selectable text) can be used to write and layout the article. That being said, not all tools can meet these requirements. Here's a short (and sometimes updated) list of tools that are known to work well (or known to be lacking).

  • Google Docs - Free, but requires a Google Account. You cannot select custom paper size, but setting proper margins works without a problem. Please use File / Download as / PDF document (.pdf) for exporting.
  • Scribus - Open/Free DTP software. Use version 1.5.4 or newer - otherwise there are some problems with exported PDFs.
  • Inkscape - Open/Free vector drawing software with rich text editing. There are some issues with line spacing on the Windows version though. Please use Save As... PDF when exporting the article.
  • Microsoft Word - Please note you need a commercial (i.e. more expensive) version of Word to be able to submit an article (cheaper versions do not allow commercial usage). No idea if this remark applies to 365 version though.
  • Adobe Photoshop - Please do not use Photoshop! Exported PDFs tend to be pretty weird and pretty large at that (and there is a 50% chance that parts of your text will be rendered as a bitmap by accident).
  • LaTeX - Everyone's favorite LaTeX obviously works well (but be careful not to use fonts on Alladin Free Public License as they disallow commercial usage).
Do you have other comments or recommendations? Let us know!

Character Count

Here are some statistics that can help you plan/control the article size (useful especially if you plan to first write the text and only then lay it out on a page):

  • The maximum number of characters you can reasonably fit on one page using the smallest allowed font size is around ~5300 (~6300 counting whitespaces).
  • We expect most articles to use between 1900 to 3200 characters (that's 2400 to 4000 counting whitespace).

There are no hard requirements on the actual amount of characters on the page.


Obviously the used fonts should be readable (and ideally their name shouldn't start with "Comic" and end with "Sans", though there might be some article topics that justify even that!), and while almost any font meets this requirement, please be careful when selecting a non-standard font.

Please note that the licenses for all used fonts MUST allow embedding in PDF documents as well as MUST be available to be used for commercial purposes. This means it should be OK to use most default Windows fonts if you create the article with Windows software (see Redistribution FAQ - look for "When can I use document embedding"), as well as fonts on open/free licenses like Ubuntu Font License, SIL Open Font License and fonts on GPL license with Font Exception (when in doubt, check the font's license).

(TODO: In time we hope to add a vetted list of licenses and standard fonts that can be used here - probably after the first issue)

Technically, as far as font embedding is concerned, TTF and OTF fonts have a field called fsType (in OS/2 header) that contains usage permission bitmask. If bits 2 (value 4 - "Preview & Print embedding") or 3 (value 8 - "Editable embedding") are set, the font is fine to embed. You can use e.g. FontDrop! website to check this. Note that this doesn't really address whether the font can be used for commercial purposes.

As for the font size, please make sure that the majority of the text of the article is written with a font not smaller than 9pt. That being said, in some cases (e.g. footnotes, subscripts, etc.) you can use fonts down to 7pt.


The use of color is permitted and encouraged, but when creating your article please be mindful of the following:

  • Your article might be printed and read in grayscale. Or displayed/printed on an uncalibrated device, or a device that is just not able to produce a certain shade. Furthermore, the reader of your article might not be able to distinguish between all colors. See this, this or this article for some hints on how to address this in your design.
  • Most of the background in your article should be white, just to save folks some ink. There might be good reasons to ignore this rule from time to time, but in general avoid setting the background to black and font to white for the whole article. :)

What to submit

We accept articles submitted in two forms:

  • PDF (vector where possible, 300 PPI for bitmaps, be sure to set a proper page size) - this is the preferred form as it enables text indexing and text selection.
  • PNG (300 PPI - which translates to 2055px x 2976px for the usable area, or 2150px horizontally for the wider option).

Submission and next steps

Before submitting the article, please read it once or twice to make sure it's in good shape - this will simplify and shorten the review process. Sharing the article with a friend for proofreading and feedback is also a good idea.

After submission, the article will be passed to the Review Board for admission and review. The process from there is pretty standard - the Review Board will usually have some feedback for you and there might be a few rounds of back and forth until the article is ready for publication.

Publication timeline

We'll try to push the article out in the next possible issue of Paged Out!. That, however, might not always mean the very next issue if:

  • There are already 100 articles approved for the next issue. We'll be using a FIFO algorithm here, or actually First Approved First Published.
  • The article doesn’t meet a technical deadline for the next issue. We need some time to finalize an issue, so there will be a moment when we "freeze" it and focus on releasing it.
Once again, in case of any questions or comments, feel free to contact us at articles@pagedout.institute.

A random set of tips

  • Remember that you are not restricted to use typical DTP tools for creating the article. It's fine to write it in a text editor and then format it in e.g. Inkscape. (Not) everyone's favorite LaTeX is another option.
  • Code listings DO NOT have to follow typical style guidelines. As long as your variable/function names are descriptive, all the code can be manually minified to take less space (e.g. multiple expressions in one line, etc.).
  • For high quality screenshots, you can try to increase your system's DPI, so that the application window in question is actually rendered bigger. Not all applications support it, and sometimes the screen is just not large enough, but commonly it yields better results in print than the default settings.