Hacker News Reader

Comment by systemvoltage | Hacker News Reader

There is something really pleasing about reading PDFs. It’s perhaps how static it is and it won’t change on me. I can zoom in or “operate” on it without some reorganization. It puts the mind to ease. There is no reflowing. There is no columns shifting. It’s just is. Like a piece of paper as an analog - the intent of the author and the designer is retained and frozen in time. Fonts are embedded and chosen by the creator. Haters of PDFs do not understand the human aspects of it - they just see it as a specification (which is convoluted).

View on HN

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.

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!

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?

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.

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.

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.

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.

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.

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.

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

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.

The great thing about PDFs is that you can open huge documents and page through them quickly. I feel this is under-appreciated in today's world, where scrolling is being forced on us everywhere. Scrolling sucks for reading text. Every time you scroll, you have to pay attention to how much you scrolled, and then find your place in the text again.

As for paging speed, just try using GoodReader or PDF Expert on an iPad. I can flip through thousand-page manuals and datasheets as quickly as if it were a paper book. And a 12" iPad shows an entire A4 page without the need for zooming and panning.

In my experience, people who dislike reading PDFs have only tried doing so in Acrobat Reader (which is hot garbage, and slow), on a small screen that is wider than it is tall, zoomed in so that only half a page is being shown. That is a sub-par experience indeed.

Be it pdfs or html, I find my place through chapters, rather than pages.

Haven't you ever been forced to stop reading in the middle of a chapter? It happens to me all the time.

Depends what you mean.

Temporary interruptions yes. But then the location is kept.

Interruptions for a very long time ? I might have to reread the whole chapter anyway...

> I feel this is under-appreciated in today's world, where scrolling is being forced on us everywhere. Scrolling sucks for reading text. Every time you scroll, you have to pay attention to how much you scrolled, and then find your place in the text again.

This is incredibly important, and something that dedicated book readers like Kindles get right, but I've never seen done well in long web pages. Discrete "pages" (that correspond to "screens") make it much easier to find your place as you go to the next page. Note that multipart web pages often have you scroll through each "page" separately, and give you the worst of both worlds. Sure, PDF isn't always best for reading on a computer or phone screen, but infinite scrolling is annoying too.

Anchor tags have existed in HTML for thousands of years.

1992 to be precise! I actually made a minimal SSG based on them: https://portable.fyi/#2020-11-27-this-blog-is-a-single-html-...

Printing this page to PDF outputs the whole website, one post per page.

Maybe it's simply a force of habit at this point, but I can only read/study/memorize technical stuff from PDF/paginated source--I memorize the overall "picture" of the page and it's location along with the bits I actually need, and it's really tough to do with non-paginated sources.

Yes! I totally get this. I think it's akin to the "mind palace" method popularized in media.

That's an apt observation, actually. I used to practice mind palace when I had to memorize lists, and I do feel more comfortable when information is "physically" placed somewhere like a page, I guess it's all connected.

I wonder if source code could be read and understood more effectively if it were paginated.

I'm happy that someone came Forth with that idea here.

Source code often does facilitate it's own method of paginating, into different files. One could argue that is the whole point of the practice.

Pagination or not, both pagination and files provide some degree of spatial sense just as 'loci' and memory palaces.

Edit addendum:

There are theories about which senses are our dominant ones, and how they affect our learning processes. Some may lean towards visual ques in their mental life, others on kinetic or sound. Personlly I experience my mental models as spatial. Even abstract thoughts become situated "somewhere", if not by itself, then by contrast of other things on my mind.

"Everything is a Memory palace."

Needless to say, when I'm deep off in a terminal with something, I don't think I'd describe it as text-based.

Actually the whole different people learn with different senses has been disproved in neuroscience. It's a myth that holds itself persistently in education. There is a very good article about this: https://www.nature.com/articles/nrn3817

Source code has a bunch of other properties that make pagination less useful.

I.e. we strive for short functions, we use indentation heavily, it is commonly rendered in fixed-width fonts (this helps with spatial memory/overview too), etc.

Good points. Also, code can change frequently, so the "visual memory" reinforced by pagination becomes less useful, maybe even a hindrance.

Sounds like scrolling is actually a positive then, by forcing you to focus on understanding the content rather than relying on rote memorization.

Spatial memory is not rote memorisation.

https://en.wikipedia.org/wiki/Method_of_loci

Not sure what you're trying to say, that article pretty much only talks about its applicability to (inherently rote) memorization contests. It doesn't say _anything_ about meaningfully integrating the information as knowledge.

Which also seems to align with the article's description of how it works: you're not trying to figure out the underlying structure of what's going on, you're making up a new structure as you go based on the surface-level patterns.

I think PDFs are also less distracting since they tend to have very minimal navigation elements, very few advertisements if any, rarely ever have animation or video content, etc.

I don't have much experience with PDF as a spec, but I guess I'm a "PDF hater."

It's the things that didn't need to be PDFs, but inexplicably are, that annoy me. Like data dumps from local governments that could have been machine-readable, or announcements that are distributed in print and emailed as PDFs, rather than lifting the content into the message body.

Our city council posts PDF files which consist of scans of documents someone printed out. Sometimes they turn on OCR, but not often.

You're right - it's just the wrong format and it isn't intended for that. Gov should be publishing text/csv/parsable-formats not PDFs when it comes to data dumps.

Agreed, but there exist solutions [0] to make even PDF tables machine-readable (optionally making use of machine learning techniques). It's incredibly backwards and much harder than, say, CSV, but it might get the machine-reading job done.

0: https://camelot-py.readthedocs.io/en/master/

Also pdf has very bad support of animation formats.

That's a good thing, I don't want to see animations in a PDF.

And I would like to have an actual portable document format for electronic documents, but since mhtml support was for some reason dropped except in e-mail clients (as .eml), I'm stuck with this frankenformat that is pdf !

mhtml support is there in both Firefox and Chrome. I didn't check other browsers.

How can you save a web page as a single mhtml file in Firefox ?

Not a mhtml, but you can download a page as a single html file with the TagSpaces Web Clipper extension. It convert images to inline format.

https://addons.mozilla.org/es/firefox/addon/tagspaces/

Interesting, I was using SingleFile myself, will have to look into the differences...

Single File works better IMHO.

ePub (based on HTML as it happens) seems to come close, though even it has its warts.

> data dumps from local governments that could have been machine-readable, or announcements that are distributed in print and emailed as PDFs, rather than lifting the content into the message body.

You should thank PDF for giving you any useful electronic copies at all.

If it's scanned-in papers, sticking them loosly in an e-mail or web page would be much more difficult to read through.

If it's text data, then perhaps it was primarily composed to be printed, and PDF allows easy creation of readable electronic copies with minimum of effort from any input. Before PDF you might have gotten nothing at all, because most people don't have readers for various obscure proprietary input formats.

And PDF is far easier than other formats to convert into another format for your own consumption. Do you have a command-line tool which will extract the embedded images out of a Microsoft Word document? Or one that will convert it to plain text, preserving formatting? pdfimages and pdftotext -layout are very widely available.

> You should thank PDF for giving you any useful electronic copies at all.

I think the point is that data dumps in PDF format are not useful at all.

I take objection to your statement that it’s easier to convert. The only reason there are so many tools to do so is because it’s so hard/impossible in the first place.

> The only reason there are so many tools to do so is because it’s so hard

What exactly do you base that on? Have you written any PDF or postscript utilities?

Images are easily located in rather discrete chunks, and they are conveniently stored in standard formats like JPEG. Preserving the layout of text output takes a bit of work, but otherwise extracting text and images is just about a necessary first early step in writing any PDF viewer. And I do believe even very early PDF viewers allowed arbitrary copy/paste of text.

I’ve attempted, and given up on, writing and reading PDF files more often than I can count.

Conversely, I’ve only ever tried to write a (new) word file once, since it all worked right away.

> data dumps from local governments that could have been machine-readable

It's annoying, but if they were produced from a database (as opposed to scans), they're still usually machine-readable by converting the PDF to text, and then running a few regexes as needed to convert to something like CSV, if it's tabular in the first place.

In theory the text could be gibberish because of font subsetting that intentionally scrambles the glyphs, but that's rare and generally only implemented when a publisher is intentionally trying to thwart text extraction and/or font extraction, which I wouldn't expect a local government to either intend or to enable accidentally.

Sometimes that's on purpose.

I know of a company that was required to send HR data to a union (time clockings over a period of time). They didn't like it. They just printed a badly-organized spreadsheet to a pdf. There, they sent the data, and it was unusable.

I have the opposite experience. To me, opening a PDF puts me on edge. My computer is likely to slow to a crawl. It never renders correctly - sometimes it will slowly render each page, one at a time, flashing the screen as it goes. Or maybe the PDF is using some features that my reader doesn't support so it renders incomplete and incorrectly.

Links are often hard to pick out. What is a link and what isn't? What happens when I click on something, is it going to stay in the PDF or open a browser or something?

Don't get me started on moving around in PDFs. There are always 2 sets of page numbers, one for the PDF and one of the document. Extremely confusing.

Searching. Ugh, searching a PDF is a nightmare I don't want to even think about right now. Ctrl+F is broken 99% of the time.

Or at least, that's my experience over the last 20 years. Sure, it's gotten better recently, but, not enough to make my mind 'at ease' exactly. Very stressful to open a PDF still, usually.

> To me, opening a PDF puts me on edge. My computer is likely to slow to a crawl. It never renders correctly - sometimes it will slowly render each page, one at a time, flashing the screen as it goes.

That probably isn't the fault of the PDF, but the PDF reader you're using.

> Searching. Ugh, searching a PDF is a nightmare I don't want to even think about right now. Ctrl+F is broken 99% of the time.

Now this is actually the fault of PDF and how it does positioning of stuff within it - but about 50% of the blame lies with whichever software generated a shit PDF.

>Now this is actually the fault of PDF and how it does positioning of stuff within it - but about 50% of the blame lies with whichever software generated a shit PDF.

Arguably, it's still the fault of the horribly overcomplicated pdf spec -- html manages to do it just fine, with a plain text format, to boot

Well, it’s an interesting competition, but I believe HTML(+CSS to be fair) would win the complexity of the spec price hands down.

Shoe me the html document where I can search through a 60 page text. That's actually the thing. Html is fine if you only read text that would be maximal 2 pages on print. But if you read longer documents you want pagination which destroys the ability to search (unless the author implements a separate search or you use Google)

>Shoe me the html document where I can search through a 60 page text.

epub.

>An EPUB file is an archive that contains, in effect, a website. It includes HTML files, images, CSS style sheets, and other assets.

Search works just fine on ereaders.

The flexibility of html is that you can render it however you want, for whatever viewport or feature. If you want pagination, just render it differently.

>But if you read longer documents you want pagination

For long form works, I do actually prefer having them on my kindle, but that's because I don't want to read long-form text by staring at a screen, and I want a lower line width. PDFs tend to be worst case scenario there, because they often render with the assumption that you're trying to read it on standard letter paper.

Also, we've had "pagination" for text files for decades. It's called "less".

> That probably isn't the fault of the PDF, but the PDF reader you're using.

Completely agree. Try something that isn't Adobe Reader!

> Don't get me started on moving around in PDFs. There are always 2 sets of page numbers, one for the PDF and one of the document. Extremely confusing.

It's only a tiny subset of all PDFs in circulation, but the LaTeX PDFs I produce using appropriate settings (mainly KOMAScript class) always nail this. The current page number always corresponds to what is printed in the PDF. This can be alphanumerical (e.g. page "a" / 300, where 300 is the total number of all pages) or roman, for the frontmatter. The PDF viewer will then literally show e.g. "Page XII / 300".

So in that sense, it's in the hands of the party producing the PDF to get this right, not an inherent limitation in the standard.

But now, new problems arise. If you're on the printed page XII but your viewer displays "Page 22 / 300", you know where you are in total. "Page XII / 300" is "correcter" but can be anything.

> Searching. Ugh, searching a PDF is a nightmare I don't want to even think about right now. Ctrl+F is broken 99% of the time.

Don't share this experience. It's a the same level as in browsers, where CTRL+F is also quite limited (I'd give a kidney to have regex available everywhere---ripgrep-all gets close on the desktop). The only different thing in PDFs is if hyphenation occurs, which is arguably less common in browsers (simply because of poorer typographical standards/people care more in proper PDFs). Your search term will indeed be invisible to CTRL+F. The only other time it breaks down in PDFs if the PDF is corrupt/poorly produced/bad OCR.

PDFs can be produced by mapping completely unrelated characters to glyphs that appear as actual characters (basically, they'd embed a "compacted" font that only has the glyphs required for the document, and then map them to ASCII or something). This was quite common with pdftex documents not using ASCII characters in the past, thus making text unsearchable (and even more so when going the ps2pdf route). For example, you'd have a Cyrillic document in which when you selected text in, highlighted text would be some jumbled ASCII characters.

The fact is that PDF can display one thing and have underlying semantic text be something else entirely (frequently used for OCRing: you show actual scanned images of text, and put the invisible OCRed text as searchable ).

It works in the other direction too: you could solve the hyphenation problem in the same way by having PDF include invisible non-hyphenated word in place of the hyphenated one for searching.

Still, PDF is mostly a laying-out format, and while tools have evolved to provide some "meaning" to rendered content, it is never going to be semantic in the sense markup languages can be (i.e. there is no "emphasis", "quote" or "header" command for PDF, instead, it just uses a different font). To put things into perspective, TeX files can be semantic (if a semantic TeX .fmt like LaTeX is used) like HTML/ePub, but PDF is an output format, just like DVI is.

First thing I do when opening a Word document at work is converting it to PDF and reopen it in Sumatra Reader.

It just feels a lot better to me. It opens faster, it opens at the position I left it at, zooming in and out is fast, scrolling is smoother, and even if I wanted to, I couldn't modify it on accident.

It just feels a lot more reified than something that is responsive or editable.

Not great for mobile, but that's not what I care for at work.

I mean I dislike PDFs for the exact reasons you cite, they don't reflow and fonts are embedded and chosen by the creator.

Occasionally these choices can be good, but often I want to resize the text-size to make reading more comfortable which is easy with HTML or an EPUB, but with PDF I can only zoom so much before I must pan to actually read the entire line. Similarly, I think that the creator's font choice is often the wrong choice, it's very common for me to change fonts on an EPUB, but I can't do that for a PDF which is frustrating.

It is funny this is being upvoted as the top comment on HN, last time something similar was said, HN were piling in how awful PDF is and HTML is going to take over the world of publishing along with the coming death of PDF.

>Haters of PDFs do not understand the human aspects of it

Unfortunately UX is not something HN audience or Tech in general are good at. ( Apart from Apple )

I know! The first thing I do with an .epub or .mobi is convert it to PDF. That way, I can read it and feel my "place", highlight passages that get saved in the file (not my reader application), and annotate in margins, circle big sections, etc. I feel like the annotation abilities of PDF's get ignored, but they're HUGE.

> The first thing I do with an .epub or .mobi is convert it to PDF.

b r u h

Same here. It helps to have a solid PDF viewer (I use Okular), but what's also really underappreciated is the vastly better typography in PDFs. I suppose it depends partly on the viewer, but epubs tend to be hot garbage to look at. Fortunately ebook-convert (from the Calibre project) generates great looking PDFs and lets you set a bunch of options like fonts and so on.

This is especially important if I'm on mobile, because I can create an easily readable PDF in portrait mode that works great with the Android default PDF reader, whereas the obvious choice to open epubs (Google Books) is terrible: it's slow and battery heavy, and requires you to upload the epub so that it can be converted into the native format. (Once the conversion process choked and I somehow ended up with a 1 GB file.)

"It’s perhaps how static it is and it won’t change on me."

You might be surprised that's not always true.

https://www.pdfscripting.com/public/FreeStuff/PDFSamples/Jav...

The typesetting is better because PDF documents don't have to flow and resize across screens. This means a post-processing step can tweak hypenation, letter spacing, etc. to give the whole document a pleasing look. On the web it's a lot more difficult, but not impossible, to do the same and work on every possible size screen. There's also growing work to make typesetting style hyphenation and such work in browsers in the near future: https://developer.mozilla.org/en-US/docs/Web/CSS/hyphens

I've been obsessed with dynamicity and having everything adaptable.. but yeah static stuff have this weird feeling of 'right'.

As I discovered by accident fonts are not automatically embedded in PDFs.

PDFs are great when you want to read them on a large enough screen. They are not great on a Kindle or a phone.

I wish there was a way to have several different layouts in one PDF file, so you could have the same content but with different layouts and then your device could select the most appropriate one.

Do you know if it would be possible to get the same font(s) used on the webpage also used in the PDF?

Furthermore, even on mobile devices, everything just work. Ctrl+f is non invasive, if I close the document in the middle of 100s of pages and reopen the document, I do not need to scroll, unlike many web apps it preserves the scroll location. It does what it needs to do without any hiccups.

PDFs are designed to be printed and HTML tends to be overrun by ads. The former is nicer for reading and the latter is nicer still with ad-blocking, reader mode and/or a tasteful design.

Also they can be justified in ways browsers can’t (yet) do. Every web page has a ragged right.

Like this (the demo at the top is interactive)?

https://developer.mozilla.org/en-US/docs/Web/CSS/text-align

Interesting, there’s absolutely no difference between justify and align left on iOS Safari. I wouldn’t have guessed that’s an unsupported feature. I guess it’s not common enough for me to notice throughout the web.

Justify works in iOS Safari (I just checked). I like to use it in my designs sometimes :)

Works fine for me.

No, like ‘text-justify: inter-character’: https://developer.mozilla.org/en-US/docs/Web/CSS/text-justif...

I have been trying to place the justification format I have seen in some print books. In most cases it will add spaces between words to make up for sentences with words that can't be split easily, but it also doesn't fully right-justify the last letter of the line. It seems to be something like "add inter-word spacing unless spacing exceeds X"

The gold standard for computer text justification is the TeX algorithm: https://en.wikipedia.org/wiki/TeX#Hyphenation_and_justificat...

Copy/pasting can be infuriating though. The web is catching up fast however, but at least I can view source/inspect.

Wouldn't an SVG be better, then?

Reply on news.ycombinator.com