Two newspapers run a map across their centre pages. The first looks like a screenshot of QGIS, exported. Right scale, right data, but the labels are colliding, the legend is generic and bulky, the colours are screen-bright and clash on paper, and the title is whatever the project file was called. Readers glance and turn the page.
The second looks designed. The labels are placed individually, the legend is hand-tuned to the size of the page, the colours are muted for print, the title is set in a typeface that matches the masthead, and the date in the corner is automatically the current issue. Readers stop. Some of them tear the page out and stick it on the fridge.
The difference between those two is not the data. The data is the same. The difference is the print layout system in QGIS, which is the part of the program that most people never really learn. The canvas is where you do the work. The print layout is where the work becomes a thing the reader will actually look at. They are two different programs, sharing a project file. For the gruvor centerfold, the second one is where most of the next forty-eight hours should be spent.
QGIS has two minds. The main window is the canvas, where you load layers, style them, query them, edit them. The other window is the print layout, and it lives a separate life. You open it via Project, then New Print Layout. A second window appears with its own toolbar, its own menus, its own concept of pages and margins and paper sizes. It looks at the same project, but it does not behave like the canvas. It is more like a graphic design application pointed at your map data.
The mental shift is small but important. In the canvas, you are working with data. In the layout, you are working with a page that will become a printable, exportable artefact. A PDF for the printer. A PNG for the web. An SVG for someone to retouch in Illustrator afterwards. The layout is the bridge from "what is in the data" to "what the reader sees on paper."
A QGIS project can hold many layouts. The Layout Manager, under the Project menu, lets you keep a Centerfold Spring, a Centerfold Summer, a Centerfold Autumn, and a Centerfold Winter, all in the same project file. Each is its own collection of pages. Each can be exported independently. Each can be edited without touching the others. For Årebladet, where the centerfold theme rotates with the seasons, this matters.
A layout is a canvas of fixed paper size with items placed on it. The items come in a small set of types, and you learn the set once and reuse it forever.
The map frame is the main one. A rectangle that shows a portion of the project map, at some scale, in some coordinate system, with some subset of layers. You can have several map frames in one layout, all looking at the same project but at different scales or different areas, which is how overview maps work.
Then there are labels and text. Static strings, or, more interestingly, expression-driven strings that evaluate at print time. There are legends, which can update automatically from the layers in a map frame or be hand-edited. There are scale bars, in a dozen different styles. There are images, for the masthead logo or for SVG icons or for a north arrow, which in QGIS is just an SVG image from a library. There are shapes, boxes, lines, dividers. There are HTML frames, where you can embed actual HTML for fancier text. There are attribute tables, if you want to show a small data table alongside the map.
You drag these from the toolbar on the left. You position them with the mouse or with precise coordinates in the item properties panel on the right. You can lock the position so you do not nudge them by accident. You can rotate them. You can adjust transparency, blend mode, frame, background. The layout system has more cartographic polish than most graphic design tools because it knows about coordinate systems and scale, and most graphic design tools do not.
The map frame is the most important item, and the one that bites you first. When you add a map frame, by default it shows the current state of the canvas. Same layers, same styling, same extent. As you change the canvas, the map frame updates. This is convenient until it is not, because suddenly your perfectly tuned centerfold has an extra layer in it that you only meant for the canvas. The fix is the Lock Layers and Lock Styles checkboxes in the map frame's item properties. Once locked, the layout map is frozen to the layers and styles it had at the moment of locking. You can change anything in the canvas and the layout map will not budge. For a centerfold you have spent hours composing, lock early.
Static text is easy. Static text is boring. The interesting move is dynamic text, strings that evaluate at print time using the QGIS expression engine.
The syntax to remember is square bracket, percent sign, your expression, percent sign, square bracket. Inside the percents, almost any QGIS expression. So if you put a label on your layout that reads format date of now today comma year month day, what shows up on paper is the current date in ISO format. If you put year of now, what shows up is two thousand and twenty-six. If you put the name of the active map frame and ask for its scale, you get the current scale rendered live.
For the centerfold, this matters because the same template can produce different outputs across time without manual editing. Today's date in the corner. The project name pulled from project metadata. The number of features in a layer, computed live. The map scale displayed as "one to fifty thousand" computed from the map frame's actual extent at export time.
The expression engine is large. It has hundreds of functions. Geometry functions for area, length, perimeter. String functions for format, regex replace, concatenation. Aggregate functions for sum, mean, max over a whole layer. Date and time functions. Conditional CASE WHEN logic. The same engine drives expressions in symbology, in labels, in field calculations, in atlas filtering. Learn it once and the same skill applies everywhere QGIS asks for an expression.
A small pattern worth knowing: in any expression context, you can right-click and insert variables. There is a long list of built-in variables like at project home, at qgis version, at user account name. There are layer-specific variables. There are atlas-specific variables, which we will come to in a moment. You do not have to memorise them; the picker in the expression dialog lists them all.
This is the killer feature. The one that, once you understand it, changes how you think about cartography entirely.
Atlas lets one print layout produce many output pages, one per feature in a chosen layer. If your coverage layer has the boundaries of every kommun in Jämtland, Atlas can produce one page per kommun. If your coverage layer has the centroid of every borehole cluster, Atlas can produce one page per cluster, zoomed in. If your coverage layer is a grid of squares covering northern Sweden, Atlas can produce one page per grid square, the way an old road atlas worked.
You activate it on a map frame. Item properties, scroll down, check Controlled by Atlas. Then in the Atlas menu at the top of the layout window, configure the coverage layer, the sort order, the page naming, the margin around each feature. Hit Preview Atlas in the toolbar and the layout starts showing you each page in turn. You can click through them with arrow buttons in the toolbar.
Each page is automatically zoomed to the current feature, with the margin you configured. So if Atlas iterates through Jämtland kommuns, page one zooms to Åre, page two to Östersund, page three to Strömsund, and so on. The map auto-zooms. Any title text using atlas variables auto-updates. The output is one PDF with one page per coverage feature, or many separate files named with an expression of the feature's attributes.
This is the feature that turns the centerfold from a one-off into a series. The pattern for Årebladet: one template, one coverage layer with four features for the seasons, Atlas generates four centerfolds with slightly different focus and dates each quarter. The cartography work is done once. The export becomes a single command.
The coverage layer is whatever vector layer you point Atlas at, but the design of the coverage layer is the design of the atlas. A few useful patterns.
The coverage layer can be your existing kommun boundaries. One page per kommun. Map auto-zooms to each. This is the obvious case.
The coverage layer can be a custom grid you generate with Vector, Research Tools, Create Grid. One page per grid cell. This is how road atlases work, where the country is sliced into rectangles and each rectangle becomes a page.
The coverage layer can be a single-row table with one feature spanning your whole area of interest. Atlas then produces one page, but you still get access to all the atlas variables inside the layout. This sounds silly, but it is a useful trick if you want a layout that uses atlas variables for naming and metadata without actually iterating across many features.
The coverage layer can be a "field" table, one row per attribute column you want to map across. This is a clever pattern that produces the same map repeatedly, but each page renders a different data column. Used for things like one map per year showing house prices, where the data is twenty columns in a single dataset and you want twenty separate pages. The trick involves an expression called eval, which evaluates a string as an expression at draw time. We will not unpack it here, but if you ever need to make twenty maps from twenty columns, search for "QGIS atlas by field" and the pattern is documented.
For the gruvor work specifically. Imagine a coverage layer that holds one polygon per major mining region of northern Sweden. Atlas produces one centerfold-style detail per region. Same template, same legend, same layout, just zoomed to a different patch each time. The build script that generates the project file does not change. Atlas does the multiplication at export time.
When atlas is active, you have access to magic variables in any expression context inside the layout.
At atlas feature is the current feature object. At atlas geometry is its geometry. At atlas pagename is the string used to name the page. At atlas featurenumber is its position in the iteration, one for the first, two for the second, and so on. At atlas totalfeatures is how many features there are in total.
These are usable in any layout expression. So a title like the name field followed by "page" the atlas feature number "of" the atlas total features will render as "Åre page one of eight" on page one, "Östersund page two of eight" on page two. Self-updating. The legend can be filtered to show only features within the current coverage feature. The label text can pull any attribute from the current coverage feature.
There is one more trick that separates amateur atlases from professional ones. The inverted polygon trick.
A common atlas problem: you want each page to highlight the current feature, with the surrounding area faded out or masked, so the reader's eye knows where to look. The technique is the Inverted Polygons renderer.
In your coverage layer's symbology, set the renderer to Inverted Polygons. This is a renderer that draws the area outside the polygon rather than inside. Colour the inverted polygon a semi-transparent white or grey. Now when atlas iterates, each page shows the current feature in full colour, with everything outside it masked by the inverted polygon.
Then set the sub-renderer to Rule-Based, with a rule whose filter is dollar id equals at atlas featureid. This restricts the inverted polygon to draw only on the current feature, so previous pages' masks do not accumulate across the export.
That is the trick that makes atlas pages look like real cartography rather than cookie-cutter zooms. The current feature pops, the context recedes. It is the same visual technique you see in newspaper map insets where one country is highlighted against a faded continent.
The default atlas zoom mode is "margin around feature": the map auto-scales so the current feature fills the frame with some configurable padding, typically ten percent. This is fine for irregular features but produces inconsistent scales. A big kommun like Strömsund might render at one to four hundred thousand, while a compact one like Östersund renders at one to a hundred and twenty thousand. The pages no longer compare directly.
For a professional atlas, you usually want consistent scales. Two options.
Fixed Scale. Every page is at exactly the same scale, say one to a hundred thousand. Some features may not fit, others may have lots of empty space, but the scale bar is constant and comparing one page to another is meaningful.
Predefined Scales. You give Atlas a list of allowed scales: one to fifty thousand, one to a hundred thousand, one to two hundred and fifty thousand, one to five hundred thousand. Atlas picks the smallest scale that still fits the current feature. This gives consistent visual feel across pages without forcing one universal scale onto features of wildly different sizes.
For the gruvor centerfold, fixed scale is probably what you want at print scale. The whole point of a printed comparison is that two areas at the same scale are directly comparable. If you want one detail callout zoomed further, do that as a second map frame inside the layout, not by changing the main scale.
The print export has its own truths. Newspapers want at least three hundred dots per inch. QGIS exports at three hundred by default for PDFs, but it defaults to ninety-six for PNG. Set the PNG export to three hundred manually every time, or you will hand the printer a fuzzy file and find out at the worst possible moment. For SVG, choose "Always export as vectors" if the downstream tool is Illustrator or Inkscape and the designer wants to refine paths.
GeoPDF is a special format worth knowing. It is a regular PDF that also carries the coordinate system metadata inside. A reader using a GeoPDF-aware tool can click on the PDF and get latitude and longitude back. For a centerfold map that someone might overlay on field GPS or import into another mapping tool, this is hugely useful. QGIS exports GeoPDF natively as a checkbox in the PDF export dialog. There is almost no reason not to tick it.
There is a second feature most QGIS users miss: the Report. It lives next to Print Layout, under Project, New Report. It is for when one atlas-style template is not enough.
A Report is a tree of sections. Each section can contain a static layout, or it can iterate across a layer the way Atlas does, or it can be a header or footer or cover page. So you can build a document that has a cover page, an introduction layout, a section that produces one detail page per kommun, a summary statistics layout, and a closing page. All in one export, all from one Report file.
For a thirty-page printed report on the mining activity across northern Sweden, this is the right tool. For a single centerfold spread, Atlas in a regular Print Layout is enough. But it is worth knowing Report exists, because the moment your single centerfold grows into a four-page pullout, you will want it.
All of this can be scripted. The class is QgsLayoutExporter. Common pattern: load a project that already has the layout configured, get the layout by name from the project's layout manager, set up an exporter, run an export. About fifteen lines of Python.
The atlas case adds a few lines. The layout's atlas object has methods for first feature, next feature, and so on. The exporter has a dedicated export to PDF for atlas method that takes a folder and a filename expression. The whole pattern is documented in the PyQGIS Cookbook under the Layout chapter, and the cookbook is the place to copy from rather than asking an AI to guess.
This is what makes the gruvor build script genuinely powerful. Not only does the script build the project from scratch with the right layers and the right symbology, it can also re-export the centerfold to PDF at the end, without anyone clicking anything. You can wire it into a git commit hook, a cron job, or a manual command. The whole centerfold pipeline becomes idempotent and reproducible.
The pattern for the Årebladet workflow: one Python script that loads the latest data sources, refreshes the project, sets the atlas page title expression to include the current issue date, exports a three hundred DPI GeoPDF to the deliverables folder, and exits. The quarterly centerfold becomes a single command. You spend the time on the cartographic decisions, not on the export clicks.
Putting it together. Imagine a recurring centerfold series called "Jämtland från ovan", Jämtland from above. Each season, one centerfold focused on a different region or theme.
The build pipeline. A coverage layer with one feature per season-theme pair. Vinter Skidor, Vår Älv, Sommar Vandring, Höst Svamp. A single layout template with Atlas configured against that coverage layer. Data layers swapped in via the Python script based on the current season. Inverted polygons highlighting the current feature, with the surrounding kommun faded. Fixed scale at one to two hundred thousand so the four issues compare directly. Three hundred DPI GeoPDF exported automatically, with the filename pulled from the atlas page name.
Four issues a year. Four centerfolds. One template. One script. The QGIS work is done thoroughly in Mörkret tomorrow, once, and the pipeline runs every quarter without further intervention.
The mining engineer in Alaska made a viewer for his own data. Twenty-four years later, his viewer is the cartography engine for a local paper in Jämtland, producing centerfolds for an audience he will never meet, in a kommun he will probably never visit. That is not a small thing. That is the whole story of open source software in one specific corner of one particular newspaper.
Next time you open the print layout window, treat it the way you would treat a designer's workspace. The data is just the material. The page is the artefact. Atlas is the multiplier. Give the layout the time the centerfold deserves.