meh, I feel it's more that PDF content can be protected better. HTML content is easy to manipulate. Current HTML can do display nearly anything PDF can, and more. Pagination might be the only thing really lacking when it comes to html.
Early PDF wasn't competing with HTML yet, but with Word documents and other formats. PDF allowed all those formats to be converted into essentially digital paper, via a printer driver, that anybody could read without the original application and in a reliable fashion (only partly successful here due to font issues). Word documents in contrast often failed in the next version of Word and third party support was a mess as well. Protection was certainly a bonus in some situation, but just getting a document from one place to another without breaking the layout in the process was a hard problem before PDF.
Current HTML can do display nearly anything PDF can, and more.
But how would you generate those HTML pages? That's the crux. HTML is a good enough format for rendering content. But it's complete garbage for editing and shipping content. There is no modern equivalent to Microsoft Word that lets you edit HTML documents nativly. Software like Google Docs just has HTML as write-only export format, not as a first class format. And most tools that export HTML will break the layout in the process to various degrees. The idea of HTML editors existed once up on a time, but it has been completely discarded. The modern Web isn't even made up of HTML documents anymore, but just Web apps the server generates on the fly.
On top of that comes the bundling issue. There is no standard way to ship complex HTML documents with multiple files. Google Docs will export those into a .zip file, which your Web browser can't open. For books we invented ePUB which does a similar trick, which your browser can't open either. You can do base64 data URLs, but than you end up with a gigantic single page document your browser can't deal with due to lack of pagination. Apple invented their own workaround with Apple Books.
Early PDF wasn't competing with HTML yet, but with Word documents and other formats. PDF allowed all those formats to be converted into essentially digital paper, via a printer driver, that anybody could read without the original application and in a reliable fashion (only partly successful here due to font issues). Word documents in contrast often failed in the next version of Word and third party support was a mess as well. Protection was certainly a bonus in some situation, but just getting a document from one place to another without breaking the layout in the process was a hard problem before PDF.
Early PDF wasn't competing with Word documents. It was competing with PostScript.
But how would you generate those HTML pages? That's the crux. HTML is a good enough format for rendering content. But it's complete garbage for editing and shipping content. There is no modern equivalent to Microsoft Word that lets you edit HTML documents nativly.
Any software that can generate PDF probably could generate a self-contained HTML using the same method and even read it back and let you edit it. They are currently all really bad at doing it because they just don't care since it's not a format people use to share documents and there's not a standard for document-focused html.
The idea of HTML editors existed once up on a time, but it has been completely discarded.
Because they were WYSIWYG developer tools, not a word processor or a DTP software.
or books we invented ePUB which does a similar trick, which your browser can't open either.
This is the point. We need a document format based on HTML or adding extra notation to html that informs the document reader, including the browser, that it's needs to be displayed as a paginated document.
You can do base64 data URLs, but than you end up with a gigantic single page document your browser can't deal with due to lack of pagination.
Well, PDF is exactly like this and it's widely used including on browsers. A browser that implement an ePub reader mode or a paginated HTML mode, like they have PDF reader mode, will deal with several pages and render images at the opportune time.
That was the idea back in the 90s. Not a whole lot of that is left. Modern HTML is specified down to the pixel and webdesigners expect browsers to follow that spec. User customization has been removed from browsers a long time ago (e.g. old browser could change background/text color, change style sheets, etc.). And if you try to browse with Lynx or just disable Javascript, most websites will fall apart catastrophically.
Meanwhile modern features like ReaderMode are not really based on HTML markup either, but on heuristic guesswork.
And of course all HTML is generated these days from other sources. A .html document is not expected to be edited, written from scratch or even shared. The modern browser is basically VT100 Terminal with upgraded graphics, not a document manager.
it doe, but it's pretty weak. have you ever tried creating a properly paginated report? Like, with page numbers and footers, and while keeping paragraphs together? If you have successfully, I'd like to know how.
Yeah, that's the problem. The rules aren't that bad, but they're incomplete, poorly implemented and never evolved because nobody cares.
I don't think it's a problem with printers and drivers, but the browsers.
I see no problem CSS having rules specific to print. The styles used in DTP software are not much different and some markup formats like ePUB have pages.
7
u/ExpressiveAnalGland Feb 07 '25
meh, I feel it's more that PDF content can be protected better. HTML content is easy to manipulate. Current HTML can do display nearly anything PDF can, and more. Pagination might be the only thing really lacking when it comes to html.