Hacker News Reader

Comment by bobbylarrybobby | Hacker News Reader

Isn’t zooming in and having text reflow a feature, not a bug, of HTML? PDFs are pretty much impossible to read on a phone because of the endless amount of zooming in and out and horizontal scrolling (unless they were designed for mobile — and then they’re hard to read on a desktop). Never mind users on a desktop who just like their text large for ease of reading — their screen might not be wide enough to fit the text without horizontally scrolling.

As an author, my intent is that the content be easily readable to all readers. I don’t see why I should want or get to dictate the layout and aesthetics to my readers.

View on HN

I think there is a spectrum of commodity vs. artistic mediums in all forms and we often talk past each other when debating the finer points. If your goal is to send out a press release to the public, perhaps layout/aesthetics isn't as important (sometimes it is though so its not a hard/fast rule). In artistic media, especially in magazines and mixed-media books, layout and aesthetics are an integral part of print media. It is inseparable. Just as in music, you don't want to add an equalizer ruining the original intent of the artist, books created by artists in 1890 still are with us in print format - exactly how they were intended to published to readers. But it is entirely different if the "music" is a podcast - I want to use an equalizer to bring up the higher frequencies for better audibility. Similarly, if I am reading a novel on an epaper display and I want to increase the font-size or type, we should allow that as you said.

I agree. What annoys me is when not very artistic mediums like scientific articles force a fixed page layout. It gets even worse when you have to hunt down the relevant figures over the following pages because they couldn't be put on the same page due to lack of space. Also opening a figure in a separate window isn't much a thing either for pdfs.

I definitely prefer to read research papers in html. I like to zoom in a lot when reading a long piece on my computer since it helps me read faster and keeps me from getting distracted. I've been thinking about working on a side project where I convert pdfs to html for academic papers.

One benefit of PDFs for research papers is that you can easily save them to your own computer, build up a library of them, highlight lines with functionality built into most PDF readers. I generally prefer HTML for reading, but PDF has some benefits, too. Granted, most of these features are also available for HTML. But for some reason you need to look for browser plugins in order to highlight HTML pages, whereas in PDF you can just use the feature. And PDF is always about the content whereas HTML also typically contains navigation and other distractors.

I really don't get why mhtml has been discontinued by browsers??

It hasn't. Chrome can still save .mhtml just fine, and will also open them if you copy/paste the path into the URL bar.

What about Firefox ?

It never had support for mhtml, only through an extension that's no longer supported.

Hmm, I might be confusing with Opera ?

Somehow related: I find Snappy Snippet extension (for Chrome) very interesting. It's supposed to let you make a "live" screenshot of a DOM element. Unfortunately, I've not tried it much as I only rely on Firefox in day to day browsing.

https://github.com/kdzwinel/SnappySnippet

What about epub? Under the hood it is basically html, but viewers know to treat it as a written work.

Epub is ok, but it has no support for math equations (practically all implementations just dump them into raster images) and HTML's typography leaves much to be desired.

There are plenty of good reasons why TeX and LaTeX are still the workhorse of scientific publishing in spite of the emphasis on fixed format layouts.

It's much more restricted than html, even less support for animations than pdf.

Regarding a library of HTML documents: https://github.com/gildas-lormeau/SingleFile#install

I currently have Adobe's Creative Cloud All Apps, which includes Adobe Acrobat. I've bought tons of books on Java, Javascript, HTML, C++, etc.

I have installed an extension named "single file" in my browser, which allows me to save any webpage, as it looks right now in my browser, as a single HTML file. Images and CSS is inline, javascript (I think) is removed. Quite handy when you prefer a folder and file based workflow.

Ugh, I really hate when I stumble upon a research paper only available in html and not in a standard two-column pdf - I find it much harder to read in general

What you're saying is enjoying in the fine details. However you can do that only if those details in different parts of the page are not too correlated, so you can zoom in one part of the page, without it really be dependent on some other details somewhere else. In some situations, like say in comic books having to constantly zoom in/out totally kills the artistic impression that you'd have with an actual 2 pages book opened in front of you. Only having a bigger screen can really help with that.

Are you open to the argument that PDFs are not trying to solve the issue that you’re describing?

Depends on what the question is. If we‘re debating pros and cons of document formats, and not solving a particular problem is a con, then not trying to solve that problem doesn‘t make it a non-con.

> Just as in music, you don't want to add an equalizer ruining the original intent of the artist

You might not. Does that mean that music should only be distributed in proprietary formats designed to prevent anyone from plugging in an equalizer?

What about the naturally different frequency response curves of different speakers?

What about room acoustics?

What's a feature in one context can be a bug in another. I get where OP is coming from: when I zoom in and the text reflows, it's easy to lose my place. PDFs don't have that problem.

Also, digital, free-flow media lose basically all sense of space. PDFs are much better for finding a piece of content again later, because I can remember the location on the page and roughly how many pages into the document.

Usually, if you have reflow, you can disable it. However, if you don't have reflow, you cannot usually enable it!

Opera does better, or at least it used to.

Many PDF readers / eBook readers now at least try to reflow PDFs. This often works, though it often doesn't.

Though too be fair, reflowing HTML / displaying it without all the added-on cruft also often fails these days. Tools such as Reader Mode make heroic efforts, but also very frequently fail (or are apparently blocked or have sites blacklisted by tools).

I wonder why browser bookmarks don't save the position.

The answer is likely obvious in that it depends on what content is the visible content at the time of the bookmark, which will further depend on the content itself (it can change since this is a bookmark on an alive web page), page styles, zoom level/scaling, window size etc.

Basically, for a bookmark to fully store a position, it would have to store all of the above (and probably more), and it would only be really usable on the same device as long as the underlying content does not change.

The underlying content of most pages that I bookmark does not often change. And storage is so cheap now that I would even be happy to have my browser save the rendered page whenever I save a bookmark so that when I ask to see the bookmarked page I get exactly what I was looking at. If I want to see what the page at that address looks like now I refresh the page.

And I am almost always on the same device.

Browser bookmarks save position when there is a position to be saved, which is represented in the form of IDs being pointed to by links with a fragment.

Any other scenario doesn't even ensure that the content will continue to exist, let alone have the same structure.

> when I zoom in and the text reflows

Zooming in/out should not trigger a reflow. Only things like changing the geometry of a page or font settings require a reflow.

It seems you're blaming a document format for a UX problem created by an implementation.

A5 pdfs are really nice on mobile and especially tablets. If there were both A4 and A5 pdf renders available more often that would be grate!

For many people yes, if you're dealing with straight-up text.

But so much content has images, diagrams, footnotes, sidebars, meaningful indentation, and so forth, that text reflow often mangles or scrambles or relegates to the end of the chapter/document. And not to mention that reading on a phone sometimes freezes the zoom so you can't even zoom into images when necessary.

When I read a published PDF I'm usually getting a presentation that was carefully thought out for legibility, scale, etc. The locations of images, footnotes, sidebars, etc. all make sense.

And I find that reading PDF's on a phone is actually no problem at all, even on my small iPhone SE 2. Just hold your phone in landscape and zoom so the width of the phone is the width of the text column. Generally it works perfectly well.

So as a reader, when an author/publisher takes responsibility for well-organized and legible layout and aesthetics, I appreciate it greatly.

It is a feature if it works, but whenever the text the text fails to reflow correctly, or an attempt to zoom into a figure causes the entire page to reorganise itself and (worst case) replace the figure, then it really annoying. The fact that reader mode is often the best way to read websites on mobile suggests that either HTML has got this feature badly wrong or has provided features that are being very badly used. In comparison the fairly common two column format of scientific papers is quite readable on my phone after zooming into a column.

I think that reflowing text is perfectly fine for reading fiction which lacks graphs and meaningful formatting beyond section titles.

For non fiction I find reflowed epubs sometimes inferior to a pdf perhaps to a degree more aesthetically than in terms of actual usability which is harder to quantify. Below a certain size this has exactly the defects you describe however I find that on a fairly large wide screen in landscape orientation it is quite readable.

For example a screen 6in wide lend themselves well to reading without zooming. This is largish for phones or smallish for tablets.

Regarding dictating layout and aesthetics for practical purposes most of your users aren't actually dictating much of anything beyond screen size, platform, and zoom level. Just because other settings exist doesn't mean most people use them.

For practical purposes there are small screens where text must be heavily reflowed because not much fits on the screen and screens big enough to show a whole document depending on font size. For most things you want to support the first use case if any portion of your users are going to be on phones which is nearly always true.

This doesn't mean that there isn't a case for designing a non mobile version of content especially if its mostly consumed outside a limited and limiting screen or benefits from such.

It's because we all have different expectations and use-case. A PDF is great if you need to ensure the formatting looks the same on all platform, while HTML and its derivative (ie: ePub) are useful when you have a myriad of display size where you want the text to reflow and maximize the screen usage and readability (font size, etc) without caring too much about the layout.

It would not be hard to read on desktop you can simply show multiple pages like in book you usually see 2 pages. The same concept works if you have place for more pages. Its just not something people do (create PDFs for mobile). Almost all PDFs are meant to be read at approximately the size of DIN A4 for one page. In a time everyone is and should be disencouraged from printing stuff this is not really needed.

for android, ebookdroid in landscape with auto crop pages makes >99% of books readable on any of my phones (with >= 6" screen).

For anyone trying to read pdfs on phone: landscape mode and vertical scrolling.

It should be noted that the usefulness of landscape mode is limited in some docs, such as those with multiple columns or docs which include elements like tables and graphics, specially if you need to look at them while following the text.

The necessity of zooming is a shortcoming of the device, not of the text format.

Zooming seems like an inevitable consequence of how screens and eyes work, what am I missing?

Forget text for a second, if I want to see fine details in an enormous image I'm going to have to zoom in. I normally adjust font size rather than zooming text but it's nice to have both available.

> The necessity of zooming is a shortcoming of the device, not of the text format.

Zooming is a very fundamental usecases, which is linked to the need to analyse some parts of a document with more detail (i.e., look at a graph, a section of a table, etc).

Moreover, accessibility is important. There are plenty of good reasons why even Apple provides magnifying glass apps integrated into the OS and that have their own system-wide dedicated keyboard shortcuts.

Reply on news.ycombinator.com