It does look sweet! I can see that taking over latex.
Someday, I hope scientific journals can all agree on a standard for mobile display of articles. Maybe something like a Typst template for it. But it probably wouldn’t be a PDF file.
Traditional style and my own preference dictate that indentations separate paragraphs, so the first paragraph after a non-paragraph element (like a heading or a list) should not be indented. This is a common typographic convention, but to do it in CSS is impossible in the general case without dozens, maybe hundreds of selectors to handle every special case. In Typst, you just give paragraphs a first-line-indent, and they know when to use it.
p+p {text-indent:5em} seems pretty simple? I just did a quick test and it seemed to work when I broke up a few paragraphs with an h1, a ul, and a div. This isn't anything esoteric, it's CSS2 stuff that's been working for twenty years. Though "typst breaks lines 500% better than most browsers" is a compelling argument on its own.
There’s both very little and a lot that can’t be done in CSS when it comes to proper typesetting.
p + p { text-indent } absolutely works and has been my go-to method of implementing proper paragraph indentation for as long as I can remember. Impressive drop caps, hanging punctuation, etc. are possible with some effort.
However, balancing lines, hyphenation, eliminating rivers is something that browsers don’t do or do not as well, and custom kerning is painful.
If there is something that handles typesetting on par with InDesign but without the bloat and in a friendlier format, that’d be neat, but I wonder how long would it remain bloat-free considering features that would be needed.
What about the non-cloud version of InDesign (CS2, maybe CS3?) that Adobe made free for download around 2013-2014? This timing was related to the Adobe Creative Cloud being released in 2013, eleven years ago this week.
While I believe others at Adobe later backtracked and decided that the noncloud suite was no longer free _and never had been_, that has been discussed on HN elsewhere.
Typst seems like a real contender for LaTeX. I've used and hated LaTeX for over 20 years. That the horror that is LaTeX is still the least worst typesetting system for print is really depressing.
I've been waiting for Typst to get HTML output. It's been under development for quite a while but seems to suffer from some bikeshedding [1].
Glad to see there's Pandoc support for Typst HTML (and LaTeX) export as a workaround. Gotta try it for my next paper!
Hey, Typst dev here. Regarding HTML export: It's not bikeshedding. It's more that, while we consider HTML as pretty important, we decided that fixing and improving the layout engine first was even more important. Basically getting what we have already right before starting to do more stuff.
That said, our plans for HTML export have definitely become more substantiated and concrete over the past year and once the current work on layout finishes, it is the next big thing on our list.
My bikeshedding fear came from the Github issue (forgot the link in the comment), where there is IMHO definite bikeshedding about e.g. tag names. But indeed, there seems to be important architectural concerns.
You can have all that and more with TeXmacs (http://texmacs.org) and actually enjoy the writing as much as you hope for the reader to enjoy a properly typeset document instead of a fixed width font, and abstruse markup everywhere.
Typst is a better 70s answer for a 70s-level ambition, which is a fine level of ambition when you're just out of punch-card programming.
The commenter is referring to the editing experience, not the rendered output. Most people edit stuff like typst and (La)TeX in a code editor with a fixed-width font.
Emacs supports variable-width fonts just fine and in theory you could use variable width for the "content" and reserve fixed width for the code. Not sure how well it works in practice, though. Of course, that doesn't go as far as TeXmacs.
Typst is a 2-pane editing experience. What you edit is ugly, even if less ugly than LaTeX or (gasp!) XML.
TeXmacs is an interactive typesetter. It typesets as you go. You can mark chunks of content up (semantically or visually or both) the way you do with any other batch-based typesetter, but you don't need to suffer the markup when you look up at the matrix, integral or set-theory equation you wrote on the paragraph above.
I must be missing context here but I thought we were past side snarks out of mere generational antagonism. If not, please enlighten me ;)
Anyway, comparing XML against a compact syntax a la markdown or typst (AIU!) is besides the point: XML is just meant as canonical SGML syntax for delivery to browsers while full SGML has all the additional features for editing, such as short references (custom Wiki syntax token mappings for eg markdown support), tag inference, and LPDs (restricted element and attribute transformations), that together deliver quite powerful authoring and content app capabilities without turning into a full-featured programming language. HTML, without doubt the most important markup language, is based on it after all though the vast customization features of SGML really favors building your own project-specific Wiki syntax that's then mapped to a rendering vocabulary such as HTML).
Yeah, what people miss is that for everything you write you will read it at least 10 times. Why go through the unnecessary pain of reading the markup yourself?
The TeXmacs webpage does not do a great job of undoing the main confusion around it: TeXmacs is neither (La)TeX-based (it has its own typesetter), nor it has much to do with Emacs. Except perhaps that it is enormously configurable with a Lisp-based language, Guile Scheme.
You could say: the rendered output (interactively or as PDF export) looks as good if not better than if it was done with (La)TeX, and the editor can be customized to a degree similar (perhaps a little less?) than Emacs. Hence the name.
Incidentally, being able to customize Emacs with a Lisp other than emacs-lisp, is something the Emacs community would probably like, and there were in fact (now stalled) efforts to do so with Scheme.
The best part of TeX always was that you only had to deal with text. Trying to write something like TeX, but being forced into a Word like graphical environment felt easily to be the worst of both worlds.
It's hard to understand what is wrong, let alone do something about it when complaints are so generic.
At the same time I understand your sentiment. After all, TeXmacs hasbeen for a long time a one-man effort. Joris was doing everything: programming, documentation, website, community support... How many people work/have worked on Word?
Sometime ago I brought Affinity publisher (I have no affiliation with them, I got it because it did not require a subscription). It is a desktop publishing application, so the intended use case is that you make the text separately and then you setup a layout and include the text.
And honestly, I think that is the better way to go. You don't have to chase down weird commands (how do you set LaTeX to use Lato as the main font again?) and you get instant feedback on how things look.
I haven't found a way to mark text up as "this is a blockquote" and then have that mapped to the correct style, and it seems to lack a few of the more esoteric font features LaTeX does support. The fact that you get instant feedback and can tweak the relevant knobs as much as you like? That means you get a much nicer layout.
If you have a Windows machine with the Office package, you get Microsoft Publisher, which I believe can import Word documents and extract the style from that.
Scribus can map styles from imported files, but last time I checked I couldn't get it to auto update the view when you changed the font.
Thats my point - we should consider manually do the layout of our design. It is both better and give you a much tighter feedback loop.
I do strongly disagree that they are not in the same category - they both solve the problem of "taking this text and turn it into a nice PDF". If you assume that this must happen through scripting, then that is exactly the point I was questioning.
https://typst.app/
And the results have been fantastic when compared with the asciidoc version we created initially. The repo is here if you want to see how he uses it:
https://github.com/bigskysoftware/hypermedia-systems-book
You can fork it and build either a pdf or epub using the just commands: `just build-pdf` and `just build-epub`. I also uploaded the epub to libgen.
We also had a pixel artist do a new cover for the paper back version:
https://pbs.twimg.com/media/GSsMjBra4AAOQZ_?format=jpg&name=...