Printing Web Maps
As NYC Planning Labs grows and we create new impactful tools for urban planning, we’re also continually improving our existing products. We do this by first listening to our users. We hold regular demos to gather input. We visit agencies and external organizations to observe real people using our tools. We monitor feedback channels like Slack, GitHub, and Twitter.
There’s one user story that’s become very clear:
“I want to print Zoning & Land Use maps that are specifically designed for the web.”
Whether printing on paper or saving to PDF, users want to print maps. There’s an abundance of information in our mapping applications, which allow users to turn on/off layers and visualize the data in countless ways. We consider this in how we engineer our URLs. Our apps use hashes and query parameters to keep track of every change a user makes to the map — including the zoom, pitch, bearing, which layers are on, and other layer group settings.
So if you change a map to visualize a specific subset of data, you can copy or save the updated URL, reload it later, or even share it with colleagues and be sure that they’re seeing the exact same thing you are. This is a powerful way to share data visualizations. But users often need to share data offline, in meetings or presentations, or with others who may not have access to a web browser. To do so, they print.
The challenge with printing web maps
Printing a web map can yield unpredictable results. Often, user-defined printer settings conflict with page layout. Maps can look completely different once printed than they do on screen. One particular challenge is the responsive nature of our apps.
Planning Labs uses Foundation to style its apps. It has built-in print styles. Foundation’s responsive layouts are defined by a set of breakpoints (screen sizes) at which the display and orientation of content are adjusted. You configure which specific breakpoint will include print as a media type so that the printer will use the page layout for a particular screen size. Unfortunately, this doesn’t work so well for maps.
When you print a web map, print styles adjust the page layout to fit your paper. But the map remains the same size as it is in the screen layout — either overflowing or not filling its allotted space in the layout.
The map is programmed to size itself correctly when it’s loaded on a particular screen, or resize itself when you resize your browser window (using the window.onresize event). But there’s no way to trigger this map resize when printing determines the page layout.
Paper CSS to the rescue!
The solution to this printing problem is to have a predictable print layout that’s previewed on the screen before you hit the print button. Paper CSS is a small snippet of CSS that lets you set the page layout to a specific paper size. When Paper CSS styles are applied, the map is the exact size it should be when you send it to the printer.
Recent updates to our Zoning & Land Use map (ZoLa) included this new approach for printing. The ZoLa print button now applies Paper CSS styles to the screen layout and exposes a few settings that allow you to configure the print layout to match your printer.
ZoLa’s new print settings allow you to change the size and orientation, or show and hide parts of the layout. If you want to print on a tabloid size page, toggle the size. If you don’t need a legend, hide it. You still have the opportunity to pan and zoom the map so it looks just how you want it to print. Then just click print, and make sure your print setting match what you defined in the preview.
WYSIWYG printing! 🖨 🎉
A great thing about the code change:
This new print feature didn’t require extensive markup changes. There’s no new view in the app for the print preview. We simply have a button toggle a query parameter and a couple classes in the layout. Paper CSS (and some other custom styles) handles the preview.
