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

21–30 of 66 posts

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

#21

Post by jkscm »

Worf wrote: post #10

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 an…

slighlty disagree with this. A fixed page layout has it's own advantages. The reason we have more high quality pdf readers than epub readers is probrably connected to the format itself. PDF readers usally are more more feature complete when it comes to stuff like annotations too.

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

#22

Post by caspper69 »

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

You would think that, but PDF is not really a format for text. It's a format that describes typography and graphics layout & formatting. It's not uncommon for a text pdf to not contain all of the text it renders (due to ligatures).

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

#23

Post by Worf »

gf000 wrote: post #13
Worf wrote: post #10

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 an…

I don't know, I really love a well-typeset books/papers. Especially when they feature figures that are deliberately placed close to the relevant section in the text, it's just not something we can replicate with HTML, that can barely do proper justified text. Sure, I would like that beautifully designed page to magically become a single column beautiful document on my phone, but I will take the former over a badly de…

The "figures that are deliberately placed close to the relevant section in the text" is something I've heard often, and I'd agree to an extent. But the figure is never 10 pages away (unless you have a tiny screen or something). It's easy to put an image inbetween 2 paragraphs. With PDF papers 1 figure is often referenced in several places throughout the paper so I just open 2 windows with the paper anyway.

For justified text - what's the point of stretching each line artificially just so they align at the end? It looks awful to me even when done "correctly". Having uneven spaces makes it harder to read. Having every line align on the right also makes it harder to read. When you have uneven lines, I subconsciously use the different at the end as an anchor for where I am in the text or where a certain phrase was. Hyphenating words is another thing that doesn't make a lot of sense nowadays - we have enough words with a hyphen naturally in them, so reading a broken up word is mentally taxing as I have to figure out if it's a normal word with a hyphen or a broken up one.

All the arXiv HTML papers are much better to read in the browser, IMO. And they'll only get better. PDF will likely stay the same.

For small screens like phones or tablets, having to constantly scroll up and down and left and right for a 2-column paper is just painful. PDF is much better on a big screen.

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

#24

Post by Worf »

danhor wrote: post #15
Worf wrote: post #10

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 an…

A PDF of a long document such as a standard or reference manual is almost always preferable to an HTML version. HTML versions have issues with formatting, searching (as browsers struggle with multi-thousand page documents and non-native search document search implementations almost always suck), indexing, correct behavior on windows size change (especially a side-by-side pdf view is almost unheard of for webpages), .…

> correct behavior on windows size change

Except the PDF is not responsive at all and you can't increase or decrease the font size without increasing the whole width of page.

> Some vendors have switched to online-only for some documents and it always annoys me.

HTML shouldn't mean online-only. If the vendor isn't trying to make it hard to download, you should always be able to convert to PDF. But PDF to HTML is very hard or impossible.

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

#25

Post by Worf »

FailMore wrote: post #19
Sharlin wrote: post #17

Earlier quoted context omitted.

Because the business world used to run on paper, and pdf became the de facto standard desktop publishing file format because Adobe became the de facto king of desktop publishing. Storing, transferring, and reading documents on paper has given way for doing all of that digitally, but path dependency guarantees that there’s no way of getting rid of PDF now. Purely psychologically, I think there’s something that feels m…

Yeah, I think the point about editing is a very good one. There is something comforting about them and perhaps that's it (+ maybe we are used to them being A4 pages, so you know what to expect). I think also the lack of flexibility with rendering is good, if you see it on one device you know exactly how it will look on another device.

But you can actually edit PDFs if you're into pain. For immutability there are hashes, signatures and so on.

I've seen rendering differences on different readers over the years. Rarely, but it happens. Probably not for basic documents or scanned papers. At least with HTML or Markdown you can read the source.

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

#26

Post by 000000000001 »

I vibecoded a pdf replacement at work, sort of.

I wanted a way to make submitting Inventory Changes at work easier, so I took the pdf, used StirlingPDF to convert to an html bundled zip, I converted the .png with the form border and symbols to base64, and then wrote a powershell script to replace

tags with variable data from a csv export of our inv data(I tried to use odbc to extract it but once a dev showed me the logical, physical, and views that made up our Inventory lookup I went back to using a xlsx export that is built into our environment and letting the ps1 trim and sanitatize the input). As the conversion places text with absolute positioning, I was able to fine tune the layout and spacing. I then used my local AI qwen3.6-27b to convert my ps1 to a single html binary webapp with html/css/js, no external framework, two js scripts are loaded via cdn for now.

Inspired by how well that worked I vibecoded a drag and drop editor to build forms for other processes, I upload a png w which gets converted to base64 and then I can drag and drop text elements to where they need to be and export.

I know how many people feel about AI coded projects so these are really only for me, I didn't expect my coworkers to adopt it or anything but they did.

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

#27

Post by Worf »

jkscm wrote: post #21
Worf wrote: post #10

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 an…

slighlty disagree with this. A fixed page layout has it's own advantages. The reason we have more high quality pdf readers than epub readers is probrably connected to the format itself. PDF readers usally are more more feature complete when it comes to stuff like annotations too.

My issue with EPUB readers is about features a PDF reader wouldn't even have. Small and annoying things like how much freedom I get when changing fonts and whatnot.

I haven't had a need to use annotations. I guess that could be solved by EPUB editors, but I haven't tested any, apart from any text editors after unzipping the EPUB.

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

#28

Post by FailMore »

000000000001 wrote: post #26

I vibecoded a pdf replacement at work, sort of. I wanted a way to make submitting Inventory Changes at work easier, so I took the pdf, used StirlingPDF to convert to an html bundled zip, I converted the .png with the form border and symbols to base64, and then wrote a powershell script to replace tags with variable data from a csv export of our inv data(I tried to use odbc to extract it but once a dev showed me the l…

Sounds pretty interesting. Got a video of it? Sometimes our vibe coded tools are pretty useful... but sometimes we can be a bit shy to share them given the vibeness...

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

#29

Post by gadders »

000000000001 wrote: post #26

I vibecoded a pdf replacement at work, sort of. I wanted a way to make submitting Inventory Changes at work easier, so I took the pdf, used StirlingPDF to convert to an html bundled zip, I converted the .png with the form border and symbols to base64, and then wrote a powershell script to replace tags with variable data from a csv export of our inv data(I tried to use odbc to extract it but once a dev showed me the l…

While I think you would be stupid to try and vibe-code EG a banking platform or SAP, I do think there is a lot of scope for small apps that can solve a particular issue.

I've just vibe-coded a mobile app, and I'm comfortable doing that because this particular app can't update data or send data anywhere. It's damage blast radius is pretty low.

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

#30

Post by jkscm »

Worf wrote: post #23
gf000 wrote: post #13

Earlier quoted context omitted.

I don't know, I really love a well-typeset books/papers. Especially when they feature figures that are deliberately placed close to the relevant section in the text, it's just not something we can replicate with HTML, that can barely do proper justified text. Sure, I would like that beautifully designed page to magically become a single column beautiful document on my phone, but I will take the former over a badly de…

The "figures that are deliberately placed close to the relevant section in the text" is something I've heard often, and I'd agree to an extent. But the figure is never 10 pages away (unless you have a tiny screen or something). It's easy to put an image inbetween 2 paragraphs. With PDF papers 1 figure is often referenced in several places throughout the paper so I just open 2 windows with the paper anyway. For justif…

Just look at examples like this: https://www.google.de/books/edition/Exploration_Map_by_Map/s...

You will realize that saying "PDFs should be only for printing" is a vast oversimplifcation for the requirements people have for different kinds of documents.

Post reply on HN