71–80 of 119 posts
Earlier quoted context omitted.
Sadly no one really publishes books as HTML.
Not sure if this is sarcastic but FYI: https://en.wikipedia.org/wiki/Comparison_of_e-book_formats (spoiler, most of them are HTML/CSS)
Isn't the whole point of PDFs that they (mostly) don't change? They represent content as laid out on a page. So, IMO this is neat if it's new tech for reading PDFs and extracting data from them (and maybe leveraging current under-used features to store more machine-readable information), but bad if it's about introducing even more complexity into the PDF documents. Perhaps 10 years from now we will have responsive PD…
https://helpx.adobe.com/acrobat/using/reading-pdfs-reflow-ac...
A couple of insights from those years:
PDF is popular because it fits the paper designer mindset and because Adobe InDesign is pretty much the standard in the publishing industry.
HTML is a much better format for the digital age. It's responsive, interactive, etc, but even today, the best way to produce HTML is by using a code editor.
Even if there was a good WYSIWYG tool, editorial designers come from the paper world and have a really hard time understanding the responsive model.
Many times I've fantasized about working on a tool made for designers to produce HTML, but it would be a ton of work and I don't really think there is a market for it. Many ebook formats are actually HTML, but I think the industry is getting by with conversion tools from Word. Most HTML content comes from blogs and journals which already have an established pipeline and don't need a general purpose HTML production solution. Education is the strongest use case, but most education companies are still rooted in paper and switching to interactive education is quite a leap.
Earlier quoted context omitted.
A standard that is too open ;-) Better have an alternative that is controlled by one company. Shareholders like that. Think social media, ads, apps.
PDF is an ISO standard. PDF 2.0 has no proprietary components.
Earlier quoted context omitted.
This is more like a readability mode than a responsive website. It's a button you click to automatically make a fixed-layout PDF fluid and easier to read on mobile. You'd still author the document the same way without considering multiple device sizes. When the PDF needs to be reproduced faithfully (printing) it would still appear as the creator intended.
>It's a button you click to automatically make a fixed-layout PDF fluid and easier to read on mobile. But this of course reminds us of the miserable UX we have come to accept from the "mobile web". In the beginning, mobile websites didn't exist, and you just zoomed. Now, it's practically impossible to view the desktop website from a phone at some URLs without jailbreaking your device (if it's iOS). The net effect has…
Maybe put a link on the pdf for online ordering or finding locations, but I have no idea why the home page should be anything but a menu.
Earlier quoted context omitted.
For many, the point of a PDF is that it appears the same way in all contexts. For device-dependent rendering, we have HTML.
Sadly no one really publishes books as HTML.
Can Apple kill PDF too, please? I'm especially enraged at the PDF "forms" XFA or whatever that no software on this planet can open except Adobe Reader. And Adobe Reader even on macOS doesn't allow Print to PDF or something else to get a PDF in a "sane" format. I have to use a fake printer to trick Adobe Reader about this! Incredible!
But as a reader of essays and textbooks on a small tablet, let me tell you it's can be useful. Yeah, it's not elegant. It a clever technical solution to a real-world problem made of decades of path dependency.
You might call it a hack.
If this had been from some kid in his basement and not from a corporate press release (admittedly pompous, overselling and worrying privacy-wise), you would have cheer.