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

41–50 of 66 posts

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

#41

Post by adrian_b »

Worf wrote: post #36
adrian_b wrote: post #32

Earlier quoted context omitted.

HTML and EPUB work not great, but very badly for scientific or technical papers or books. No two readers render them alike, and they typically are much uglier and more difficult to use than books (sometimes even the same book) in PDF, DJVU or ODT formats. I read a very large quantity of technical documentation and I always avoid EPUB and HTML like the plague. I use such formats only when there is no alternative. On L…

I understand your point that you want a fixed presentation layout and pagination. I prefer to be able to responsively resize the document and to follow the ToC instead of pages. I've yet to see documentation that's thousands of pages long that doesn't include a very detailed ToC. For me remembering "section 8.3.16.2" is better and makes more sense than remembering "page 1292". I've had to read scanned math books year…

While browsers like Chrome and Firefox normally render very well on-screen any Web page, it is enough to give them the "Print" command for that page, to see in most cases a badly rendered page, where the size ratios of various elements are bad and they overlap or are mis-positioned so that the "printed" page is completely unlike what the browser shows on screen.

The way how the "printed" pages look in Firefox and Chrome demonstrates the same rendering problems that appear in most EPUB readers.

I have no idea which is the cause of this, but the bad behavior of "printing" in Firefox and Chrome has existed for years. Not all browsers behave the same, e.g. Vivaldi usually is much better at generating "printed" pages, than Chrome, despite being derived from the same code base.

Perhaps the great differences between on-screen rendering and "printed" rendering is caused by the fact that badly designed HTML/CSS might specify some sizes in "pixels" or other such inappropriate units, instead of using length units, like points, inches or millimeters. Then when rendering on different media the size ratios are corrupted.

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

#42

Post by Worf »

adrian_b wrote: post #39
Worf wrote: post #24

Earlier quoted context omitted.

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

In any technical/scientific document I do not want to increase or decrease the size of any element, e.g. of one of the fonts. You only want to do an overall proportional zoom, when needed. A well-designed document page has appropriate size ratios between various kinds of texts, formulae, tables and images, which should not be corrupted by changing the size of a single element. The pages where the author has not forma…

I absolutely want to increase or decrease the font while keeping the whole width unchanged. This is not possible with PDF. Or maybe it is, but I've never seen a PDF file that supports it. I may be reading on a tiny phone or on a FULL HD monitor. Or I may want to put the file on the left side of the monitor and something else on the right. If I'm on a huge monitor, I might not be OK with tiny fonts. I actually like tiny fonts sometimes, but other times I want to zoom everything. I think at night, where my eyes are more tired and when I have shut off the lighting in the room, I prefer bigger fonts.

I don't particularly care about increasing fonts ONLY. I've mainly done that on Firefox for Android years ago. The standard browser zoom (with CTRL++, CTRL+- or CTRL+WHEEL_UP, CTRL+WHEEL_DOWN) increases everything proportionally. The exceptions are newer websites that try to cram too much logic about what should be zoomed or hidden at a given level of zoom, but I'm not talking about 5 MB SPAs, but normal HTML sites.

I have read vast amounts of docs and I prefer HTML. So OK, I agree that some people want something unresponsive that looks like a printed page. But I think the issue is with how unpolished most EPUB readers are, not in the format itself.

For "underetministic" rendering, it's usually a PDF that had 2 columns, placed an image on the bottom of column 2 and referred to it from the top of column 1. If you automatically make an EPUB from that, the image would be far from where it's referred to. But nothing's stopping you from putting an image right after the paragraph that refers to it.

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

#43

Post by pegasus »

mvdwoord wrote: post #31

"everyone hates PDFs where you can't reliably select and copy text!" Boy do I. One of my biggest annoyances is receiving an invoice in pdf format, where I can either not select the text at all, or where you cannot cleanly select text, i.e. when you try to select something it somehow half highlights the line above as well and I am not sure what is on my clipboard, and need to paste temporarily in a text editor, then s…

For the mac there's TextSniper which does just that.

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

#44

Post by mock-possum »

pegasus wrote: post #43
mvdwoord wrote: post #31

"everyone hates PDFs where you can't reliably select and copy text!" Boy do I. One of my biggest annoyances is receiving an invoice in pdf format, where I can either not select the text at all, or where you cannot cleanly select text, i.e. when you try to select something it somehow half highlights the line above as well and I am not sure what is on my clipboard, and need to paste temporarily in a text editor, then s…

For the mac there's TextSniper which does just that.

There’s a Power Toys util for windows that does the same - draw a rectangle around the text you want, and it OCRs it to your clipboard.

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

#45

Post by LuttelBurchtje »

cbolton wrote: post #20

I wonder if using Typst would be a viable solution: the compiler can be built into a wasm component that runs locally in the browser (that's what the Typst webapp does) and it generates good PDFs with working selection/copy/paste. There's even a package (cmarker) than can translate Markdown to Typst which could be enough for a MVP.

The Swiss army knife for document conversion, Pandoc, supports compiling to WASM since 3.9 [1]. It supports Markdown, in a wide variety of flavours, and Typst. Their official demo page provides a PDF output via Typst, all done client-side [2]. Furthermore, you get .docx and other output formats as well

[1]: https://github.com/jgm/pandoc/releases/tag/3.9

[2]: https://pandoc.org/app/

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

#46

Post by lavrton »

Just was solving the exact same issue.

Recently I released https://polotno.com/render-tag/ library to render rich text into 2d canvas context. And it turns out it was very easy to adapt it to work with pdflib library (via 2d canvas pdf context) proxy. I was able to render good set of rich text features. Thinking to make that bridge open source as well. Maybe you will be interested in that?

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

#48

Post by FailMore »

lavrton wrote: post #46

Just was solving the exact same issue. Recently I released https://polotno.com/render-tag/ library to render rich text into 2d canvas context. And it turns out it was very easy to adapt it to work with pdflib library (via 2d canvas pdf context) proxy. I was able to render good set of rich text features. Thinking to make that bridge open source as well. Maybe you will be interested in that?

Yep sounds good!

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

#49

Post by thomas_viaelo »

lavrton wrote: post #46

Just was solving the exact same issue. Recently I released https://polotno.com/render-tag/ library to render rich text into 2d canvas context. And it turns out it was very easy to adapt it to work with pdflib library (via 2d canvas pdf context) proxy. I was able to render good set of rich text features. Thinking to make that bridge open source as well. Maybe you will be interested in that?

[dead]

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

#50

Post by seemaze »

pegasus wrote: post #43
mvdwoord wrote: post #31

"everyone hates PDFs where you can't reliably select and copy text!" Boy do I. One of my biggest annoyances is receiving an invoice in pdf format, where I can either not select the text at all, or where you cannot cleanly select text, i.e. when you try to select something it somehow half highlights the line above as well and I am not sure what is on my clipboard, and need to paste temporarily in a text editor, then s…

For the mac there's TextSniper which does just that.

On mac, I just do a quick screenshot and use the builtin OCR in Preview to select and copy text all the time.
Post reply on HN