Skip to content

Printing without the print dialog: learning from how Chrome does it

The first idea was to hand printing to the operating system and let people sort out the options. That was a mistake. Here is how we cut the choices down to three, and how reading Chromium's source helped.

6 min read

A printer pushing out a stack of blank pages in warm light, with a hand seen from behind lifting the top page.

6 min read

On Windows, an early version of our printing had a bug we could reproduce. You pressed Cancel or OK, and the print dialog opened again, stacked on top of the program.

Printing sounds like the simplest part of an exam program. You press print, paper comes out. For us it took three stages and one detour through the source code of a widely used browser.

Key points

  • An early Windows version had a bug we could reproduce: after Cancel or OK, the print dialog opened again on top of the program.
  • A general print dialog offers choices that are not real decisions for an exam. We built our own window with three: which printer, colour or black and white, and quality.
  • We read the printing code of Chromium to learn the order of the steps, not to copy it.
  • Our decision record is marked “Proposed” (not yet “Accepted”), and the Mac and Linux option names still had to be checked against real printers. We found no note that closes that point.

Stage one: let the system handle it

The first idea was the obvious one. Create the PDF, hand it to the operating system, and let the system’s print dialog show up. People know that dialog. It has every option a printer could have, and we would not have to build anything.

In the Wails (opens in a new tab) version, that meant different things on different systems. On Windows, an early version asked a PowerShell command (a built-in Windows tool that runs typed instructions) to print the file using “whatever PDF viewer was registered” on the computer. On a Mac, we opened the file in the default viewer and left the printing to the teacher. On Linux it was the same, with a different command.

Look at what we were really doing: we left the user to work it out. Each of those paths put a different screen in front of a teacher, with a different set of options, none of which we controlled.

What went wrong

Our decision record (a short note we wrote when we chose between options) of 14 July 2026 lists the problems:

  • Windows. The dialog that kept reopening had a small cause: it had no owner window, so it did not know which window it belonged to.
  • Mac and Linux. We had no control at all. The file went to a viewer, and what happened next was the viewer’s business.
  • Too many options. A general print dialog lets you choose pages, number of copies, layout, paper size, margins and scale. For us, none of that is a real decision. The exam is already a fixed document. The pages, the paper size and the layout are decided by our own PDF code, and several copies are made earlier, when the exam is generated.

The same lesson we learned with the scanner applies here: if the program already knows the answer, do not ask the user the question.

Stage two: only three choices

We decided on a print window of our own with three choices:

  • which printer,
  • colour or black and white,
  • quality, normal or high.

Nothing else: not a page range, not a scale, not margins. We also decided the program should remember the last printer used. To make this possible we had to do the printing ourselves, because once you remove the system dialog, you have to send the job to the printer yourself.

A desktop printer with three plain round buttons on its front and a few blank pages resting in its tray.

Illustration: a printer, and only three choices to make.

Stage three: how do real programs do this?

Here we did something we should have done earlier: we asked how a mature program does it. Chromium (opens in a new tab), the open-source project behind Chrome, prints on Windows, Mac and Linux. It can print directly, with settings chosen in its own window, and its source code is public.

On 14 July 2026 we read its printing code: the part that builds printer settings on Windows and the part that talks to the printing system on Linux and Mac. The notes from that session are in the project. They also record how: we read the code through Chromium’s online code viewer, with no local copy, because the full source is very large.

What we took from it was a method, not code. Chromium’s code is tied closely to the rest of Chromium and cannot be lifted out, and our decision record says we considered copying it and rejected that. What we learned was the right sequence of steps on Windows: make the printer’s own driver fill in its defaults, put the user’s choices on top, and let the driver check the result. That way we never validate printer capabilities by hand.

What is a driver?

A driver is a small program that teaches the computer how to talk to one device, such as a printer or a scanner. It is like an interpreter between the computer and the machine, and each model usually comes with its own.

On Mac and Linux, Chromium talks to the printing system directly. We chose the simpler route of calling the standard print command with the options, because it avoids pulling in extra libraries. The decision record notes that the exact option names must still be checked against real printers’ descriptions.

What changed in the code

Saved steps in the project history (commits) from those days, all in July 2026, show the path:

  • Windows printing through a built-in tool that draws PDF pages and sends each one to the printer, with no external PDF viewer needed (14 July).
  • The native Windows dialog dropped, and the printer’s settings built directly.
  • Mac and Linux changed to call the print command directly with the chosen options.
  • All the printing code pulled out into a small separate part of its own (14 July), with a note on how to print a real PDF on Windows, “verified working end-to-end against a real physical printer”.

A small follow-up: on 20 August 2026, listing the printers briefly flashed a black console window on Windows, and we fixed that.

What is a project’s history?

A repository is the folder where a project’s files are kept together with a record of every change. Each time someone saves a set of changes with a short note, that is called a commit, so the history reads like a diary with dates. We use it to see what we did and when.

An honest note

Our decision record is marked “Proposed”, not “Accepted”, although the code carried it out within days. It also says that the option names on Mac and Linux still have to be checked against real printers. We found no note that closes that point, so we cannot say it was done.

What we learned

First, removing options is a design decision, not a missing feature. Second, the reason to read the source of a mature open-source project is to learn the order of the steps and the traps, not to copy it. Third, we should have looked sooner.

Read next

Finding the scanner, and taking over its settingsA teacher should press one button and get a scan. Behind that button are a search for the scanner, a list of settings nobody should have to touch, and a Windows firewall surprise.Building Windows software from a Mac: a borrowed computer, a virtual machine and a photo of an errorSchools run Windows. We work on a Mac and Ubuntu. This is how Tziyun B'Rega learned to build and test for Windows, and the photo that taught us the most.

Got something to build? Let's talk.

No sales pitch. Tell us what your business needs and we'll tell you straight how we'd tackle it, or whether you need it at all.

9 stories about Tziyun B'Rega

All 9 stories

"Why can't you just scan it?" How Tziyun B'Rega beganIt started with one email asking a simple question. The studio's account of the first search, a lottery-ticket comparison, a childhood memory of bubbles, and why we built our own reader.How we chose the tools: Tauri, Electron, then Wails and GoWe started with Rust and Tauri, went back to the tools we knew, and ended up with Go and Wails, which we never planned. The lesson: pick tools you can deliver with.Why we left Electron: the exam that moved on the pageTziyun B'Rega printed exams through a hidden Chrome window, and later pages drifted. We tried LaTeX twice, then found Folio, Go and Wails. The project history shows the path.Printing without the print dialog: learning from how Chrome does itYou are reading this story. The first idea was to hand printing to the operating system and let people sort out the options. That was a mistake. Here is how we cut the choices down to three, and how reading Chromium's source helped.Finding the scanner, and taking over its settingsA teacher should press one button and get a scan. Behind that button are a search for the scanner, a list of settings nobody should have to touch, and a Windows firewall surprise.Building Windows software from a Mac: a borrowed computer, a virtual machine and a photo of an errorSchools run Windows. We work on a Mac and Ubuntu. This is how Tziyun B'Rega learned to build and test for Windows, and the photo that taught us the most.A mouse pointer that looked wrong on WindowsThe same program can look different on every operating system. One day the mouse pointer changed on Windows, so we chose our own pointer and learned to test the small things.Watching a school computer from far away: what the logs taught us about small computersTziyun B'Rega sends its logs home so we can see it work where we cannot visit. A small computer in a remote town showed us that a computer's size, and in the end its processor, decides how well the program runs.Offline first, but is it really always offline?Tziyun B'Rega works without an internet connection, but a few features need one. Telling the two cases apart turned out to be harder than we expected.
Accessibility menu

Keyboard shortcuts

Open accessibility menuAlt+A
Accessibility statement

These settings are saved on your device only and are used to adjust the display. They do not change the site content and send no information to any server.