Quirky TidBITS Issue Printing Problem Solved

It’s uncommon for people to want to print TidBITS issues, so I was surprised when Lauri Reinhardt, who helps us with support, forwarded me a message from a reader asking if there was a way to print the email issue of TidBITS with all the images. Neither of us had ever tried to do such a thing, but the reader was entirely correct: printing a TidBITS issue or exporting it to PDF resulted in blank boxes in place of the images. 

Tinkering with Mail’s Protect Mail Activity setting made no difference, and the images showed up fine in the message itself—it wasn’t related to loading remote content. Even more confusing was the fact that Mimestream, which I use with Gmail, suffered from the same problem, but only in macOS 12 Monterey, not in macOS 13 Ventura. Printing from Gmail’s Web interface also worked fine.

A look at the raw source of our issues revealed a smoking gun right away: a loading="lazy" attribute for every IMG tag in articles. The sponsor banners at the top of the issue lacked that attribute, and they appeared in PDFs fine. Curious, I turned to Mimestream’s developer, Neil Jhaveri, who used to work on Mail at Apple. He said that Mail generates an offscreen web view, waits for the “load” part of the document to arrive, and then “prints.” But loading="lazy" causes images to load only when scrolled into view, which never happens with printing. Mimestream shared the problem, at least in Monterey, because it uses WebKit for printing, just like Mail. Neil recommended dropping the loading="lazy" attribute because he didn’t think images (at least those with width and height attributes) would block the page from rendering until loaded anyway.

During these conversations, Lauri stumbled upon a workaround that makes sense in the context of Neil’s explanation. She postulated that perhaps the images were too large to load, so she tried shrinking them with the Scaling option in the Print dialog, which caused at least some images to display. I did testing and found that if I changed the scaling percentage to 99%, some images would load—but they’d be fuzzy—and others would remain blank. However, if I changed the scaling percentage more seriously, such as to 87%, and then scrolled through the entire document preview, all images would appear crisply in the resulting PDF, even if I later returned the scaling to 100%. Presumably, asking the Print dialog to scale the output forced WebKit to load all the images, allowing them to appear.

When I asked our developer Eli Van Zoeren to remove that loading="lazy" attribute from the IMG tags, he noted that WordPress inserted it automatically, so he added a filter to remove it from the email versions of our issues. (His code adds the sponsor banners to the issue separately, which is why they lack that attribute.) I was excited to test the fix with the next week’s issue, only to be disappointed to discover that the problem hadn’t gone away. It turned out that, after Eli filtered out loading="lazy", WordPress replaced it with a similar-sounding attribute decoding="async". After another round of Whack-an-Attribute, the problem disappeared for good.

So, while I don’t recommend printing TidBITS issues—we don’t format them for print, and they’ll consume quite a bit of paper—you’ll at least see the images now. Interestingly, both screenshots above have extra blank pages at the end. I don’t know why Mail adds them, but I recommend removing them. Choose File > Export to PDF, open the file in Preview, select the blank pages (and any other unnecessary pages) in the sidebar, and delete them before printing.

I very much doubt that many people were affected by this problem, but at least one TidBITS reader will be happier, and with luck, others who run into a similar problem will find this article and figure out how to solve it more quickly.