Hacker News Reader

Comment by sprinkly-dust | Hacker News Reader

Having composed many pieces of coursework using Typst, I must say that it certainly makes academic writing more streamlined, engaging, and dare I say fun — though that might just be me. The functional nature of Typst's syntax ensures I don't have the erratic behaviour emblematic of modern day Microsoft Word and sometimes even Google Docs. Using a local IDE such as VSCode brings all the features one could like.

In comparison to LaTeX, overall document typesetting is far more straightforward. However, for long multi-page stretches of equations solving, I feel that LaTeX is easier to type than Typst because its syntax is not that of a functional programming language but more akin to markdown. Thus, one does not need to think as far in advance when typesetting equations with lots of functions, superscript, and subscript.

View on HN

Having composed pieces of academic writing, I would like that, journals would start to supporting typst, or, plugins/bridges to LaTeX/Word would fall in place.

For now I would not chose to write a paper in typst, because I most certainly need to convert it once it leaves the institution (even arXiv require LaTeX source).

Tooling around LaTeX is quite good today, with a plethora of IDEs helping. Personally I use Emacs' Org-Mode which compiles to LaTeX.

The only thing I need to start writing more serious documents with Typst is an equivalent to latexdiff. But I really think (and hope) that this will replace latex in the future. Alone the compilation time makes it so much nice to use! Meanwhile I am supporting them by having a pro account, which is not even so expensive.

Arxiv will accept a rendered pdf, no source files required. Are any special features unlocked if source files are uploaded?

They autoconvert latex to html. Typst can't currently produce html output.

Just for completeness the html export issue is here: https://github.com/typst/typst/issues/721

Quarto can convert to typst, html, and LaTeX through pandoc.

Typst is missing vital features to produce professional looking documents. Latex and Adobe InDesign use paragraph based algorithms for line breaks and hyphenation (see http://dx.doi.org/10.1002/spe.4380111102 for Latex). That is the main reason why papers written in Word look so amateurish. Proper support for footnotes seems to be also lacking in Typst.

Footnotes might be handled properly in a future version of Typst. Regarding paragraph formatting I'm not so optimistic. I've read the thesis and papers by one of the Typst authors. They either don't seem to be aware of better approaches or they simply don't care about aesthetics.

Edit: Another thing that irks me about Typst is that it does not seem to be a purely not-for-profit project. It is tightly entangled with their commercial offering, whatever that might mean for the future of the "free" version.

I'm not sure what you're referring to because when justification is enabled Typst uses almost the same line breaking algorithm as TeX. [1]

One problem we had was over-eager hyphenation. We've addressed that recently. [2]

[1]: https://github.com/typst/typst/blob/9b001e21121ab7b5645aa36f...

[2]: https://github.com/typst/typst/pull/4584

That is great news! It wasn't there the last time I checked. Maybe I missed it. Thanks for clarifying!

FWIW there is already partial LaTeX support for Typst via the mitex package:

https://github.com/mitex-rs/mitex

This is interesting! However, I suspect general TeX support in Typst is probably impossible unless you re-implement the entirety of TeX within Typst somehow. The TeX language has some really terrible properties. For example, the tokenization rules can be dynamically changed at runtime based on the output that has already been produced. E.g. you can write a TeX file that says "typeset this paragraph, and if the result is an odd number of lines, change the meaning of A from letter to open brace". Thus, fully supporting TeX within Typst would seem to require making all of the internals of Typst available to the TeX runtime.

Is that just common constructs, or can I pull in amsmath and other similar packages?

As someone who almost never needs equations, does this have any benefits to me over using markdown?

It depends on what you are doing with your markdown files. For example, if you are using them as the source for a statically generated website typst won't do much for you.

You have more control over the style and structure. If you use markdown + css, that's a different story.

Yea that is my setup right now.

I write markdown and use eleventy + nunjucks templates to build the final result.

It’s pretty easy to create new layouts and styles for really any use case with that setup in minutes.

If that's the case, I don't think you will get any benefits by switching to Typst.

With or without equations, just use MonsterWriter. It gives you LaTeX results without needing to know what LaTeX is.

But, yes LaTeX has other benefits, e.g. citing references, or creating PDFs according to layout and typesettings best practices.

MonsterWriter is your product, correct?

It is customary to add a short disclaimer when you're promoting your own product or project.

Yes it is my own product. Sorry for not pointing it out.

I would say probably not.

Markdown is really more about getting words down in plain text with a very simple structure for rendering on the web.

Typst and LaTex make stark distinctions between composing and typesetting. They are programmatic typesetting systems with very structured and fine grained control over the look and design of a document once it's compiled and rendered as a PDF.

If all you're doing is writing prose then I honestly think typesetting programs are overkill unless you do want very fine grained control over how your documents look.

You've had some good replies already, but just want to add my thoughts. Markdown to me is more about (a) the content (the actual words) and (b) the semantics (text emphasis, headings, etc, which communicate information about the importance or meaning of particular things).

Typesetting systems like Typst or LaTeX go beyond this. They're also about presentation, how precisely it is laid out, on mediums such as print or PDF. Is that something you need? If you care more about the content and its meaning, and are happy to have it rendered differently in different situations (a preview in Visual Studio Code, or passed through a markdown-to-html renderer, or viewed in Obsidian, etc), then Markdown might not just be fine, it may be preferable. But if you need to do things like print this on paper for mailing, email in a PDF, that sort of thing, then you'll want something more.

A few Markdown documents I've converted to PDFs:

* https://impacts.to/downloads/lowres/impacts.pdf

* https://whitemagicsoftware.com/softcover/technical.pdf

* https://whitemagicsoftware.com/softcover/jekyll-hyde.pdf

Respectfully, keeping presentation logic and content completely separated while having precise control over layout can happen with Markdown, as the example documents demonstrate. The ConTeXt typesetting system makes keeping such separation possible.

The deeper issue relates to the software's architecture, which, IMO, systems like Typst, Obsidian, and others fail to generalize broadly enough. Here's KeenWrite's architecture (the "Proposed" row):

https://gitlab.com/DaveJarvis/KeenWrite/-/raw/main/docs/imag...

Although only Markdown is currently implemented, it's possible to plug other text-based input formats to produce an XHTML document. The instructions for how to typeset XHTML documents are defined by a theme. You can think of a theme as an XML to TeX translation layer. From there, going from XML to TeX is straightforward (when using ConTeXt, at least), allowing full control over the final output format (be it PDF, ePub, and so forth).

I am the author of KeenWrite. The following tutorial shows how its themes work:

https://www.youtube.com/watch?v=3QpX70O5S30&list=PLB-WIt1cZY...

>A few Markdown documents I've converted to PDFs:

These aren't Markdowns converted to PDFs. These are HTML websites rendered as PDF, where at some early point some text with basic formatting was fed in.

>keeping presentation logic and content completely separated while having precise control over layout

Does anyone really want that? I certainly wouldn't want that separation. I want to create some document and not a sophisticated template, so I am always willing to sacrifice generality over momentary needs, if I can't force the layout, then I need to waste time to implement some generality, which I don't need. Completely the wrong approach to document creation.

This looks like you really want to have a web framework, not a document creation system.

> These aren't Markdowns converted to PDFs

Would you like to see the source Markdown documents? My workflow is:

    Markdown -> XML (XHTML) -> TeX -> PDF

If that isn't converting Markdown into PDF, what would you call it?

> Does anyone really want that?

At time of writing KeenWrite has had over 4,000 downloads. So, maybe? However, my point wasn't whether people want it (besides me). My point was that it is technically possible to keep a Markdown document's content separated from its final presentation form (e.g., PDF).

> This looks like you really want to have a web framework, not a document creation system.

Not really: I want to write in Markdown (or R Markdown) using interpolated variables and generate PDF documents. I have spent about 9 years working on a cross-platform desktop text editor that allows me to do so.

>Would you like to see the source Markdown documents?

I am pretty sure I know what they look like from the end result.

My point was that almost all of the design effort wasn't contained in the markdown. So clearly there were at least two major inputs to the documents. But of course you agree with that.

>Not particularly; I want to write in Markdown (or R Markdown) using interpolated variables and generate PDF documents.

To me the total separation only makes sense if you are designing for unknown content. If you control the input of content and formatting, then a closer linkage between both seems superior. Markdown is (intentionally) extremely limited, so everything that markdown can't do needs to be implemented in a general way on the formatting layer. Obviously that is more tedious if you have total separation.

What I meant by "web framework" is that they can't assume content, so need to deal with generality. Essentially what you are writing is a website generator, except with PDF being the end output. But generating general and reusable components doesn't seem to be how I would want to create a document.

Typst deals with documents, so if you want to prepare an actual document, with a defined page layout, style, font, etc. typst gives you that.

Markdown does not do any of that, it just gives you html.

You would want to use typst if you want to create a document and need to control how that document looks from the language itself. Even if you were to render the markdown html to a PDF, markdown itself, or even css doesn't give you control over many parameters of the output document.

There basically is no competition between the tools, they target different output formats.

I've done .doc -> .md -> .tex -> .pdf via pandoc (e.g. to convert a confluence document to a nicely typeset PDF), so I'm not sure there's much difference.

Naturally, a format with more metadata loses metadata when converted to one with less (and the reverse, you may need to add metadata in when going up the chain), but unless your document is bound to a specific format (in which case, I'd pick RST for HTML and LaTeX for pdf), markdown gives you the content and pandoc lets you specify a template (and with pandoc, you can take the markdown and generate slides in HTML, PDF and create notes through the different outputs).

Conversions don't just loose metadata, you loose the ability to specify things. LaTeX shines because it can do everything by itself, markdown clearly can't and even with a TeX template you loose much of TeX's power.

You should start out by defining your desired output and needed input. I realize that 99% of document content can be fully realized in markdown, but the 1% can easily be a total deal breaker and make using markdown a complete nonstarter.

Markdown doesn't give you a table of contents, an index, page breaks, control over typesetting, control over table layout, captioned figures, diagramming tools, etc. The difference is about the same magnitude as between Pong and Call of Duty. Yes they're both video games, sometimes one is preferable over the other, but they are not equivalent.

Pandoc/Quarto markdown gives you most of these.

In my experience, it rarely really matters fine control. If the effort is too big to tweak the templates/markdown you export it to an intermediate state (LaTeX/Office/whatever) and drop the original markdown source.

There is no lock-in.

Exactly, and I need those features, I'd use LaTeX (and if collaboration is needed, either git or overleaf depending on who I'm working with). For a ~1 page document of text, where there is minimal markup required, markdown through pandoc produces a nicer looking document than using the output from web-based editors (e.g. google docs, confluence), which is typically where I'm starting with .doc.

What are you doing with Markdown? My own requirements for a format are:

* 30 year viability. * simple but explicit formatting: I need to specify font size, underline, and red text. * clarity in writing is almost as important as clarity in reading, so I am not fond of formatting directives mixed in with text.

That led me to RTF, since Markdown fails on the second and third point, and LaTeX fails on the last. But you have to determine your own requirements from your use case.

Reply on news.ycombinator.com