Hacker News Reader

Comment by zhxiaoliang | Hacker News Reader

I understand your pain. That’s why I’ve ported my VMPrint layout engine to Rust. It’s early, but it already shows promising performance improvements over the original TypeScript-based engine, which is already very fast. The Rust version can create fully paginated, publishing-grade layout at around 8,500 pages (or 2,000,000 words) per second on a M4 MacBook. It’s even faster at advanced tasks like mixing texts with irregular exclusion fields. The TS version can do it under 1ms, but I don’t have a measure yet for the Rust version. Unfortunately, people have shown little interest in this kind of components, so I’m no longer inspired to release it in its raw form like I did with VMPrint. My plan is to use it to build a native markdown editor first to test it more fully and just to have fun with it, LOL.

View on HN

Your FAQ says:

    Why not Typst?

    Typst is excellent for authored documents and produces beautiful output. It is also a Rust binary. You cannot import it into a Node process, run it in a browser, deploy it to a Cloudflare Worker, or call it as a library from a TypeScript application. If you need a layout engine embedded in a JS or TS runtime, Typst is not available to you.

So, wouldn't porting VMPrint to Rust make it such that Typst is the clear winner? Or is there something else missing?

VMPrint was a document pipeline and indeed somewhat crossed path with Typst, but I’ve since carved out its engine module, stripped away all dependencies so it's a pure math engine now that can be used anywhere.

My first experiment was to wrap it in a set of APIs called Layoutmaster. They work natively with the browser’s text systems to bypass DOM overflow. It was very fast... faster than the browser in many cases. This made me wonder if it would be faster in Rust so I made a port just for fun.

Turns out, the TS version was fast -- over a thousand pages per second, but the Rust version is quite a bit faster. It's still not fully optimized though. Still working on it.

I have no intention to use it for document generation unless there is a demand for it. For now I’m more interested in how this native engine can help with frontend jobs like creating a native live-editing surface without a browser.

Just checked out VMPrint and it's crazy! Keep up the efforts. If you/someone could get a HTML/CSS input layer in front of VMPrint that would be a killer feature? Or is it possible already?

HTML/CSS is notoriously bad for print.

Basic text styles are ok, but things like authored pagination, page header/footer, mirrored margins, margin notes, footnotes and references are basically unsupported or need to be hacked together.

Exactly!

Thank you. The architecture to get an HTML/CSS input layer in front of VMPrint is already there via a component called Transmuter. I have made transmuters to allow markdown with custom syntax support as input, and they work extremely well. Full support of HTML/CSS will be still be difficult, but a well-defined subset should be easy. The sibling Layoutmaster project also demonstrates this -- you can hand it a DOM element and it automatically grabs the styles and contents, converts them into the JSON AST, then feeds them to the engine for instant layout.

Reply on news.ycombinator.com