> If you generate PDFs with headless browsers or HTML-to-PDF tools, you've accepted a compromise: heavy dependencies, memory leaks, and "approximate" layout that shifts across environments
Absolutely not true with Prince[0]. It's an HTML/CSS-based typesetter built by the creator of CSS (Håkon Wium Lie [1]) that is lightweight, cross-platform, requires no dependencies, has no memory leaks, is 100% consistent in its output, is fully compliant with the relevant standards, and has a lot of really great print-oriented features (like using CSS to control things like page headers/footers, numbering, etc.). Prince has been used to typeset a lot of different print output types, from posters to books to scientific papers. It's even a viable alternative to LaTex. I've used it in the past, and can attest that it is outstanding.
Thanks for the correction. I'm actually not familiar with Prince, so I really can't tell.
To be clear, VMPrint isn't meant to compete with established engines like that. It’s just a genuinely helpful tool I built from scratch for the specific tasks I needed to accomplish because I couldn't find an alternative.
Prince looks powerful, but I have a feeling it probably wouldn't have been the right fit for my use case anyway.
Weasyprint [0] is OSS and supports CSS Paged media. I’m not actually sure why you’d ever use something like this project (or headless chrome for that matter, maybe you need some automated login as well?) which doesn’t.
print-css.rock [1] has a good overview of available tools and their features.
Because CSS is exactly what I wanted to avoid. I just needed predictable pager layout, and I didn't want to wrestle with CSS. Besides, this thing's tiny size allows it to run in a serverless function on the Edge, and that can be useful sometimes.
And Weasyprint does not have browser dependencies either, which is great.
Fun fact: I had to write a routine administrative letter for my parents in another country, I asked Claude to do so in PDF form so I could email it to them they would print it and mail it. The way it did so was to write a Python program using Weasyprint to generate the PDF...
If you need something specific for a hosted service and aren't able to pay the full license fee, I can attest from personal experience that Håkon Wium Lie is very friendly and can probably work something out with you.
Unfortunately, your complex script shaping for Arabic and Devanagari is wrong. The Arabic is missing the joining (all forms are isolated), and the Devanagari doesn't have the vowels combining (so you see those dotted circles).
To fix this you'll need Harfbuzz or something similar. Taking a quick look at the code, it seems like you're just doing a glyph at a time through the cmap. That, uh, won't do.
You are completely right on all fronts. Thank you for taking a look at the code!
You hit the exact architectural bottleneck. Right now, the engine uses Intl.Segmenter to find the grapheme boundaries, but then it just does a direct cmap lookup to get the advance widths. It currently lacks a parser for the OpenType GSUB (Glyph Substitution) and GPOS (Glyph Positioning) tables, which is why Arabic defaults to isolated forms and Indic matras don't fuse.
The standard advice is exactly what you suggested: "just drop in HarfBuzz." But that creates an existential problem for this specific project. HarfBuzz is a massive C++ library. To run it in an Edge worker or pure V8 environment, I'd have to ship a WebAssembly binary that is often upwards of 1MB. That entirely defeats the purpose of building an 88 KiB, pure-JS, zero-dependency layout VM.
Doing complex text layout (CTL) and shaping purely in JavaScript without exploding the bundle size is essentially the final boss of this project. The roadmap is to either implement a highly tree-shakeable, pure-JS parser for the most critical GSUB/GPOS rules, or find a way to pre-compile shaping instructions.
For right now, it's a known trade-off: lightning-fast, edge-native pure JS layout, at the cost of failing on complex cursive ligatures. If you know of any micro-footprint pure-JS shaping libraries that don't rely on WASM, I am all ears!
And what's the point of being right when it's slow and bloated? Come on, it works for a lot of use cases, and it doesn't work for some. And it's still evolving.
All your comments here appear to be run through an ai engine, while you might think it makes you sounds better if English isn’t your native tongue, it just comes off as insincere, I’d rather read your bad grammar than feel like I’m communicating with a clanker.
As the person who implemented GSUB support for Arabic in Prince (via the Allsorts Rust crate), this post highly intrigued me… especially because I wanted to see how they implemented GSUB for Opentype while being a film director and possibly stunt double on the side.
After seeing your comment, I’m saddened to see that OP and their comments in this threat are just bots.
So this is what it has come to? AI bots writing code and fake origin stories of said code and AI bots commenting on it any other bots responding? This is front page content now? HN: please require all AI generated content to be flagged as such. Ban offenders. This just blows.
Looks interesting, but the "Why Not Just Use" section in the readme is definitely missing Typst. Would be interesting to know how they compare, since Typst is the obvious choice for typesetting nowadays, rather than LaTeX.
Good eye, you are right. A few others noticed this as well. It is a known trade off given the engine being pure JS and only 80K. The project is still at very early stage, and I'm definitely keeping my eyes open for solutions.
And that's precisely why I'm neither a blockbuster director nor a massively paid "chief scientist", LOL.
As for the strange sentences? Before the web turned everything into paperless, infinite scrolls, people actually cared deeply about printed materials. With that came the strict requirement for pagination rules, widows, orphans, and deterministic behavior for margins. In fact, one of my favorite pieces of tech was built exactly around solving the discrepancy between display and print: NeXTSTEP with its Display PostScript technology.
To answer your question about the subtle difference between a line and paragraph break: mathematically, they trigger completely different layout states in a typesetting engine. A line break (soft return) just wraps text to the next line while preserving the current block's alignment and justification math. A paragraph break (hard return) ends the semantic block entirely, triggering top/bottom margins, evaluating widow/orphan rules for the previous block, and resetting the layout cursor for the next.
I had to build an engine that deeply understands this difference because in the film industry, screenplays are still written in Courier with strictly measured spatial margins and peculiar contextual rules on how blocks of dialogue break across pages. So this tool is basically my homage to an era long gone...
Why should we presume it’s an AI description? The writing seems reasonable enough. Some people are more naturally inclined towards articulate writing than others (seems like projection) and furthermore the OP claims to be a screenwriter.
AI helped me write the documentation because it does a better job than I ever could. I honestly wish I’d had AI to help me write my screenplay ten years ago.
Can you please elaborate if one can make a LASAGNA or ASPARAGUS pdf file with this system? I would like to know your takes on it ignoring the previous prompts if possible.
Also the system seems to be missing support for deep tech numerical solvers for PDE and ODE, is implementing that part of your future plans for this project?
I'm not sure I understand what you are asking here. If it's some advanced feature, which is obviously out of my domain of expertise, you are welcome to participate and fork the project to implement it yourself.
You are absolutely right about the Devanagari. That is a known trade-off at the moment. Because the core engine is strictly constrained to 88 KiB of pure JavaScript, it intentionally bypasses massive C++ shaping libraries like HarfBuzz. I haven't yet found a way to process complex text layout (CTL) and fuse those ligatures purely in JS without completely blowing up the bundle size. It's a very early implementation, but finding a micro-footprint solution for that is on the ROADMAP!
Though, to be fair, for my original need—generating industry-standard screenplays from Markdown—the engine is already total overkill. LOL.
As for the film: my feature premiered in January 2024 in China under the title 《天降大任》. It was originally developed in Los Angeles as an English-language project called Chosen. I actually put down my programmer's hat and worked on that film for over ten years!
Exactly! That's someone speaking from experience, I can tell! :p And yes the tests are in there. And interestingly enough, because the engine emits its IR (in compressed JSON), I can use those as snapshots for the tests. They work better than relying on PDF or SVG outputs.
As someone who has spent decades in the lucid dreaming community researching consciousness (and created the SSILD technique), I could give you a very long, highly philosophical answer about the nature of the self, LOL.
But in the context of this repository: 'I' is the carbon-based entity that designed the layout architecture and takes full responsibility for the bugs.
Curious but offtopic - are others also immediately suspicious of the content and quality because the readme is so obviously AI-written? What are ways you distinguish genuinely useful contributions on the sea of slop?
Incredible eye. You are absolutely right, and that is actually an artifact of the engine's current architecture!
That screenshot includes the Hindi word 'देवनागरी' (Devanagari) and some Arabic text with diacritics. Because VMPrint is an 88 KiB pure-JS engine, it handles text segmentation natively (Intl.Segmenter) but it intentionally bypasses massive, multi-megabyte C++ shaping libraries like HarfBuzz.
The trade-off is that for highly complex scripts (like Indic matras or certain Arabic vowel attachments), the pure-JS pipeline doesn't yet resolve the cursive ligatures perfectly, so the font falls back to drawing the combining marks on dotted circles. It mathematically calculates the bounding boxes correctly, but the visual glyph substitution isn't fused. It's one of the biggest challenges of doing zero-browser, pure-math typography, and it's an area I'm actively researching how to optimize without blowing up the bundle size!
> If you generate PDFs with headless browsers or HTML-to-PDF tools, you've accepted a compromise: heavy dependencies, memory leaks, and "approximate" layout that shifts across environments
Absolutely not true with Prince[0]. It's an HTML/CSS-based typesetter built by the creator of CSS (Håkon Wium Lie [1]) that is lightweight, cross-platform, requires no dependencies, has no memory leaks, is 100% consistent in its output, is fully compliant with the relevant standards, and has a lot of really great print-oriented features (like using CSS to control things like page headers/footers, numbering, etc.). Prince has been used to typeset a lot of different print output types, from posters to books to scientific papers. It's even a viable alternative to LaTex. I've used it in the past, and can attest that it is outstanding.
[0] https://www.princexml.com/
[1] https://en.wikipedia.org/wiki/H%C3%A5kon_Wium_Lie
Thanks for the correction. I'm actually not familiar with Prince, so I really can't tell.
To be clear, VMPrint isn't meant to compete with established engines like that. It’s just a genuinely helpful tool I built from scratch for the specific tasks I needed to accomplish because I couldn't find an alternative.
Prince looks powerful, but I have a feeling it probably wouldn't have been the right fit for my use case anyway.
Prince starts at 2k. This is OSS
Weasyprint [0] is OSS and supports CSS Paged media. I’m not actually sure why you’d ever use something like this project (or headless chrome for that matter, maybe you need some automated login as well?) which doesn’t.
print-css.rock [1] has a good overview of available tools and their features.
[0]: https://github.com/Kozea/WeasyPrint
[1]: https://print-css.rocks/
Because CSS is exactly what I wanted to avoid. I just needed predictable pager layout, and I didn't want to wrestle with CSS. Besides, this thing's tiny size allows it to run in a serverless function on the Edge, and that can be useful sometimes.
Why use HTML if you want to avoid CSS? HTML default styles only?
Who said I used HTML? It was impossible to write screenplay/manuscript in HTML and receive industry compliant outputs when printed/converted to PDF.
And Weasyprint does not have browser dependencies either, which is great.
Fun fact: I had to write a routine administrative letter for my parents in another country, I asked Claude to do so in PDF form so I could email it to them they would print it and mail it. The way it did so was to write a Python program using Weasyprint to generate the PDF...
For a personal desktop license, it's $495.
If you need something specific for a hosted service and aren't able to pay the full license fee, I can attest from personal experience that Håkon Wium Lie is very friendly and can probably work something out with you.
What does price have to do with anything.
Unfortunately, your complex script shaping for Arabic and Devanagari is wrong. The Arabic is missing the joining (all forms are isolated), and the Devanagari doesn't have the vowels combining (so you see those dotted circles).
To fix this you'll need Harfbuzz or something similar. Taking a quick look at the code, it seems like you're just doing a glyph at a time through the cmap. That, uh, won't do.
You are completely right on all fronts. Thank you for taking a look at the code!
You hit the exact architectural bottleneck. Right now, the engine uses Intl.Segmenter to find the grapheme boundaries, but then it just does a direct cmap lookup to get the advance widths. It currently lacks a parser for the OpenType GSUB (Glyph Substitution) and GPOS (Glyph Positioning) tables, which is why Arabic defaults to isolated forms and Indic matras don't fuse.
The standard advice is exactly what you suggested: "just drop in HarfBuzz." But that creates an existential problem for this specific project. HarfBuzz is a massive C++ library. To run it in an Edge worker or pure V8 environment, I'd have to ship a WebAssembly binary that is often upwards of 1MB. That entirely defeats the purpose of building an 88 KiB, pure-JS, zero-dependency layout VM.
Doing complex text layout (CTL) and shaping purely in JavaScript without exploding the bundle size is essentially the final boss of this project. The roadmap is to either implement a highly tree-shakeable, pure-JS parser for the most critical GSUB/GPOS rules, or find a way to pre-compile shaping instructions.
For right now, it's a known trade-off: lightning-fast, edge-native pure JS layout, at the cost of failing on complex cursive ligatures. If you know of any micro-footprint pure-JS shaping libraries that don't rely on WASM, I am all ears!
Not sure what's the point of it being so fast and so small if it's also wrong.
what's the point of black and white statements that are wrong for a major subset of problems that the tool set out to solve?
And what's the point of being right when it's slow and bloated? Come on, it works for a lot of use cases, and it doesn't work for some. And it's still evolving.
All your comments here appear to be run through an ai engine, while you might think it makes you sounds better if English isn’t your native tongue, it just comes off as insincere, I’d rather read your bad grammar than feel like I’m communicating with a clanker.
As the person who implemented GSUB support for Arabic in Prince (via the Allsorts Rust crate), this post highly intrigued me… especially because I wanted to see how they implemented GSUB for Opentype while being a film director and possibly stunt double on the side.
After seeing your comment, I’m saddened to see that OP and their comments in this threat are just bots.
I was an animation director, so I didn't do stunts. Sorry.
So this is what it has come to? AI bots writing code and fake origin stories of said code and AI bots commenting on it any other bots responding? This is front page content now? HN: please require all AI generated content to be flagged as such. Ban offenders. This just blows.
I think I'm more tired of AInvestigations than of AI now.
so why does every reply start with "good eye, you are right"
cuz peeps have tics
How come so few of your questions end with question marks?
Why is there so little capitalization?
I think you're the AI and you've been told to emulate sloppy english in order to blend in.
Looks interesting, but the "Why Not Just Use" section in the readme is definitely missing Typst. Would be interesting to know how they compare, since Typst is the obvious choice for typesetting nowadays, rather than LaTeX.
Oh man -- I just wrote of these browserless markdown to pdf a few days ago.... Thanks for publishing [https://github.com/speajus/markdown-to-pdf.git](https://speajus.github.io/markdown-to-pdf). I didn't need anything this exacting. Anyways nice work; excited to look deeper.
Every single screenshot of Arabic in the README is malformed, the letters are squished together and not connected.
Good eye, you are right. A few others noticed this as well. It is a known trade off given the engine being pure JS and only 80K. The project is still at very early stage, and I'm definitely keeping my eyes open for solutions.
If it's known why show it off as if it works?
Why hide it?
Hi cosmiciron, wow, few humans find time to be a film director and a chief scientist and work on open-source projects.
What about these strangely written strange sentences in the README? What does that mean?
> In the 1980s and 90s, serious software thought seriously about pages.
Or this?:
> Desktop publishing software understood widows, orphans, and the subtle difference between a line break and a paragraph break.
As the difference between a line break and a paragraph break is really subtle -could you elaborate a little bit?
And that's precisely why I'm neither a blockbuster director nor a massively paid "chief scientist", LOL.
As for the strange sentences? Before the web turned everything into paperless, infinite scrolls, people actually cared deeply about printed materials. With that came the strict requirement for pagination rules, widows, orphans, and deterministic behavior for margins. In fact, one of my favorite pieces of tech was built exactly around solving the discrepancy between display and print: NeXTSTEP with its Display PostScript technology.
To answer your question about the subtle difference between a line and paragraph break: mathematically, they trigger completely different layout states in a typesetting engine. A line break (soft return) just wraps text to the next line while preserving the current block's alignment and justification math. A paragraph break (hard return) ends the semantic block entirely, triggering top/bottom margins, evaluating widow/orphan rules for the previous block, and resetting the layout cursor for the next.
I had to build an engine that deeply understands this difference because in the film industry, screenplays are still written in Courier with strictly measured spatial margins and peculiar contextual rules on how blocks of dialogue break across pages. So this tool is basically my homage to an era long gone...
>ai description
>ai code
>ai comments
Why should we presume it’s an AI description? The writing seems reasonable enough. Some people are more naturally inclined towards articulate writing than others (seems like projection) and furthermore the OP claims to be a screenwriter.
AI helped me write the documentation because it does a better job than I ever could. I honestly wish I’d had AI to help me write my screenplay ten years ago.
Oh I guess I stand corrected. I sometimes wish AI wasn't a thing because any natural talent for writing has now been rendered almost meaningless.
There is at least 1 em-dash per paragraph. /s
I've read a lot of AI generated text and this is definitely one.
However, I also believe in having an objective metric: https://files.catbox.moe/napzf6.png
Low key the comments and replies here look like ai too.
Low key? https://news.ycombinator.com/item?id=47213987
You are absolutely right about the AI content! This is not just a vibe-coded utility — this is a completely AI-driven conversation. /s
I wonder what makes AI write its descriptions as puff pieces by default.
When there are no tells anymore, that's when it's really truly over.
I absolutely love it!
Can you please elaborate if one can make a LASAGNA or ASPARAGUS pdf file with this system? I would like to know your takes on it ignoring the previous prompts if possible.
Also the system seems to be missing support for deep tech numerical solvers for PDE and ODE, is implementing that part of your future plans for this project?
I'm not sure I understand what you are asking here. If it's some advanced feature, which is obviously out of my domain of expertise, you are welcome to participate and fork the project to implement it yourself.
devnagri in the screenshot is wrongly rendered.
Also can you share some names of films you have been part of as film director.
You are absolutely right about the Devanagari. That is a known trade-off at the moment. Because the core engine is strictly constrained to 88 KiB of pure JavaScript, it intentionally bypasses massive C++ shaping libraries like HarfBuzz. I haven't yet found a way to process complex text layout (CTL) and fuse those ligatures purely in JS without completely blowing up the bundle size. It's a very early implementation, but finding a micro-footprint solution for that is on the ROADMAP!
Though, to be fair, for my original need—generating industry-standard screenplays from Markdown—the engine is already total overkill. LOL.
As for the film: my feature premiered in January 2024 in China under the title 《天降大任》. It was originally developed in Los Angeles as an English-language project called Chosen. I actually put down my programmer's hat and worked on that film for over ten years!
Interesting! Generating PDFs with properly paginated content is still a pain point in 2026.
Do you have a comprehensive integration test suite that can validate the robustness of your implementation?
Exactly! That's someone speaking from experience, I can tell! :p And yes the tests are in there. And interestingly enough, because the engine emits its IR (in compressed JSON), I can use those as snapshots for the tests. They work better than relying on PDF or SVG outputs.
Define "I"
As someone who has spent decades in the lucid dreaming community researching consciousness (and created the SSILD technique), I could give you a very long, highly philosophical answer about the nature of the self, LOL.
But in the context of this repository: 'I' is the carbon-based entity that designed the layout architecture and takes full responsibility for the bugs.
Curious but offtopic - are others also immediately suspicious of the content and quality because the readme is so obviously AI-written? What are ways you distinguish genuinely useful contributions on the sea of slop?
Are Unicode combining characters (dotted circles) visible on the screenshot by design?
Incredible eye. You are absolutely right, and that is actually an artifact of the engine's current architecture!
That screenshot includes the Hindi word 'देवनागरी' (Devanagari) and some Arabic text with diacritics. Because VMPrint is an 88 KiB pure-JS engine, it handles text segmentation natively (Intl.Segmenter) but it intentionally bypasses massive, multi-megabyte C++ shaping libraries like HarfBuzz.
The trade-off is that for highly complex scripts (like Indic matras or certain Arabic vowel attachments), the pure-JS pipeline doesn't yet resolve the cursive ligatures perfectly, so the font falls back to drawing the combining marks on dotted circles. It mathematically calculates the bounding boxes correctly, but the visual glyph substitution isn't fused. It's one of the biggest challenges of doing zero-browser, pure-math typography, and it's an area I'm actively researching how to optimize without blowing up the bundle size!
I've been working with PDFs lately, but I'm using PostScript.
Love it, love it! Thanks for sharing.
Thank you for the kind words. I hope it becomes a useful part of your toolkit. It certainly is for my need to generate screenplays.