reknih

Front Door is down for us (as Azure‘s Twitter account confirms)

We're pretty close, actually. The PRs for accessible PDFs [^1] and their associated documentation [^2] are landing next week.

[^1]: https://github.com/typst/typst/pull/6619

[^2]: https://github.com/typst/typst/pull/6905

For the upcoming release, we decided to prioritize print layout and the shortcomings we have there. The release after (think late fall) will focus on HTML and accessible output. The plan is to create a turn-key solution for technical writing, docs, and document automation.

I put the buttons on the bottom so the user would not be overwhelmed by options at the start. Interesting to hear you'd prefer them on top of the table!

Suggesting similar characters would definitely a nice feature, I'll add it for basic cases.

No worries!

Author here: this is the fault of Adobe Acrobat unfortunately. I converted the thesis to PDF/A using that software and redacted my student registration number. Acrobat apparently did not like my file, therefore it converted many pages to images.

You've got mail!

Yes, there will be a template producing equivalently looking (and more accessible) PDFs for Physical Review and the likes.

Yeah, that might be a problem that must be gradually solved through partnerships, outreach, and an eventual community. We already talked to a publishing industry rep about this.

In the meantime, many conferences just want camera-ready PDFs for their proceedings. Additionally, Typst will be useful in a university/lab/research group context and for tech reports right away!

We are targeting PDF and raster graphic output at the moment. Typst is designed to allow HTML export and we do have our eyes on it. At the moment, however, we want to focus on getting PDF export right, including options for standards like PDF/A (archival) and PDF/X (professional print).

ePub is a subset of HTML so the latter would come first.

We will maintain a version history and offer the typical change tracking features, but this will likely be a paid feature for users who join after the beta.

The editor is a web app! Because we build Typst in Rust, we are able to deliver it as WebAssembly and embed it into the web site.

Hey, I'm working on Typst. We try to open source Typst's libraries as soon as they are ready. The same goes for the Typst compiler: it will be open source when we go into beta.

We do not want to lock anybody into our service, so you'll always be able to download Typst for the command line for free. Only the web app will remain proprietary.

This is not really a meaningful comparison: You have your TeX compiler (pdfTeX, XeTeX, LuaTeX, and the older e-TeX) that takes a document in some format and produces a PDF or DVI. In my tests (that did not include e-TeX) pdfTeX tends to be the fastest here, but sometimes you need modern fonts, so you have no choice but to use the other two.

The TeX compiler then loads a format like plain TeX (which the above commenter uses), LaTeX, or ConTeXt. The format defines what macros are available. LaTeX adds a package system, as does ConTeXt (modules) so you can import even more macros on-demand. These TeX formats differ in scope and thus speed, LaTeX tends to be a bit heavier but what really weighs it down are the myriad of packages it is usually used with.

Many TeX distributions will define aliases like pdflatex in your path such that you can preload pdfTeX with the LaTeX format, but they are not really separate compilers.

Very valid concern. We aim for an open core model so you can always take your projects and compile them locally

I figure I should also mention that my LaTeX alternative is called Typst. We do not have much public detail yet but there is a landing page [1] to sign up for more info and beta access as soon as it becomes available.

[1]: https://typst.app/

IMO draft seems like a crutch: Because TeX has to reprocess the whole document and the sty-files of each imported package every time, you do not have a huge budget for your document content. Instead, you are given the option to sacrifice image decoding, plot drawing, and output fidelity to keep TeX humming along.

Sure, that's better than nothing but I cannot help but wonder whether there could be an architecture where you cut down on repeating work and get faster recompiles that way!

In use cases like the Markdown to PDF pipeline described in the article, sure! Documents there are also simple enough so that compile times aren't too much of a problem.

However, many of the documents we like to set in TeX are more complex than that: bibliographies, figure placement, special typographical flourishes.... And here is where the complexity of LaTeX and its macros adds to the inherent complexity of what we are trying to accomplish (and compile times quickly ballon again).

So, sometimes it helps...?

The LaTeX criticisms of the article really resonated with me. Long compile times and a narrow "happy path" are the things where I feel LaTeX makes me less productive.

This is a pity because, otherwise, it is a great tool with its focus on document structure and output quality. I'm currently working on a LaTeX successor which seeks to address these issues, but it is really hard to make the right design compromises here -- what can be programmed? What is accessible through dedicated syntax? How does the structure drive presentation?

Computer typesetting is a rabbit hole, but a fascinating one. And I'm sure the last word on it has not been spoken yet :)