Hacker News new | ask | show | jobs
by __mharrison__ 21 days ago
I'll give an example.

I write Python, software engineering, and data science books in Jupyter. (Because I want both text and code). I've written my own toolchain (multiple times, don't ask, yes, I've tried the one you're thinking of and it didn't work for me).

I need to convert the notebooks into chapters in my books (PDF so I can print them). In the past, I used code to convert to LaTeX. (It was horrible).

Now, I use code to convert the Jupyter file to markdown, then (I use pandoc too) to typst. (It is 100x better than LaTeX).

(I also use pandoc to convert markdown to epub).

2 comments

> (multiple times, don't ask, yes, I've tried the one you're thinking of and it didn't work for me).

I know you didn't want questions, but maybe you can save me some trouble?

Assuming you're talking about quarto, may I ask what you didn't like about it? I've been converting some of my course materials to it and have been enjoying it immensely.

Quarto is one of them. When I checked it out, it wasn't usable for printed books (focused on papers). At that point (it's even easier now), I just painted my own bikeshed rather than dealing with others' weird angles and flooring.
For what's it's worth you can render Jupyter notebooks directly from Typst using the Callisto package. You can then style the notebook content as if it was written in Typst, using show rules, etc:

  #import "@preview/callisto:0.2.5"
  #callisto.render(nb: json("notebook.ipynb"))
though as the sibling comment says Quarto also works great for this, and Typst doesn't do epub (yet?)
Again, this is simplistic and not appropriate for a printed book...
I'm curious what would be a good example of something where this falls short of what you need?

I mean this Typst package just lets you import the notebook content in your Typst document. All the formatting is done in Typst which is also what you use for your final output...

Sidebars, front matter, index entries...
(Callisto author here)

Front matter would be fine I think. The static parts you would write directly in Typst. For the outline you would call #outline() as usual in the Typst document: notebook content is converted to Typst content (using cmarker), including the headings which become Typst headings so they show up as expected in the outline.

For sidebars I guess you use pandoc-Markdown extensions such as Divs that you transform with a Lua filter? What I would do then is use raw cells in the notebook to define sidebars (using Typst code in the raw cells) and configure Callisto to eval the raw cells.

For index entries, for example using the in-dexter package you could use HTML comments to insert index references where appropriate:

  <!--raw-typst #index[Entry]!-->
but I would just write #index[Entry] directly in the Markdown text, and use a show rule in the Typst document to convert them:

  #show regex("#index\[.*\]"): it => eval(it.text, mode: "markup", scope: in-dexter)
Overall, I think pandoc-Markdown + filters + Typst template is powerful and conceptually straightforward: you define the data structure with Markdown, you transform it with filters and render with Typst. Having the document as a well-defined data structure you can manipulate is especially powerful and something I wish we had in Typst.

In practice though it often feels overly complicated for little gains, when you can get things done with one tool and a single language (well, two since we're talking about including Jupyter notebooks).

Also working directly in Typst has advantages like live preview (also for content imported from notebooks), and some things that are a bit involved with pandoc, like maybe showing a cell output in a sidebar, become super easy: just add "#| label: my-cell" and "#| output: false" in the cell header, and #output("my-cell") in the side bar.