This page tries to address two questions:
- What kind of topics are accepted into our zin?
- How to technically prepare the article?
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 email@example.com.
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.
Feel free to use these templates for the articles. Feel free to NOT use them and create your own layout too!
Template donations for other software / other layouts are most welcomed!
Paged Out! is a deeply technical zin 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 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 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 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 zin (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; when determining whether to publish articles about 0-days we'll use the following rules:
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).
- 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.
Paged Out! is an experimental zin, 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
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.).
One more important thing to note is how we define a page (see also the image above).
In case of our zin a page (or rather the usable area of a full page) is 174mm x 252mm or 6.85" x 9.92" (or 182mm x 252mm aka 7.71" x 9.92" if you really need more horizontal space).
We arrived at this result by starting with the common area of A4 and US Letter paper (that's 210mm x 279mm or 8.3" x 11"), and then subtracted the following areas:
- top 7mm or 0.28" for the page header,
- bottom 20mm or 0.79" for the page footer,
- and horizontal margins - that's 18mm or 0.71" per side for a safe margin, but we can probably get away with only 14mm or 0.55" - thus the wider option mentioned above.
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:
- Margins for A4 paper:
|Top:||16mm or 0.63"|
|Bottom:||29mm or 1.14"|
|Left/Right (ideal):||18mm or 0.71"|
|Left/Right (max):||14mm or 0.55"|
- Margins for US Letter paper:
|Top:||7mm or 0.28"|
|Bottom:||20mm or 0.79"|
|Left/Right (ideal):||21mm or 0.83"|
|Left/Right (max):||17mm or 0.67"|
Note: Page footer will contain the name of the author, as well as links to blogs / web pages / other social media (as per Author's wish), so you don't have to include this in the article.
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 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.
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 firstname.lastname@example.org
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.