DEADLINE for Article / Art submission for Issue #10:
30 September 2026 EoD AoE
Support Paged Out! on Patreon!
patreon.com/PagedOut

Writing Articles

This page is full of information, tips&tricks, and requirements regarding writing articles for Paged Out!
It’s a must read for first-time authors (but can prove valuable for veterans as well) to make the writing and submission process easier and smoother.

An overview of the writing, submission, and review process can be found here.

This page also addresses the questions on what kind of topics are accepted into our zine and how to technically prepare the article.

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.

Article topics

Let's start with the most important question - what to write about?

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.

If you have additional questions, or feel your topic might not exactly be what Paged Out! usually publishes, and want to make sure before you commit to writing, send us an e-mail at articles@pagedout.institute.

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

Here are some shortcuts to the most important contents of this section:

Examples of topics aligned and not aligned with Paged Out!

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

Policies

0-day 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.

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.

Templates, layouts, and page sizes

Here's an overview of the contents of this section:

Templates

We offer ready-to-use templates. Feel free to use them to speed up and ease the writing process.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 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.

Layout and page size

First things first, one thing to keep in mind is that the article layout is custom and must be provided by the author.

At Paged Out!, we are not confined to the traditional 2-3 column setup, our authors can be as creative as they want to be as long as the layout fits on the usable space of our zine’s page. So, you have one page to showcase your article, but you can go wild with it.

Since the article has to fit on one page, let’s start from defining what we mean by that.

In case of our zine a page (or rather the usable area of a full page) is 182mm x 253mm aka 7.71" x 9.96" or 515 pts x 717 pts.

Remember to also account for the header and footer on the page.

Article page - right side

Article page - left side

Margins

If the editor you are using does not allow to set up the page size to the ones specified above, you can always use A4 page with the following margins:

  • Margins for A4 paper:
    Top/Bottom: 22mm or 0.87"
    Left/Right: 14mm or 0.55"
  • Margins for US letter:
    Top/Bottom: 13mm or 0.51"
    Left/Right: 16mm or 0.63"

The margins can be used to visualize what the article will look like. Remember that the correct size of the article is more important. You can check whether the article has the right size using our cool little tool - PDF checker

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.

Fonts

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.

Links

When including links in your article, be sure to include text URLs as well — this is because Paged Out! is also printed and clickable-only links don't work well in printed versions. ;)

There are a couple of ways you can go about it:

  • Full text links: https://example.com/asdf (if the prefix (protocol/schema) "https://" you can omit it: example.com/asdf)
  • URL in parantheses: Clickable Link (https://example.com/asdf)
  • Footnoes: Clickable Link1 and then at the bottom of the article (or wherever you have space):
    1 https://example.com/asdf
  • Per-link QR-codes (this requires a lot of space though).
  • One more way (not recommended) is to have just one link/QR-code to a website where all the other links are gathered. The reason this isn't recommended is that you'll have to maintain this website for the next centuries (sic!!!) to make sure the links are still accessible in the future. On the flipside, the links will be in the PDF version anyway.
  • You can also go about it another way — the above are just some examples.
Colors

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 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. :)
  • If you go for dark/black background and white text, use a slightly larger and bolder font. This is because on some inkjet printers on some papers there might be feathering effect, i.e. the ink from the dark/black background would slightly flow into the white empty areas that make the actual text, which in turn would make the effective letter size a bit smaller and thus less readable.
Graphics

You can add graphics to your article (or your article can be a graphic itself, chart, comic, diagram, etc.] Some rules and restrictions apply here too. Best are graphics that you are the author of, but you can use graphics that have the right license that allows for their commercial use. AI generated graphics, due to a lot of ambiguity and controversy surrounding it, are not accepted.

Remember to include and properly cite the source of any used graphics (according to the requirements of their licenses).

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.