Live data from Hacker News

Typesetting Engines: A Programmer's Perspective

blog.ppresume.com

21–30 of 55 posts

Re: Typesetting Engines: A Programmer's Perspective

#21
post #9

This overlooks CSS Paged Media based options like paged.js, weasyprint, etc. (You can find the full list here..some open source, some commercial)[0] [0] https://www.print-css.rocks/tools

Author here.

I mentioned https://polytype.dev/ in the end of the post, which has pages.js included.

Is not that hard to simulate pagination with JavaScript, the deal breaker for me is still line breaking and also mixed languages typesetting nuances.

Re: Typesetting Engines: A Programmer's Perspective

#22
post #8

GNU TeXmacs ( https://youtu.be/H46ON2FB30U ) is missing.

I firmly believe that just its name set TeXmacs back by a lot. It's a pretty great choice, was even more so a decade or two ago (when typst and the ilk weren't available). But every single time I've tried to introduce it to someone, it's always some variant of "Oh, I don't use Emacs, so a plugin for that isn't useful to me". It's a really unintuitive and unfortunate naming choice that I wish they'd at least changed a…

Any idea about TeXmacs support for non-latin languages?

Re: Typesetting Engines: A Programmer's Perspective

#23

> Indo-European languages: a language family native to the overwhelming majority of Europe, the Iranian plateau, and the northern Indian subcontinent. Widely spoken indo-european languages includes English, French, Portuguese, Russian, Dutch, and Spanish, etc. > Indo-European languages typically use the Latin alphabet After the first sentence, "Indo-European" seems to have transformed to just "European" in the author…

Thanks for pointing this out.

Yes you are right, I am not a linguist so I have little knowledge for "Indo" languages.

Originally I adopted the word of "Germanic languages" then I found Spanish is not a Germanic language hence I then adopted "Indo European" language.

This needs a fix for sure.

Re: Typesetting Engines: A Programmer's Perspective

#24

I've written and published over a dozen books. (Two published with big tech publishers, the rest self-published.) With my most recent book, I've moved my PDF generation to Typst. LaTeX, you served me well, but I'm more than happy to never use you again. Typst is better (or decent enough) in every dimension.

Just curious, what is the best part you love typst most over LaTeX?

I guess: 1) the incremental compilation speed, 2) the modern user experience (better error message things, better syntax, etc)?

Re: Typesetting Engines: A Programmer's Perspective

#25

ConTeXt[1] is monolithic typesetting software that I've integrated into my Markdown editor[2]. I find ConTeXt allows for a complete separation of content and presentation. This makes it possible to write a novel in Markdown and produce various styles: a formatted PDF and a manuscript PDF. See the themes output in the screenshots[3]. Too bad the authors didn't evaluate LuaTeX or ConTeXt. [1]: https://wiki.contextgarde…

Just for keenwrite, from the screenshot: https://keenwrite.com/images/screenshots/05.png, seems that keenwrite doesn't implement Knuth Plass line breaking algorithm?

Re: Typesetting Engines: A Programmer's Perspective

#26

> Indo-European languages: a language family native to the overwhelming majority of Europe, the Iranian plateau, and the northern Indian subcontinent. Widely spoken indo-european languages includes English, French, Portuguese, Russian, Dutch, and Spanish, etc. > Indo-European languages typically use the Latin alphabet After the first sentence, "Indo-European" seems to have transformed to just "European" in the author…

My understandings, as one very familiar with Indic scripts, very familiar with Unicode in general, but not a CJK user, so please correct me if I’ve blundered:

• Indic scripts need the renderer to support complex text shaping, or else the text will generally be illegible, as though you were drawing your letters wrong, stacking some vowels on top of each other, and other nonsense things like that. As an example, if you’re not familiar with Indic scripts, see the code points used to write my name in Telugu, and how they contribute to the rendering: https://temp.chrismorgan.info/%E0%B0%95%E0%B1%8D%E0%B0%B0%E0.... It’s basically “letter ka, delete the vowel, letter ra, delete the vowel, add vowel i, letter sa, delete the vowel”, but the “kri” will normally be joined together into a conjunct, with the vowel sign drawn on the first consonant, and the second consonant being drawn in a completely different way from normal, which may even affect layout by font—the r conjunct can be a semicircle below, as in that font, but it can also be a curve beginning on the left, shifting the k to the right. (Me, I like the curve style for no particular reason, but the semicircle seems more popular these days. If this concept seems weird to you, reflect that English has allographs too https://en.wikipedia.org/wiki/Allograph>, though mostly not particularly affecting layout.)

• But as regards line breaking, Indic scripts are much the same as English.

• CJK shaping/rendering can have a bit of complexity because of Han unification https://en.wikipedia.org/wiki/Han_unification>, and definitely has a lot more nuanced stuff like mixing horizontal and vertical writing modes, and what to do when you mix scripts (which happens much more than with Indic scripts), especially digits, and especially when combining vertical and horizontal. But if your engine doesn’t support any of this, your document should still at least be fully intelligible—just uglier.

• CJK line breaking is awful: where most languages have settled on using spaces to separate words, most CJK languages mostly don’t (Korean does, I believe), and so you pretty much need to know the language to avoid breaking in the middle of words. So you end up things a bit like hyphenation dictionaries to try to do a good-enough job of it. Again, if your engine doesn’t support this, your document should still be intelligible—just uglier.

Re: Typesetting Engines: A Programmer's Perspective

#27
post #3

The most painful issues I encountered when building out a text layout engine for my JS 2D canvas library were: - Vertical text - in particular when it comes to how CJK punctuation differs in horizontal and vertical environments (not yet solved) - Staying on CJK, making sure the punctuation marks that follow a character don't break and remain with their preceding characters at all times. (I expect the same holds for o…

Paste the following into https://chearon.github.io/dropflow/ to see that it _is_ possible to style individual Arabic characters in canvas:

عربي

That uses harfbuzzjs to do shaping and, for the segments that it has to, it paints paths instead of using fillText. There is an even better method which Mozilla's pdfjs uses: for all the glyphs that you want to draw, build a font (easy with HarfBuzz) that maps sequential characters to those glyphs. Then use fillText with that font and the character that corresponds to the glyph that you want for each glyph. That's nearly as fast as fillText on the whole string.

The points you make are really important. I rant about how even Google Sheets doesn't do rich text correctly because of fillText's simplicity here: [1]. But I think many of your points could be solved by using HarfBuzz. I dream of having shapeText and fillGlyphs methods on the canvas as an alternate to HarfBuzz because it would be less wasteful. Leave the high-level APIs up to client-side libraries like dropflow and scrawl.

Google has proposed a placeElement method [2] that allows you to render HTML and CSS into a canvas, but that destroys what's so great about canvas, which is that it's crazy fast. DOM is very heavy-weight.

[1] https://github.com/chearon/dropflow#harfbuzz [2] https://github.com/WICG/canvas-place-element

Re: Typesetting Engines: A Programmer's Perspective

#28

> Indo-European languages: a language family native to the overwhelming majority of Europe, the Iranian plateau, and the northern Indian subcontinent. Widely spoken indo-european languages includes English, French, Portuguese, Russian, Dutch, and Spanish, etc. > Indo-European languages typically use the Latin alphabet After the first sentence, "Indo-European" seems to have transformed to just "European" in the author…

My understandings, as one very familiar with Indic scripts, very familiar with Unicode in general, but not a CJK user , so please correct me if I’ve blundered: • Indic scripts need the renderer to support complex text shaping, or else the text will generally be illegible, as though you were drawing your letters wrong, stacking some vowels on top of each other, and other nonsense things like that. As an example, if yo…

That graphic of the Indic glyph is very interesting! Definitely explains why shaping is so complex for those scripts!

Regarding CJK line-breaking, my understanding was that it was only Thai and closely related languages that required dictionary-based line breaking, and the Chinese/Japanese had simpler rules mostly concerning punctuation. But I'm not certain about that.

Re: Typesetting Engines: A Programmer's Perspective

#29
post #20

> Indo-European languages: a language family native to the overwhelming majority of Europe, the Iranian plateau, and the northern Indian subcontinent. Widely spoken indo-european languages includes English, French, Portuguese, Russian, Dutch, and Spanish, etc. > Indo-European languages typically use the Latin alphabet After the first sentence, "Indo-European" seems to have transformed to just "European" in the author…

Not just "European", Western European. A whole lot of people read and write with the Cyrillic alphabet.

roger that, thanks!

Re: Typesetting Engines: A Programmer's Perspective

#30
post #16
post #15

Earlier quoted context omitted.

This is pretty hard to believe considering how good the ecosystem in Typst is so far. There are quite a few packages for making slides in Typst including [Polylux]( https://github.com/gszauer/polylux ), [Touying]( https://github.com/Wyntau/touying ], [minideck]( https://typst.app/universe/package/minideck ), [slydst]( https://typst.app/universe/package/slydst ) [minimal-presentation]( https://typst.app/universe/packa…

The problem is not with the slides package, it's with the content I want to put on the slides: https://github.com/Dherse/codly/issues/35 and in particular, this comment from the author of codly where he sounds constrained by Typst: https://github.com/Dherse/codly/issues/35#issuecomment-24667...

My impressions with Typst have been very positive, though I did notice the same issue with Codly. Typst is still quite a new tool, so my expectation would be that this kind of issue will be fixed at some point.
Post reply on HN