Hacker News Reader

Comment by crazygringo | Hacker News Reader

Hard disagree. Also the author is arguing against a strawman.

Normal PDF's are simple, reliable, and interoperable.

In contrast to webpages which are actually more often the "clunky", "slow", "stuffed with fluff", and "disorienting" (with scroll hijacking) alternative.

But the strawman is people creating PDF content as an alternative to HTML. Practically nobody is doing that. Virtually every PDF out there is designed to be a printable document first, that is then made available on the web. Nobody is saying "how should we architect our new site -- I know, let's make all our pages PDF's!"

What a truly bizarre article.

View on HN

> Virtually every PDF out there is designed to be a printable document first , that is then made available on the web.

Tell that to Arxiv. Most papers never get printed. Everything is consumed on screen. Yet the layout is completely wrong for screens.

I think browsers should offer PDF reflow as HTML, to adapt to any screen width with optimal font size.

2 pages side-by-side on a sufficiently large screen looks great. I've only seen a few websites that flow text in columns and make graphics pleasant to interact with. Sure, many web browsers have reader mode but it's limited, clunky, and hard to configure.

Web designers have the idea that I want a big column of text running down the center and lots of whitespace to the sides, perhaps with sub-menus. This would look OK if I had my main monitor oriented vertically, but I don't and almost nobody does. As a result only about 50% of my screen space is working and I am constantly scrolling back and forth on long pages if I want to look back more than a paragraph or two.

I've developed a deep dislike of commercial graphic designers as a class of people because they took everything that was annoying about magazines and put it on steroids. Many graphic designers hate text and now we have a million interfaces that look superficially interesting but are deeply unpleasant to read.

The use case for 99% of pdfs is email transfer. They are absolutely superior to sending a clunky, bloated MS Word or CAD document. The web archive is just the final resting place in the process that made them.

Exactly.

With academic articles, I virtually never want to simply read them online.

I need to save them for future reference, read them later when I've set aside time, annotate them, refer back to my annotations four months later...

Arxiv (or JSTOR or wherever else) is just where you get the papers. It's not where most academics are going to be consuming them.

(For consumption, a full-size tablet like an iPad, with a stylus or Apple Pencil, is absolutely ideal.)

Same with electronic part datasheets. I need to be able to mark up and save datasheets along with the other documents which make up the design of a product.

Can I ask what app you use on your iPad for reading PDFs? I use Adobe reader which is pretty good on iOS, but I find Preview a better experience.

I have been maintaining a PDF library this way using GoodReader for about 10 years now. You can connect it to most cloud storage services or any SFTP or WebDAV server, and sync annotations with Acrobat, Preview, Okular, etc. on the desktop. I have still yet to find something this good for HTML or EPUB documents.

> What a truly bizarre article.

Not at all. It would be bizarre if the uses of PDF that the article is meant to address didn't exist, but they do. Just look at https://berkshirehathaway.com for one example.

For a reference, we're a little over a week into the month so far. Yet when I check my browser history for PDFs, there are around 50 entries for August alone. Most of those instances are exactly what the author describes: cases where the format choice led to a worse experience than if that content had existed on a web page instead (or multiple ones). And as annoying as it is to try grappling with the format on a desktop screen, doing it on a smartphone would have been a non-starter, i.e. near 100% bounce rate.

I wish more websites were organized the way berkshire's is. A simple dashboard directory followed by PDFs where appropriate.

My only objection is that I wish more of the content was in PDF, or at least had a PDF options.

https://www.sec.gov/Archives/edgar/data/1081316/000108131619...

When I download a 10-k, I dont want html to review on my phone. I want a PDF to read.

This comment reads like person who has taken a special case (and even then one that only appears to contradict the "other side", even though it really doesn't)—something like having a 10-K in PDF format—and then constructs an entire (and entirely hypothetical) ideal out of it, just so they can relish in spiting the person they're responding to. It's a crummy way to have a discussion and a crummy interaction to force on other people in general.

The website you picked -- Berkshire Hathaway's -- is about as much of a "special case" website as exists on the internet.

So ironically, this comment of yours describes your own original comment far more than the comment you're responding to.

Also, you do realize the Berkshire Hathaway site's PDF's are especially a lot of long printable documents, precisely what PDF's are designed for?

Finally, please don't assume bad faith ("relishing in spiting", "a crummy way to have a discussion") on HN. It's against the guidelines:

https://news.ycombinator.com/newsguidelines.html

> The website you picked -- Berkshire Hathaway's -- is about as much of a "special case" website as exists on the internet.

Only tautologically.

> Also, you do realize the Berkshire Hathaway site's PDF's are especially a lot of long printable documents

In fact, I do realize what the contents of the website I referenced are. Do you have an actual argument for why even in the cases of the printable material, there's any good reason to force people to use the for-print form even when they have no need or desire to print it?

And the site doesn't even fit the characterization here. It certainly has plenty of PDFs made for print, but then it's also filled with stuff like this, which works just as well in HTML as it does as PDF, if not better:

https://berkshirehathaway.com/news/jul0820.pdf

In addition to what crazy-gringo pointed out, I would add that Berkshire did essentially what the article recommends:

>Given PDFs poor usability for online reading, user-experience designers should either avoid using PDFs altogether in favor of presenting content on web pages, or, in cases where a printable PDF is needed, use an HTML gateway page.

I certainly agree that "Normal PDFs are simple, reliable, and interoperable". And yes, virtually every PDF out there is designed to be printable first, and in that context they're pretty great, and the flaws that they do have are mostly flaws created by the choices of the humans who made them.

But I strongly disagree that the article is arguing against a straw man.

Too many websites, especially from either very large organizations or very small ones, when asking "how should we architect our new side", answer "we already have some printable documents... let's make most of our pages PDFs!"

And TFA's point is: that's a disaster.

All restaurant menus in PDF are examples the complaint relates to. The less common case of actually printing a menu is well served by applying a print specific css. There's no advantage of PDF in this case, a menu doesn't need any of the additional sophistication that PDF brings.

To the contrary.

Restaurants create a "source of truth" menu that they print for use on-premises, often daily for seasonal fine dining. That is going to have layout.

Why is the restaurant going to go to the trouble of creating a second HTML version?

I've found that often, when a restaurant has an HTML menu on its site, it's months out of date because it never gets updated.

PDF menus always that are the same as what customers are getting at their tables, please.

This is due to the disconnect in web vs print disciplines. They have a print oriented designer do the menu, and use PDF for print and for web. But invariably on a mobile device it downloads a persistent PDF file, and has a net negative experience as a media type, size is always more bloated than HTML/CSS equivalent not least of which is due to the embedding of fonts in the PDF and superfluous print quality resolution images.

The restaurant industry is poorly served by having these disciplines separated. It's been possible to do high quality printed output with HTML/CSS for a decade if you have a web designer familiar with it, but sadly too many aren't and so the restaurant has the menu done by a traditional print designer.

Unless they want to use the same PDF on the website that they send to the menu printing company. There's no way you are going to order menus from a printer and tell them to "print my webpage".

In fact you can, it's been this way for over two decades. W3C has been working on CSS and SVG print for that long expressly for cross-media print rendering needs.

You can but I wouldn't

Reply on news.ycombinator.com