Something we’re often asked about is printing images that run all the way across the sheets of a newspaper, like a series of posters. Setting up a file to print as full spread posters is simple once you know how. But it is so, so hard to explain with words!
I am going to show you how to make a dummy, or mock-up of your newspaper, and then we need never confuse each other ever again.
1. Start by taking some blank sheets of paper. They can be any size or shape, it doesn’t matter too much. You want to have as many sheets of paper as you want to make posters – I’m going to make 3 double sided posters, so I have 3 sheets of paper here.
2. Sketch out a rough version of how each poster is going to look on the sheets.
3. Make sure you also sketch out how the back of each poster will look, if they have any artwork or text on them.
4. Now you should have a pile of sheets that are little rough versions of the pile of posters you want to order from Newspaper Club.
5. Gather the sheets together in the order and direction you want them to be printed in.
6. Now fold the whole pile in half.
7. Ta-da! This is your dummy newspaper.
8. Check through to make sure you’re happy with the order of the sheets – if not, you can rearrange them at this point until you’re happy with the way it looks.
9. Now, take a pen and number the bottom corner of every page. The numbers are the page numbers for your file. So page 1 in your dummy should look like page 1 in your file, page 2 should look like page 2, and so on.
10. Now look through your paper – you can see which page each part of each poster should be in your file.
11. Now you can pull the paper apart and see which page each half of each side belongs on.
So now you know how incredibly easy it is to work out how to make some posters, hopefully we can put an end to the sleepless nights and confused exchanges. However, if you are still unsure, please just drop us an email at firstname.lastname@example.org. I can’t promise we can make this any clearer, but we do always get there somehow in the end. : )
The winter edition of S.P.Q.R, Rob Ryan‘s lovely newspaper is out now. For anyone who doesn’t know, Rob is a British artist who works with papercuts of various kinds. S.P.Q.R. is a tabloid-sized glimpse into his wonderful world.
Today we’re very pleased to announce the full release of the new and improved version of our online newspaper making tool, ARTHR. It’s been in testing for a while, but it’s now the default tool if you go into your dashboard and press “Make a Newspaper“. Hurrah!
As part of this, we’re shutting down the old version of ARTHR, now known as ARTHR Classic. This post details how the shutdown will work, and if you’re still using it, important dates to finish your work by.
As of today you can still make a paper in ARTHR Classic, but it’s not recommended unless you have a good reason. If you do, we’d like to hear about it, so we can see how the new version of ARTHR might meet your needs.
Barring any problems, on 18th March, we’ll stop people being able to make new newspapers in ARTHR Classic. If you’ve already started one before then, it’ll still be editable.
Then, on 1st April, we’ll stop people being able to edit newspapers in ARTHR Classic, and the tool will disappear from the site. On that date your newspaper will be converted to a PDF on our site, and you’ll be able to download the contents as a PDF, InDesign document or a ZIP file containing the stories and pictures.
If you’re working on a paper in ARTHR Classic you’ll need to finish and order it before then. Unfortunately it’s not possible to automatically move your paper from ARTHR Classic to the new version of ARTHR as the structure of the document is significantly different.
If any of that causes you a problem, please let us know and we’ll do our best to help out.
We thought it might be interesting to take you, the dear reader, on a little tour through ARTHR II and how it all works. This post is unashamedly technical, so if all gets a little bit too much, don’t worry: like the Underground at rush hour, there will be another post along shortly.
I will start at the beginning, for the beginning is a good place to start. ARTHR II (henceforth known as ARTHR – the Automated Real-time Text Handling Resource), is our online newspaper layout tool. It provides a drag-and-drop WYSIWYG style interface to make a great looking newspaper quickly and easily. And it’s entirely browser based, with no plugins required, and nothing to download.
It looks a bit like this:
(I know I’ve used this video twice before, but dammit, I’m going to use it again. If you don’t have the time to poke around with ARTHR, it should give you an idea of what you can do with it. If you do have time to have a go, head over here and try it out!)
There are three main components, all of which integrate tightly together.
The backend Ruby on Rails application: handles storage, persistence, integration with the main Newspaper Club site, background jobs, etc.
ERNIE, a Mac OS X/Cocoa rendering server: takes a document layout and converts it into JPG previews or print-ready PDFs
Much of the logic and intelligence in ARTHR runs in the browser, putting it as close to the user as possible to make it as fast as possible.
With so much of the app’s complexity running in the user’s browser, it becomes much harder to track down tricky bugs. To help with this, we wrote our own logging engine, with a server-side component. Browser exceptions are automatically sent over, along with a stracktrace if available, and contextual information like the git revision in use, and the IP address. For persistently tricky browser/OS combinations, we can flip a user’s account into remote debug mode, sending us live log statements, effectively letting us tail a user’s actions and get good diagnostic information.
The backend of ARTHR is quite a slim component, mostly handling persistence, storage of uploaded images, validation checks, and providing a conduit for the frontend to communicate with ERNIE, the rendering engine.
It’s a Rails 3.2 application, running a Postgres database, with Sidekiq for background jobs. We’re making good use of the hstore type to be able to store arbitrary key/value pairs for different content types.
All that sits in front of nginx, running the brilliant nginx-push-stream-module. This lets us handle long-running EventSource/Server-Sent Event connections while still using our standard Unicorn single-threaded Rails server. We just make an HTTP POST request containing the message payload to a specific channel, and it arrives at any clients listening on that channel shortly after. It’s simple, it just works, and keeps the number of server components to a minimum.
When we developed the first version of ARTHR, a few years ago, we used InDesign Server to provide layout, high quality typography with PDF and JPG output. It served us fairly well, but it’s difficult to integrate tightly with, and it’s often very slow. We needed to speed it up by a couple of orders of magnitude, and have much finer information about layout and text flows. It simply wasn’t possible to do that with IDS.
We needed something to let us layout a document, and quickly convert to both JPG (for previews) and PDF. To make things a little more complex, it needs to support CMYK, and integration with a high-quality typography library for things like ligatures, hyphenation and justification.
After working through most of the options, we ended up at Quartz, part of Cocoa’s CoreGraphics stack in OS X. It’s fast – really fast – because it’s designed to run at 60fps on the desktop. Because Quartz maps very closely to the PDF format rendering to a PDF context is fast too. And it natively supports CMYK throughout, something that Skia and Cairo, two of the main open-source rasterisation engines don’t. For typography there’s the Core Text Layout System, a collection of classes for handling typography and typesetting.
Using all this we built ERNIE, the Expertly Rendered Newspaper Internet Engine. It’s an OS X 10.8 application which exposes an HTTP RPC interface, receiving requests for content size calculations, or document rendering, and returning arrays of JPGs or PDF files.
We’re really pleased with the performance. It typically takes ~50ms to render a simple, text heavy document, up to ~700ms for a longer, more graphics heavy document. It’s often 100-200x faster than comparable documents in InDesign Server.
The PDFs Quartz produces have a few oddities, so we post-process them in Ghostscript to improve compatibility with our presses and ensure they’re PDF/X-3:2002 compatible.
Putting it all together
Let’s walk through adding a new bit of text to your document, as an illustration of how this all pieces together.
The user types into the text box and hits save. The frontend immediately sends the new content to the backend for storage. During that request, the backend takes the new content and performs a test rendering against ERNIE, calculating how the text will flow, where the paragraph breaks are, the number of lines per paragraph, etc.
When the request returns, the frontend uses the calculated flow to perform a prediction of where the text will display in the document, and renders the new piece of text in the blueprint. It’s then ready to be moved around the document by the user.
The preview images are now out of date, as they don’t include the piece of text we just added, so the frontend fades them out, and requests a rebuild of them. The backend returns a unique ID for the rebuild request, which the frontend uses to listen for changes in the state of the rebuild, using an EventSource request connected to the nginx-push-stream-module mentioned earlier.
The rebuild request is picked up by one of the background workers which takes the new document structure, including the new text, and passes it through to ERNIE. ERNIE processes the document layout and returns an array of JPG files. These are written to disk by the background worker, and the build is marked as completed. The frontend, listening for changes to the build status, is immediately notified, and requests those JPG previews from the server. As they load, it fades them in and they become visible to the user.
For most users this all happens in less than half a second, end to end. And if the user moves the piece of text around, it all happens again. Of course, the user doesn’t have to wait for the preview images before continuing to edit their document – it’ll keep them up to date as they go.
Hopefully that’s given you an idea of how an application like ARTHR works, all the way through the stack. We’re very happy with the technologies we’ve chosen, and we’re very grateful to everyone who has contributed to all the open source projects we’re building upon.
We’re keen to chat to folks working on similar online publishing tools, and always open to sharing what we’ve learnt. If that’s you: get in touch!
Michael Morrell, an illustration student based in Manchester, recently used our digital format to document the destruction of the former BBC headquarters in the area.
He produced three newspapers for each of the three weeks he spent drawing the ongoing demolition. The onsite illustrations are full of life – it’s a really immersive insight into a few weeks spent on a building site.
His images are bright and bold, and have strong, simple compositions – perfect for newsprint. We think they look great!
If you would like a copy for yourself, you can buy one here.
If we were a different type of company and this was a different type of weblog, this blog post would be about how we’d successfully built a digital-analogue platform and now we’re moving on to the next stage – building (and helping you build) amazing products and services on top of that platform.
But rest assured, this is just a blog post about me, Russell and Tom messing about.
There’s a bunch of stuff we’d like to do this year and we figured the best way to do that was to just make them. Or fake them.
In 2011 Tom made The Telepaper, which was an idea we’d had since the beginning of Newspaper Club where somehow you could click a button and it would auto generate a newspaper from your delicious feed, or instapaper or pinboard or somesuch. Specifically the Telepaper was a tool that converts a Readability Reading List into a Newspaper Club newspaper. A demonstration of the Readability and Newspaper Club APIs. You can find it here on Newspaper Club and here on GitHub.
We talk about this a lot, in the cafes of central London, but realised the other day that we all had different perceptions of what such a product looked like. So we went away and made one. Ordered it in the usual way and then sent it to each other.
They were all quite different. Mine was called the Sunday Stellar was based on the idea that you could get a newspaper made from your Stellar. But seeing as we all follow more or less the same people on Stellar I wanted to make it friends of friends on Stellar. So I made a list of all the people we follow on Stellar, deleted the duplicates and then took faves from those friends’ friends.
Mine was a bit fancier with the layout, big pictures, blocks of colour and stuff, but I made it all with Arthr II. No other graphic design software was used.
Russell concentrated on long reads, stuff you might think would work well in print. Interesting stuff that’s hard to read on a screen. This meant he could only get three articles in a 12 page paper. This sort of feels odd, for no particular reason. Does it matter? Are you ordering a paper by the amount of articles? Is three articles enough?
Tom’s was probably closest to what we mean. Good number of articles, stuff we hadn’t read before, some pictures.
All three of these were made using ARTHR II.
This article about the New York newspaper strike was the one I enjoyed reading the most.
We all used different styling, different fonts, different approaches. We can’t really learn anything from any of this, it’s just messing about. There’s nothing wrong or right with any of these approaches, any of these newspapers. It’s just us poking the prototype. Making stuff rather than talking about stuff. Having actual physical things to talk about. We had to make what we were thinking in order to express it.
We enjoyed this. I think we’ll make more of these. We have a few copies left, so if you’d like one send us an email.
And yeah, I know I need to clean my lens. There are more soft focus pictures on Flickr.
This is Rosie, looking very calm as she works away at the samples.
Hi there, Emily here, just checking in with a quick update for you all.
On Monday we sent out our mailing list with a link to our handy new samples order form. We weren’t prepared for quite how many of you would order samples – we’ve had a… let me see… around 600% increase in sample requests this week, and we’ve been working day and night (yes really!) to get through the backlog. Please bear with us – many of them are in the post, and the rest will be going out over the next few days.
Ok, back to writing address labels – and looking forward to welcoming some new customers and printing lots more newspapers for you all soon!