Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The surprisingly complex journey to text-selectable client-side generated PDFs

sdocs.dev

Post reply on HN
Print view View original

1–10 of 66 posts

Re: The surprisingly complex journey to text-selectable client-side generated PDFs

#3

Post by FailMore »

josefrichter wrote: post #2

It’s not that surprising. It’s one of those well known pandora boxes of web development: email templates, PDFs, printing,…

Ah, I didn't know that. It's not something I had worked on before, and the file format is highly prevalent (so I assumed things would be easy), so it was surprising to me

Re: The surprisingly complex journey to text-selectable client-side generated PDFs

#4

Post by SirHumphrey »

FailMore wrote: post #3
josefrichter wrote: post #2

It’s not that surprising. It’s one of those well known pandora boxes of web development: email templates, PDFs, printing,…

Ah, I didn't know that. It's not something I had worked on before, and the file format is highly prevalent (so I assumed things would be easy), so it was surprising to me

Nothing about PDF is easy. Similarly to what once Tom Scott said about time zones, every time I must deal with PDFs I pray that PDF.js can be hacked in to doing it instead, otherwise I just don’t bother.

It’s on of the few examples when converting it in to picture and chucking it in a multimodal llm is a more sensible solution than trying to parse it.

Re: The surprisingly complex journey to text-selectable client-side generated PDFs

#7

Post by gobdovan »

Thanks, this puts into perspective why copy-paste from PDFs is so bad.

I months into building a pasteboard transform library that normalises VS Code, Google Docs, PDFs and a bunch of Chromium apps provider-specific data so I can start pasting everything everywhere exactly how I want it. It's much, much messier than I expected.

Apps put different UTTypes on the pasteboard that are not really compatible with each other. Usually there's a plain text fallback, then rich text/HTML, then provider-specific data. You show how much insane work is needed just to make text selectable with glyph mappings, layout, links, code blocks, rendered styles, etc. But once you copy from that PDF, most viewers still only expose raw text, and often broken raw text at that...

Re: The surprisingly complex journey to text-selectable client-side generated PDFs

#8

Post by FailMore »

ashishb wrote: post #6

Software engineers drastically underestimates GUI - Web layouts, mobile app layouts, and even PDF layouts are non-trivial pieces of work to get right in all circumstances.

Yep, they (can) rarely enter your domain... so it's easy to assume its going to be trivial (maybe because things like .md or .txt files are trivial, so it's easy to think there's not much of a delta)

Re: The surprisingly complex journey to text-selectable client-side generated PDFs

#9

Post by FailMore »

gobdovan wrote: post #7

Thanks, this puts into perspective why copy-paste from PDFs is so bad. I months into building a pasteboard transform library that normalises VS Code, Google Docs, PDFs and a bunch of Chromium apps provider-specific data so I can start pasting everything everywhere exactly how I want it. It's much, much messier than I expected. Apps put different UTTypes on the pasteboard that are not really compatible with each other…

Yep, it is a very interesting space for improvements imo. Kind of broadly speaking copy and paste is so central to working with a computer in a smooth way it should probably have more power / quality built into it (e.g. not having to install some random plug in to get clipboard history, etc.)

Re: The surprisingly complex journey to text-selectable client-side generated PDFs

#10

Post by Worf »

PDFs should be only for printing or maybe for keeping scanned versions of things. For anything else they're just not the right tool for the job. Not for things meant to be accessed on a computer like books, scientific papers or, for some weird reason, catalogs and price lists from websites.

We have responsive and open standards like HTML and EPUB (zipped XTML) and they work great. arXiv has HTML papers, and libgen and anna's archive often have EPUB versions of books. The issue for me with EPUB is the lack of good readers now.

Post reply on HN