How much is lost of Typst features by using cmarker package?

Questions
1

Hello!

I’m using Tiki for my web content where I can write Markdown and consider using it as single-source format. The question is how much of the Typst functionality would be lost if using cmarker package for my PDF-output needs instead of using all Typst functionality, both markup and typography-wise?

2

(this just what comes to mind, not a complete list)

  • Obviously, Typst has far more features than CommonMark, most notably functions – you are missing out on the ability to create reusable snippets.
  • Also, I consider typst math syntax to be much more user friendly than the latex one, but you can’t use that via markdown. (altough i think Zola is working on supporting it)
  • cmarker seems to allow for raw typst snippets, but you wouldn’t see those in your web version
  • I don’t think you would lose any automatic typography features

I would consider trying the “other way around” where you have typst files as your source of truth and using typst to generate html output for the web (and then using some html templating system to integrate it into your site, adding navigation and such around the content).

2 Likes
3

I’m doing this same evaluation right now. I’m working on content that needs to be flexible enough for deployment to Microsoft Word, PDF, .mobi, and HTML. So, my desire is to use Markdown as the source-of-truth format, Pandoc for the stuff Typst doesn’t support, and Typst for PDF because I can’t deal with any more LaTeX.

I’m converting content now, and finding some edge cases where things aren’t working as I’d hoped. I think there are some ways around that with show rules, or in a clunkier way with cmarker’s interleaving typst/markdown content, and also the raw typst options.

I considered @nleanba 's suggestion of just standardizing on typst markup … but that is not going to fly with the rest of my team, who is reflexive with Markdown and doesn’t care to learn typst markup.

One example solution I just worked out today: I wanted to be able to use #smallcaps[foo bar] in Markdown, but it of course doesn’t work that way.

I don’t want to run eval on the cmarker result, either. So I did this:

#let smallcap-magic = regex("#smallcaps\\[(.*?)\\]")
#show smallcap-magic: it => {
  let capstr = it.text.matches(smallcap-magic).first().captures.at(0)
  smallcaps[#capstr]
}

… which might work. Just playing around with this approach for now. I am looking at Pandoc add-ons (like pandoc-sidenote) and seeing things that might work for processing using this approach.

Hope that’s semi-helpful. I’ll come back to this thread if I discover more dramatic shortcomings.

1 Like
4

genuine question, what’s the point of using typst if you’re not using any typst features? can’t you just use pandoc to convert md to pdf?

1 Like
5

For one thing, typst is exponentially faster than any of Pandoc’s methods for converting Markdown to PDF. Second, layout, set/show rules, all of that stuff can still be applied to content converted using cmarker.

So, you’re not really giving up on much. And if the world you’re living in involves multiple team members who are hardline on Markdown, but want to integrate with other things typst can do (such as dynamically drive tables and so on with yaml/json, etc) … there are reasons cmarker makes sense.

If you’re thinking that all typst can do is render content that’s been typed up with typst formatting rules, you’re missing out. :wink:

3 Likes
6

Just chiming in----the cmarker package is definitely handy for mixing Markdown with Typst.

That said, from my own experience, you might want to check out Quarto as well. It is a Markdown-based publishing system that provides a robust way to create PDF documents using Typst (see known limitations). In addition, Quarto supports the full range of Pandoc-powered exports such as HTML, Word, and ePub.

1 Like