alt Hacker NewsWebsites Should Be Printable
Comments
I politely disagree. The original intent Tim Berners Lee had [1] was to create a navigable way of finding documents and information. Not printable. The entire issue we have today is that we have blurred both the navigable and the printable concepts. A website should just be a simple clean space for easily navigating and conveying intended information. To print, we have latex and other markup methods that are perfect for that.
Hilariously, when I hit CMD-P on this specific website, I end up with 4x pages: the first is 80% blank, the 2nd page is fairly nice, the 3rd page contains just the CSS code sample as a thin strip on the left-hand side, and the last page is again mostly blank space...
I also attempted something like this, but only to format my resume[1], since many employers require it to be submitted as a PDF
I agree that websites should be printable. I'm a fan of RSS and eInk displays (Kindles, and when I can afford one, a PC monitor), and printable websites would make using them on paper-like displays easier.
I've been using the PrintFriendly [1] browser extension for years (to print otherwise unprintable websites), but it gotten worse, so while looking at alternatives I started with The Printliminator [2] (which uses the Haartija CSS framework [3]) and have currently ended up using CopyAsMarkdown [4] (with Pandoc) and WebToEpub [5]
[1] https://www.printfriendly.com/ [2] https://github.com/CSS-Tricks/The-Printliminator [3] https://github.com/vladocar/Hartija---CSS-Print-Framework [4] https://github.com/yorkxin/copy-as-markdown/ [5] https://github.com/dteviot/WebToEpub
If I'm totally honest, this feels like somethign that'd be quite low on my priority list. I'd muchrather focus on the on-screen UX and accessibility if I have limited time. I think making things printable makessense in certain contexts, and I think could actually replace a lot of the pDF generation sites do for things like tickets, invoices, etc.
I personally think printing unless absolutely necessary is a waste of resources.
One issue with making websites printable is that printing, by default, removes background colors and images. So, for the chess diagrams I have on my webpage, I use background colors to have the chessboard be a checkerboard instead of a white background (the chess pieces are a color webfont)—but since web printing removes backgrounds, the chessboards have white backgrounds unless the person printing the webpage chooses “print backgrounds”.
The only way to work around this is to have two sets of chess pieces in the font, one with a white background for pieces on light squares, and one with a colored background for pieces on dark squares.
Printing web pages is rare enough I just assume someone doing that will also click on “print backgrounds”.
(The reason to not use images for the chessboard diagrams is because they use more bandwidth and can’t have usable “dark mode” colors)
I've periodically struggled with an HTML resume that can be converted to a PDF using chrome headless / puppeteer wkhtmltopdf, and looks good both on screen and PDF/printed.
Admittedly I'm not an HTML/css guru, but I know a bit... and it really feels like it shouldn't be this hard / require so many tricks to get it working even half ok.
The biggest issue is that the pages kind of fight against the DOM structure of the HTML. Like lets say I have big:
<div> <h2>Experience<h2>
<div> <h3> Job A </h3> <p>Description</p>
<div> <h3> Job B </h3> <p>Description</p>
<div> <h3> Job C </h3> <p>Description</p>
<div> <h3> Job D </h3> <p>Description</p>There isn't really a good way to say...
* Keep "Experience" and "Job A" on the same page.
* Don't break after Job X / before Description.
* Don't try to keep the whole toplevel div on one page by breaking before, just break within it, sensibly.
Whatever tweaks/hints/hacks one applies to achieve that tend to be pretty brittle across browsers/page sizes/etc.
It's very tempting to just give up and go back to... something actually page-centric like word, pagemaker or whatever, instead of HTML and then having print as a second class citizen.
Oh, wow, that's one naive print.css
Missing things like resizing media to not occupy everything, blocking certain elements from getting broken up, and so on, wrap when needed, printing links (sic), etc
The latter is why I moved links into footnotes instead of inline linking - also to prevent breaking up the reading flow.
Also: adding page counters is virtually impossible.
Anyhow, I do think it's a good idea, but mostly for archival reasons: if you really want an archival copy, you'll need to print it.
https://tuhat.net allows you to set a page size for your post and input hidden page breaks for when people download the epub version or print your posts, it doesn't affect the web version.
There is also a zine booklet mode which works out page imposition to print out a zine (eg. double sided, folded in half)
Click the printer icon on any tuhat post.
My read is that a lot of content - specifically of the infinite-scroll variety - is very intentionally not designed to be printed.
There are a number of Slack and Discord conversations I'd have liked to export off to PDF, for instance (where a solid 90% of my "prints" go). I'm reminded that one of Slack's boot messages used to be, "Consider the environment before printing this Slack."
I have been loosely involved with very specific ‘web2print’ practices, aka using web technologies (html, css but also web as space for collaboration). For example: octomode [0]
>Octomode is a collective editing space for PDF making, using Etherpad, Paged.js and Flask.
> Here's the functions this does for me, in order:
Is for anyone else, the text that follows, unreadable black on almost black background?
Printability is not important to me per se, but one property that comes with it: A natural linearization of the whole site. Sites that could be read like a book show that their authors had the whole in mind and as a top-down person that naturally appeals to me.
We use a SaaS ticket management tool (like Jira) for internal company use to track projects, requirements, software designs, etc. The tool is hopelessly unable to generate a sensible export or print to pdf for archiving pages to share with customers or auditors. I’ve had to resort to stitching screenshots together in MS Paint to create the offline evidence documents that I need.
When I want to save a page for myself I usually use the PrintFriendly (https://www.printfriendly.com/) plugin to save to PDF, minus the cruft of images and ads.
This way, I've built an archchive of useful pdf's that are now (since they are clean text) fully indexed and searchable on my devices.
I'm currently working on rebuilding my personal blog from Jekyll set up about 10 years ago in Astro. One of the things I've also been doing is setting up a resume page designed to print to PDF, which I find a lot easier to maintain and format than the LaTeX resume I've been using forever.
Printing a web page (or a PDF) is not unreasonable provided the content is two pages or more and it's something that invites itself to depth and close reading or some sort of value like ordinary print.
Your everyday blog is not worth the cost or effort. Nor is a Wikipedia entry.
I hate paper, but it's probably still worth it for being able to easily convert to a PDF. It's not that hard to do if your website isn't a hacked together mess to begin with.
Maybe only websites with content that should be printed... Like sudoku and puzzles and stuff. As for the rest of them... IDK if I don't intend on reading something on an airplane there's no reason for me to print it
Everybody is focusing on responding to the title
but I thought this bit was far more interesting:
> I read a lot of printed papers these days. While I enjoy reading on a laptop as much as the next guy, marking up a printed document engages me better. Also, there's something about sitting with a whiteboard and a printed document that makes me rightly feel like I'm doing something important.
would be interesting to consider a totally new workflow of automatically printing off any "read later" stuff, including interesting HN posts.. and then actually sit down and read the paper, no distractions.
Can't the website just lay itself out for print differently?
Nope, let’s keep printers in 2004 where they belong.
I have used CSS for print layouts before. My stance on this is: If you can reasonably expect someone will print your website or (more likely) parts of it, because of its nature, add a nice add free, no tracking cookie print layout. If not, don't.
I often have to print for example online shopping baskets so others can decide which offer they will take. Meaning how your shopping basket looks print absolutely will have an impact by annoying or pleasing the people who make the decisions. Needless to say, 99% of all shopping baskets look like trash when printed out.
If you have a blog, it would be reasonably that someone might want to read your article offline or store it for archival purposes. Having that look decent is not a bad thing. And it is not that hard.
hell no. paper is such a waste of material. use eink if you hate lcd/oled that much.
Websites should be usable first. Open this one on a phone and see what happens
There's black-on-black text for me for `onlyprint`.
I'm building a side project that turns a batch of articles I bookmark online (e.g. here on HN) into a personal printed magazine that I can then read offline [0]. I definitely underestimated the amount of post-processing I have to do because many websites are not printable. Thankfully LLMs are helping with that.
paper should be banned
I don't agree, because I just like websites that are full of moving animations... For websites that provide information, I agree, but honestly I think you have to give what matches the target audience of the website. I've always wanted to have a moving book like the magic books in Harry Potter. So I prefer homepages with as much motion as possible.
Some people see a website as a medium for reading, like this person does, but to me a website is a medium for experiencing. I find websites where the elements interact with each other fun. I like fun websites. Of course, you could strip out the animations and just show a print-style document instead, but in the end, having a particular philosophy comes from freedom. A website doesn't have to be quiet and efficient. I'd actually rather websites be fun. There are plenty of media for reading—PDFs, for one.
Today, my only two devices consist of an Android 17 Pixel, and a Chromebook. The printer drivers in each of these OS are shockingly rudimentary. Like, there is no affordance to connect to the printer and configure its settings, or monitor its status, or run tests or anything. The only printout options are so basic: I can perhaps choose 2-sided, and perhaps what size paper, but there are, max, about 5 parameters on the Print dialog.
This was something that sort of escaped my notice until I finally had to replace my 2011-era HP printer. I chose a SOHO HP printer, and basically, it can't properly print anything, not even 2-sided, unless I go through the Linux subsystem on the Chromebook. This is fine, because I seldom print stuff, but it's just emblematic that neither ChromeOS nor Android really wants anyone to print anything, ever at all.
When choosing to replace my printer with a modern one, my other option was to not replace it at all. I could easily upload documents and print them at the UPS Store, or Staples, or FedEx Kinko's, the public library, or a pharmacy photo department or something. There is not a shortage of outsourced print shops around here. Perhaps I spent way too much money on a SOHO model. But at least I can scream and rage at the printer drivers in the comfort of my own home!
fun fact: you can use mm/cm or freedom units in CSS [1]. YMMV outside of printing though, at least on low-DPI devices the rendering results might not make too much sense. If you're really adventurous, CSS offers even more dedicated printing functions such as pagination [2].
[1] https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/V...
[2] https://developer.mozilla.org/en-US/docs/Web/CSS/Guides/Frag...
[flagged]
[flagged]
[dead]
[dead]
[dead]
While I'm on board with having good html structure that prints well, and I'm on board with hiding navigation elements, etc., I'm not so on board with changing the default font size or fonts in the print version.
I just made a simple site that didn't set any font sizes anywhere, and a friend of mine complained that the font was too small on mobile. Do I detect a lo-res screen and increase the font size?
I know a lot of sites do exactly that, but I feel it's wrong. The user controls their default font size on their platform. What if they'd already increased it, and now I'm just making it bigger?
What if they'd decreased their default print font size and then I shrink it again?
I think it's best to leave those to the user entirely.