Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Typesetting Engines: A Programmer's Perspective

blog.ppresume.com

Post reply on HN
Print view View original

31–40 of 55 posts

Re: Typesetting Engines: A Programmer's Perspective

#31

Post by phonon »

xiaohanyu wrote: post #21
phonon wrote: 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.

That's pretty indirect....you might want to look more closely... https://drafts.csswg.org/css-page/ covers quite a lot...

You also didn't mention the new (Chrome only) CSS text-wrap: pretty

https://developer.chrome.com/blog/css-text-wrap-pretty

https://docs.google.com/document/d/1jJFD8nAUuiUX6ArFZQqQo8yT...

https://chromestatus.com/feature/5145771917180928

Re: Typesetting Engines: A Programmer's Perspective

#32

Post by __mharrison__ »

xiaohanyu wrote: post #24
__mharrison__ wrote: post #12

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)?

I feel like LaTeX is very hard to really learn. I wrote it for years without really understanding it. (Still don't).

I asked what was the best book for learning LaTeX. The response... "There is no book. Sit next to someone writing their dissertation."

Typst on the other hand, feels modern, is readable, and is fast. (4 seconds vs 2 minutes for some of my books.) The developers are responsive.

My only complaint is that some of my code broke during the latest release. I'll not complain too much because of is a nascent project and still making quick progress.

After I realized that Typst had the features I required for my books, I immediately moved to it.

Good riddance LaTeX. You served me well, but I felt like there was never a better option... Until now.

Re: Typesetting Engines: A Programmer's Perspective

#33

Post by __mharrison__ »

endgame wrote: post #14
__mharrison__ wrote: post #12

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.

Typst looked promising, but the very first thing I wanted to do with it - generate some slides with code snippets, and use highlights to call out specific features of the code - is not possible. The core layout engine seems to merge `styled(...)` spans in code blocks far too aggressively, making it impossible for codly (the code highlighting package I tried) to pick out precise ranges to highlight. I went back to bea…

Did you file an issue? The devs are quite responsive and now is the time to act while it is making quick progress.

Re: Typesetting Engines: A Programmer's Perspective

#34

Post by doabell »

nicoburns wrote: post #28
chrismorgan wrote: post #26

Earlier quoted context omitted.

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.

Yes, for Chinese & Japanese, not breaking words is nice, but not always practical. Maybe if you’re writing a speech, so as not to mispronounce the word in the 5% of cases when that happens. The CSS line-break property pretty much sums up the actual rules. Some apps do ship a dictionary to allow for double-click selection of words. They don’t always get it right, though.

Re: Typesetting Engines: A Programmer's Perspective

#35

Post by Tainnor »

cafard wrote: post #20
sundarurfriend wrote: post #18

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

And then there's Greek.

Re: Typesetting Engines: A Programmer's Perspective

#36

Post by chrismorgan »

chearon wrote: post #27
rikroots wrote: 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 c…

Sadly that doesn’t work with Indic text. Take for example, my name:

  క్రిస్
Ideally it’d render about the same as my manual splitting/colouring: https://temp.chrismorgan.info/%E0%B0%95%E0%B1%8D%E0%B0%B0%E0....

Now sometimes you can colour parts differently: if you stick with the inherent vowel on a conjunct, here making it LETTER KA, SIGN VIRAMA, LETTER RA, ditching the VOWEL SIGN I, then essentially the K from KA and the A from RA will be coloured LETTER KA, and the R from LETTER RA will be coloured SIGN VIRAMA. I haven’t decided yet if that’s an improvement! But this split colouring I only see in Dropflow—I’m not experiencing it in Firefox or Chromium, both of which do split Arabic colouring.

Re: Typesetting Engines: A Programmer's Perspective

#37

Post by liendolucas »

Surprised that groff is not mentioned. I've recently used it to typeset my CV and oh boy... It feels like something really really arcane. Despite fighting with it at the beginning I'm quite happy for the result and also like that I can now version the code (no more LibreOffice for that). The key difference between typesetting and textprocessing is that typesetting is like programming a document, you have basically access to common functionality offered by programming languages, which of course gives you a lot of power and flexibility. The thing I do complain about groff is its documentation (man pages are like very crude to follow on commands) and also there are almost no resources (tutorials, recipes, guides) out there.

Re: Typesetting Engines: A Programmer's Perspective

#38

Post by hsfzxjy »

chrismorgan wrote: post #26
sundarurfriend wrote: post #18

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

> CJK line breaking is awful

It's not true for Chinese. Chinese allows line breaks after any characters.

Re: Typesetting Engines: A Programmer's Perspective

#39

Post by vkazanov »

Tainnor wrote: post #35
cafard wrote: post #20

Earlier quoted context omitted.

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

And then there's Greek.

And Greek alphabet is sort of a base for both major groups of European alphabets, Latin and Cyrillic.

Can we just say greek-based alphabets?

Re: Typesetting Engines: A Programmer's Perspective

#40

Post by messe »

xiaohanyu wrote: post #23
sundarurfriend wrote: post #18

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

> Originally I adopted the word of "Germanic languages" then I found Spanish is not a Germanic language

Also worth noting that out of those you listed, Russian is also not a Germanic language (it's Slavic), and does not use the Latin alphabet.

Post reply on HN