Is Typst an option for our PDF translation?

[ds26gte]

Typst is a markup language and a converter to PDF that seems more author-friendly and efficient than LaTeX (which we don't use now but once did). Its markup is also fairly similar to AsciiDoc, so a very small amount of preproc of our source docs should make them amenable to Typst processing.

Typst is still being actively developed, but already it has turned the heads of many inveterate LaTeXers, so long-term we should probably investigate using it for our own PDF generation, replacing Puppeteer.

[schanzer]

@ds26gte making sure I understand -- your proposal is that we still write in asciidoc to generate, but then add a preprocessor to transparently convert to Typst and then make PDFs from there?

How do we ensure the web pages and PDFs look similar?

[ds26gte]

Right now we have

                                                        *.css
                                                             |
                                                             |
                                                             v 
*.src ---rkt---> *.asc ---asciidoc---> *.html ---pptr--> *.pdf

With Typst

                                                       *.css
                                                              |
                                                              |
                                                              v
*.src ---rkt---> *.asc ---asciidoc---> *.html
   |
   |
   `---rkt'---> *.typ ---typst---> *.pdf
                         ^
                         |
                         |
                     *.typ,styling

Typst isn't just a markup language but also embeds a fairly powerful extension language that can be used to style the output as shown in the second schematic. It promises to be more manipulable than CSS. Just as with the .css,the styling .typ files are shared and can sit under lib/ or shared/en-us/.

The converters from .src to .asc and *.typ respectively can share a lot of code, indeed can be the same code with a disambiguating command-line option. The diverging second steps in the two schemaics also gives us the chance to have two experts, one in HTML/CSS and the other in Typst (even if it is the same person), to tweak the two outputs without unduly worrying they'll step on the other's toes.

[schanzer]

It is absolutely critical that web pages and PDF pages look as close as possible. Puppeteer allows us to print web pages almost perfectly, modulo and CSS differences between screen and print media. Almost semester for the past 2 years, I've done a fairly massive CSS/infrastructure overhaul in order to bring the CSS for print and screen one step closer into alignment (FillVerticalSpace, flex, flex2...), and there's another one in the wings already.

I am very nervous about the web and PDF versions of workbook pages diverging, and using Typst makes that incredibly likely. What are the problems that such a switch would solve?

Is it speed? PDF generation isn't that slow (~9m on my 4-year old intel laptop), and we don't do it often unless we are proofing and printing workbooks.

Is it complexity? Your ascii graph makes it look like a move to Typst would be more complex, not less.

Given the incredible risk of display glitches between AsciiDoc->HTML and AsciiDoc->Typst->PDF, there would need to be either massive gains made or massive problems solved to make this worthwhile. Right now I'm just not seeing the value proposition.

[schanzer]

@ds26gte spoke to Shriram last night about this, and he's even more skeptical than I am. Unless you have a really strong answer to the "what problem does it solve?" question, sadly I think we need to close this

[ds26gte]

Fine with this actually: My purpose was only to bring this to your radar!