Hacker News Reader

Comment by mastax | Hacker News Reader

> Meanwhile, in HTML and SVG export, PDFs are converted to an embedded SVG on-the-fly. And, finally, in PNG export and the web app preview, PDFs are rasterized. All of this PDF processing functionality lives right in the Typst compiler, with no system dependencies. This is only possible thanks to the amazing work of community member @LaurenzV, who created a new PDF processing library called hayro from scratch. The library is 100% written in the programming language Rust (which is also the language we use for the Typst compiler) and is thus highly portable.

Wow! That must’ve been quite an effort.

View on HN

And the hayro library is standalone and can easily be used outside of Typst. It only uses CPU and is pure Rust so it can also be used with WebAsembly. Link to demo below.

https://github.com/LaurenzV/hayro

https://laurenzv.github.io/hayro/

Holy sh*t, I've just dropped some pretty big pdfs (>400 pages), and it rendered almost instantaneously! This is really impressive.

Indeed... I wonder to what extent the author of hayro did this work specifically for Typst or if they would have done it anyway.

Author here! Resolving one of the most-requested Typst features was definitely a big motivation for me, but I wouldn't say this was the only reason. I've done a lot of previous work on PDF (see e.g. the krilla library, although also mostly in the context of Typst), so I was already pretty familiar with how PDF works. In addition to that, I also just finished writing my master's thesis about 2D rendering (also in Rust), so I also gained a lot of knowledge in that area. Therefore, this project seemed like a good opportunity for me to create a bigger open source project myself that I could work on in my free time. :)

And a job offer I hope!

Would it be feasible, with hayro-interpret and krilla, to take an existing PDF and round-trip each of the pages while wrapping the contents in marked content spans and adding tags, to remediate the accessibility of an existing PDF? Round-tripping each of the page content streams through a full-featured PDF interpreter seems cleaner than trying to edit in-place. PDFium can round-trip the content streams and add the marked content spans, but can't do the tagging. What do you think?

Yeah, this is definitely a goal for the future. But there is still quite a bit of work needed in both libraries to make this possible.

Thanks for sharing the background. It's impressive work. Makes me curious about your thesis... Is it publicly available?

Not yet, but it should hopefully be graded in 1-2 weeks and then I can share it!

For posterity: https://github.com/LaurenzV/master-thesis

Thanks for your contribution!

Impressive work, congrats!

> is thus highly portable

Much less portable than the C ecosystem though.

> Much less portable than the C ecosystem though.

Theoretically? Yes. In practice...

Do you actually develop for a platform that (a) has a standards-compliant C compiler, (b) does not have a Rust target, and (c) has enough memory to be worth dealing with PDFs?

That’s simplistic. I maintain some large C and Rust programs, and I find Unix/windows issues much easier to fix on rust than in C, and supporting Linux and windows well matters a lot more than some obscure CPU Rust doesn’t support.

Reply on news.ycombinator.com