Live data from Hacker News

Show HN: I built a zero-browser, pure-JS typesetting engine for bit-perfect PDFs

github.com

41–50 of 64 posts

Re: Show HN: I built a zero-browser, pure-JS typesetting engine for bit-perfect PDFs

#41

Earlier quoted context omitted.

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

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/

Re: Show HN: I built a zero-browser, pure-JS typesetting engine for bit-perfect PDFs

#42

>ai description >ai code >ai comments

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.

Re: Show HN: I built a zero-browser, pure-JS typesetting engine for bit-perfect PDFs

#44
post #17

Earlier quoted context omitted.

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

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?

Re: Show HN: I built a zero-browser, pure-JS typesetting engine for bit-perfect PDFs

#46

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.

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.

Re: Show HN: I built a zero-browser, pure-JS typesetting engine for bit-perfect PDFs

#47
post #39

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…

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

Re: Show HN: I built a zero-browser, pure-JS typesetting engine for bit-perfect PDFs

#48

Earlier quoted context omitted.

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?

Re: Show HN: I built a zero-browser, pure-JS typesetting engine for bit-perfect PDFs

#49

Earlier quoted context omitted.

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.

Re: Show HN: I built a zero-browser, pure-JS typesetting engine for bit-perfect PDFs

#50

Earlier quoted context omitted.

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?
Post reply on HN