Creating student magazines with LaTeX and Bonaparticle

It’s often said that “Nobody likes MIT (side note: Massachusetts Institute of Technology). People respect it.” That is kind of how I feel about LaTeX. It’s part of a system that feels very outdated and can be hard to get into, but if you manage to get through the initial hurdles it lets you create some pretty awesome stuff.

Unfortunately, none of this really matters if you are dealing with a student-run magazine that relies heavily on customised lay-outs and custom scripts that are needed to compile documents and only accessible via the university’s network. Not to mention that its editors only work on the magazine several times per year, and some don’t even use “normal” LaTeX for their course assignments.

Consequently, most editors spent quite some time on rediscovering all the default and custom commands that were needed to produce the magazine’s copy.

Then there was also the additional work that had to be done by its final editor (yours truly), who was tasked with the compilation (side note: And final editing, because that’s what final editors also do…) of the web and print versions of the magazine using commands that weren’t really known among the rest of the editorial board. This meant we had a very low bus factor!

To top it all off, the magazine looked incredibly LaTeX-y, which is appropriate for things like scientific books and papers, but maybe less than ideal for a magazine that’s not supposed to take itself very seriously.

It was clear that something needed to be done, so we decided to investigate new tools that were suitable for magazine production. The obvious choice would normally be Adobe InDesign. However, none of us had ever worked with it at that point, it was insanely expensive and wasn’t supported on Linux, which was the organisation’s de facto main operating system.

Microsoft Publisher wasn’t a viable alternative for the same reasons. Scribus, a free and open-source desktop publishing application, was one of the few alternatives that met our criteria. After a brief (but successful) trial run we decided to make the jump to Scribus, with a new design.

Our readers were happy with the fresh new design.

We were not. Yes, Scribus offered us a lot of freedom, but things now also took a lot longer than we were used to – especially articles that included equations and mathematical symbols (side note: Since most of us read mathematics, physics, or both, that’s a lot of articles!).

We also learned that Scribus turned out to be ridiculously buggy. It often wouldn’t do what it was supposed to do, it crashed repeatedly, and files that had been worked on by one editor would sometimes look very different when opened by another editor – that is, if Scribus would open them at all.

To circumvent these issues much of the work on layouts was shifted from regular editors to the final editor (still yours truly). Since the position now came with a lot more responsibilities and virtually guaranteed all-nighters, very few people were eager to succeed me.

I had inadvertently lowered the editorial team’s bus factor to 1!

Because I wasn’t planning on staying the final editor forever, I went back to the drawing board. Any new solution would have to meet the following requirements:

• It should be based on LaTeX, because it’s what virtually every editor already knows and will need at some point anyway to typeset math.

• Every editor should be able to compile anything (articles or even the complete magazine) on their own machine using their own tools and their standard workflow.

• The new solution should be so simple that anyone can create decent-looking layouts, even if they have no prior experience with LaTeX.

• Readers liked our new design, so the output of our new solution should look roughly the same.

The result of all this thinking (and subsequent building) was a set of two LaTeX classes: bonaparticle and vakidioot. bonaparticle is an open-source LaTeX class that provides the building blocks you need to create your own magazines, while vakidioot is a proprietary class that includes theming for the magazine of the same name.

The latter is accompanied by a user manual that includes:

• Installation instructions for Microsoft Windows, Mac OS X (side note: Apple has since renamed Mac OS X to macOS.), and Linux (although the class still comes pre-installed on the organisation’s computers, so most people won’t ever need to do install anything themselves).

• A couple of cheatsheets that are designed to help both novice and experienced LaTeX users typeset articles or even the entire magazine.

• A pattern library with examples of common layouts that editors may want to use for their articles. Each pattern comes with its own name, a brief description that tells users when it is should be used, an example that can be copypasted, and a screenshot that shows what the pattern looks like in practice.

• A succinct overview of the two document classes that describes how they are implemented.

The result is something that might look like a small change from the outside, but provides a lot of “quality of life” improvements to editors.