I've moved all of my LaTeX-based content creation to Typst.
It's:
- Fast—Compiling my books would take around 1 minute (I often had to compile twice due to indexing). With Typst, it takes less than 5 seconds.
- Easy to write—I actually don't write it, I wrote a bunch of Pandoc plugins to tweak the output from Pandoc (I write all my books in Jupyter these days, so lots of markdown).
- Easy to read—I've used LaTeX for years (and wrote a bunch of tooling around it) and still couldn't tell you when to use a { or a [. Typst is very readable.
- Easy to script—Okay, I did write some Typst the other day. I migrated my LaTeX-based invoicing system to Typst. I created a list of objects with pricing and count and was able to throw it into a table easily. It has less code than my LaTeX version, which was using a library, and is easier to read. (I did need to write a function to properly format $ because that doesn't exist. A few rounds with AI made that easy.)
- Has great error messages—If you've used LaTeX, you know what I mean.
My needs are different from others, but I'm writing PDFs that need to be printed into a real book that looks professional. This includes front matter, footnotes, callouts, page numbers, page headers and footers, and indexes. I don't do a lot of math-heavy stuff, so I can't comment on that. And the widow/orphan support is a little weak.
This trips people up a lot once they do anything involving cross-referencing or bibliographies. But for some reason some people use latex for a long time and never hear about latexmk, which automates all that, and can even "watch" your files so you can edit and save and see your PDF refresh all in real time. (I've only used latex for papers or blog math, not big books; I can't imagine waiting a minute per change back in college, let alone on modern hardware...)
With your experience of both, have you found that Typst has fewer issues with conflicting/non-commutative plugins than LaTeX does?
Because that's where I lose the most time with LaTeX: packages often mess with the (piles of) global state in ways that sometimes conflict, and the only "solution" seems to be that, if you're very lucky, sometimes conscientious package authors will try to "detect" (through various hacks) whether some other known-conflicting package has already been loaded and adjust accordingly. I didn't see any mention in TFA of any module system or even local variables in Typst to contain this explosion of complexity, so I suspect it will be just as bad in this respect as LaTeX is once there are as many plugins available.
Regarding math stuff and graphics/diagrams, it works well too.
What I enjoy about Typst is the fact that the code is easy to write and read. Even code from some third-party library or template is easy to understand. There is a world of difference between this and LaTeX, which abstracts over TeX, and whose inner workings remain obscure even to experienced developers having used LaTeX over decades for tens of documents.
The compilation of Typst documents is indeed also extremely fast compared to LaTeX.
The runtime and libraries are lightweight and easy to install, compared to LaTeX distributions.
Writing custom logic or even a fully-fledged template with Typst is easy to do from day one.
The only reason I still see to use LaTeX nowadays is writing books and papers whose editor only accepts LaTeX.
I've switched to Typst some months ago and not once have I thought it might have been a mistake. The only thing I regret is that there is no automatic migration of older LaTeX documents to Typst.
Editors still have to be improved, though the Vscode plugin is absolutely usable.
> Easy to script—Okay, I did write some Typst the other day. I migrated my LaTeX-based invoicing system to Typst. I created a list of objects with pricing and count and was able to throw it into a table easily.
Interesting! Would you share your solution and/or tell us a little more about it? Thanks!
Ooh, very interesting! I produce lots of reports using Jupyter and nbconvert. I have a custom nbconvert template (which uses pandoc+jinja+latex under the hood).
I find the whole system to be a bit house-of-cards and I’d love to try alternatives. What’s your workflow for using Typst with Jupyter?
References in established systems like LaTeX work the way they do for a reason: you don't want to embed words in them (like "Figure" or "Section") automatically because it does not work across languages.
Serbian (and many other languages) have suffix declensions, so while "Figure 4" is "Slika 4", when used like "in Figure 4", you really need "u Slici 4" (and lowercase, really) instead of "u Slika 4" as produced by Typst.
On the plus side, it seems to use OTF locl tables for substitution glyphs for language, though it only partially works for Serbian (might be due to bad locl tables for LinLibertine which seems to be the default font).
I am sure it's not too hard to only get the reference number (eg. @foo.context.something?), but defaults should be good or maybe per-language?
I can see how they wanted to avoid authors having to hard-code the reference type if they change eg. something from an image to a table, but it's hard to make it smart enough for any language.
Hopefully they'll improve the reference system and multilingual support. But if you want a simple number for a reference, you can call "ref(<label>, supplement: none)", or if you want this to be the default for the @label shorthand syntax you can set it globally with "#set ref(supplement: none)".
Also typst knows the type of the referenced element. It's easy to write more elaborate rules that behave differently depending on the type. And the rules can also check the current language to generate localized references.
Embedding words like Figure or Section breaks not only declensions, but capitalization, too. Germans won't notice it because all their nouns are capitalized, and English speakers won't care because they're traditionally forgiving with unmotivated upper-case words in the middle of a sentence (including titles). But formally it shoud be "Figure 4" in the caption and "as we see in figure 4" in the reference.
In the very limited time I used typst it has been pretty amazing, but imho there is one missing feature that a LaTeX successor, but even more so, templating engine should have.
Come up or adapt a format, that can defer certain styling decisions to the consumer of the document. Stuff like, font, font size, line spacing, citation style, double or single column, numeration style, etc.
On a different note, we got to find a better way to exchange data than pdf reports. In my totally made up estimation about 10% of development time for enterprise software is spend on variations of these pdf templating tools and another 20% on extracting data from such generated pdfs.
You can do that in a couple different ways in Typst. First, if the user passes content into the template, then it's the user's content that ultimately gets to choose its styling. That is, there are three places that a style can be set:
1. In the content passed that the user passes to the template
2. In the template itself
3. By the user, outside the template
They take priority in that order.
OTOH, if the template really wants control, it can take optional styling arguments with defaults, and do as it likes with them. And if it wants content from the user that the user doesn't get to style, it can take that content as a string.
> Come up or adapt a format, that can defer certain styling decisions to the consumer of the document. Stuff like, font, font size, line spacing, citation style, double or single column, numeration style, etc.
We have that, it's called HTML. The use case is quite different from PDF though.
That was exactly my reaction after stumbling upon https://typst.app/universe/package/modern-cv/ I just want a replacement for ModernCV, not downloading MBs of fonts I don't want to use.
You can embed attachments in PDFs. This way you could include CSV or JSON files into your PDF report. For a quick way doing it with CLI see `qpdf --help=add-attachment`
There is no universally correct layouting. I for one absolutely detest epub versions of scientific books. Even if they are the official variant and not a generated one from some other format that understandably sucks, diagrams will be all around and I have to go back and forth and lose context. PDFs for all their shortcomings are a godsend and they do their single job perfectly. I much rather zoom in on my phone to a paragraph than look at a badly placed diagram taking up half a page in an unrelated context.
I've been looking into it.
It's `blazingly fast` (aside from the rust joke, it really is way faster than latex), the syntax is more "modern", consistent, etc.
The main problem is the popularity. It just does not have enough packages, at least for my use case.
I mainly do a lot of equations (simple math), and a loooot of tikz (forest, circuitikz, pgfplots, etc.) [https://gitlab.com/vslavkin/escuela/-/tree/main/5to?ref_type...]
I'm not a fan of tikz, but it's the only way to mantain the graphics homogeneous, clean, easily editable, compiled with the document and with links/references.
Cetz (the typst alternative) is years behind.
I've been thinking of contributing, but tikz is really complex, and I don't have enough time ATM.
Besides the typst packages, it also lacks the editor packages. I am an emacs user insert joke here, and I use AucTeX, which is a really great, and gigant package to edit latex (+cdlatex). AFAIK there's nothing like it for typst, which makes me way slower.
Another thing is that they changed the math syntax. While the latex one wasn't perfect it was insanely popular, because of its use on markdown and a lot of pages (and this was thanks to mathjax iirc).
The good thing is that something like latex or typst will always be needed, so there'll always people that want to have something like it; latex/tex isn't really great, and it has a really low entry bar.
Maybe I'll switch when I have more time to study it and make packages. (It could be as soon as next year or a late as... never)
> Besides the typst packages, it also lacks the editor packages. I am an emacs user…
The typst editor plugin for vscode is pretty great. It gives you a split view of source & pdf, and you can cmd+click on either side to scroll to the corresponding source / rendered output. It also does things like give you autocomplete on fields from externally referenced json data.
Obviously, that might be no help if you’re married to eMacs. But if you’re a little promiscuous with editors like I am, give it a try.
I have a similar "user profile" and find typst a much better experience. It's true CeTZ is not as mature, but it's much easier to extend where it's missing functionality (because you have a nice, normal scripting language to work with instead of a macro mess). But math is the reason I smile every morning when I open my .typ files. It's so clean and readable, and a pleasure to write, compared to LaTeX. It's also not as mature so I can imagine some things can be tricky to do in typst depending on your needs. But it does everything I need, and is only getting better (I see that several of the annoyances I found are getting fixed in the next release).
Can't comment on the AucTeX part, I'm using helix and typst support is not great but good enough.
> I use AucTeX, which is a really great, and gigant package to edit latex (+cdlatex)
This is tangential, but have you any quick tips for someone looking to get started with AucTeX? I'm a comfortable Emacser who has started to occasionally think of some document I'd like to do in LaTeX (some maths questions for a student, or an overview of some topic). I've looked at AucTeX once or twice, and ran away thinking, oh, I'll do that some other time.
What is the order of events? Should I make a few really basic LaTeX documents first with a terminal, and then try AucTeX?
Judging from the releases page on Github, Typst has been in the public since May 2023. You can hardly expect it to catch up with decades of LaTeX packages in that time.
One of the worst things about LaTeX is its reliance on packages to do anything useful. In fact, LaTeX is itself essentially just a set of packages for Tex. I hope whatever replaces LaTeX finds a solution that covers as many usecases as possible without needing any packages.
This is neat. I've used Latex before, and it definitely suffers from poor ergonomics. Both the language and tooling contribute to this.
The selling point seems to be that this is more similar to Markdown. That makes sense, Markdown is objectively more common and has more users than Latex. I've used both, but Markdown way more often.
Here's something I don't understand: it would be trivial to make Typst even more similar to Markdown, and yet it exists at some strange middle point in the language design space, arbitrarily far from Markdown.
Well maybe it’s good to make it clear that it isn’t markdown to avoid confusion? Also Typst has less syntactic sugar which also has benefits.
More generally, I am really impressed by Typst’s abstractions. I have typset my whole PhD thesis in it without needing any external packages. It was so easy to use the basic building blocks and write a few extra functions for the rest.
Places I’ve switched from LaTeX to Typst: My resume, research papers. Markdown was never a serious contender for my resume, since I want to control the rendering and the layout.
Places I’ve switched from Markdown to Typst: Slides. There are some okay Markdown-to-HTML solutions, but they have this unfortunate side-effect that you move the slides to some other computer, and something breaks in your rendering. PDFs ftw.
I'm not sure the selling point is similarity with markdown, but rather, to improve, or modernize LaTeX/TeX-the-language/s: TeX is really archaic: if you're curious, there's a series of articles by overleaf[0] detailing some of TeX's inner-working, quite insightful.
I remember reading — but can't find a source at the moment — that TeX originally didn't had counters; people came to rely on Church numerals[1] instead, before Knuth finally implemented them.
Personally, I don't really care about it being similar to Markdown. After all if someone wants Markdown they can just use that... For me the selling point is that it provides almost the same features as Latex except with a sane scripting language. This allows me to actually write my own scripts, as opposed to Latex where even understanding how basic stuff worked was a huge pain.
As a side note, TeX engine could support Markdown or HTML or many other syntaxes too: it's easy to redefine control character in TeX to be anything instead or in addition to "\" (I've actually done that with Plain TeX a couple decades earlier to allow two-byte UTF-8 input by making all first-bytes of valid 2-byte UTF-8 sequences into control characters).
So, LaTeX being "unergonomic" is only relative — it's pretty ergonomic compared to things like HTML but especially DocBook or TEI SGML/XML schemas, but less ergonomic than Markdown or even Plain TeX. However, it inherits the most complex part where it is extremely ergonomic from Plain TeX (for the most part): editing math formulae.
But it's also much richer in expressing intent than any of those, and from what I can see, compared to Typst as well — LaTeX is basically semantic markup for excellent printed output (where Plain TeX is excellent printed output with no semantics, DocBook/TEI are pure semantic markup, and HTML/Markdown/Typst are somewhere in the middle too).
Could you give an example of how it could be more similar to Markdown? I recently used Typst for my bachelor's project and never really thought that it needed to be simpler
Typst is a lot of fun and lets you do some really cool stuff. However! In the process of doing that cool stuff, you may need to debug things and that’s when it’s no longer fun. There is no way to print anything out to console and debug anything about what is going on. People have asked for it for over a year now and the authors have refused/ignored their requests. I would be using it a lot more except for this. https://github.com/typst/typst/issues/1669
Hey, I'm one of the Typst devs and author of the issue.
The reason there is no logging yet is because we want to get it _right_ rather than landing a permanent temporary solution. And there were simply more urgent things to do so far.
Also note that if you use an LSP or the web app, you can inspect the live values in your code simply by hovering over them.
The author of this issue is the main developer so I guess they want it done, just had other priorities.
I agree typst needs better debugging tools, but you're a bit harsh. It has things like `repr` that can often be used to inspect objects, and `panic` can be used as a (admittedly crappy) substitute for printing a value to the console.
I like Typst, but I've had a couple issues so far:
1. The line spacing. It's not defined as baseline to baseline, but as the space inbetween two lines of text. Very difficult for an assignment with a prescribed line height since it usually refers to a baseline-baseline measure.
2. While having multiple columns is really easy, adding floating elements for the text to wrap around seems not possible. There's a reason all these CV templates have the info bar on the right instead of the left.
You can change how the bounding box Typst uses for layout is defined (i.e. set the top and bottom edges both to the baseline), then I would imagine the spacing would be baseline to baseline. Would need to adjust the space before a paragraph to compensate though.
This issue and others like it are dealbreakers for me. There are numerous related issues, but the developers are stubbornly sticking to their interpretation—using the older definition of leading from the days of metal type, rather than the more modern concept of line-spacing. No other software or modern typesetting system I know of uses this approach anymore. This is particularly frustrating since I work with a lot of multilingual text, including Arabic, and it's very difficult to align the baselines when setting text in more than one column.
Built my resume with typst and know of several other folks using it for serious document typesetting. It is a very nice and modern typesetting system and language that just feels easy to make it do what I want.
It incorporates elements like templates and it is very easy to create reusable content “functions”. It is everything I want out of LaTeX while being super fast and easy to use.
Edit: pandoc can generate typst output if you want to explore :)
First of all, I will commend the Typst community for attempting to rectify the trainwreck that is LaTeX typesetting. It appears that they have succeeded.
So Typst has its own styling system, and its own scripting system, and plugin system via WASM... isn't this just HTML with extra steps? Not to mention that Typst doesn't support HTML export https://github.com/typst/typst/issues/188#issuecomment-14933..., which is a major impediment to vision-impaired accessibility in the academic community.
I think this is all a bit of a shame that there's been no major efforts to reform HTML as the go-to file format for scientific publishing instead. All the elements are there - <cite>, citation.js, KaTex, Web Components, good plotting libraries (Observable Plot), WASM. Was all this extra engineering effort required to get us a Markdown style syntax? I know people hate XML-based markup... but it's not _that_ bad, right?
PDF was designed to look the same on any device/viewer and that's something that HTML/CSS/JS will likely never be able to do (every browser does things slightly different!). HTML also lacks good support for embedding resources in a single file and is much heavier to display (try coding a whole HTML + CSS + JS engine vs a basic PDF/A viewer!). Moreover HTML/CSS lacks all the typesetting features that Latex/Typst support out of the box.
But anyway here's a challenge for you: take some random small document in Latex/Typst and try converting it to HTML/CSS/JS while keeping the same layout and visual feelings. Make it a single file you can share with people and try seeing if all browsers display it the same way.
The key difference between print systems and web tech is responsiveness. Anything print related is primarily designed with dead tree format in mind, so the layout won't change, and you don't have to worry about text reflowing after editing.
It's also why LaTeX/PDF to HTML converters are so difficult to build, because the underlying engine has no semantic information about the structure (this may be changing with LLMs and multimodal setups).
Publishing is heavily dependent on the output media, and multi-format output is still hard for anyone desiring a high quality output.
HTML is specifically designed as a publishing system for our screens and has mostly evolved that way (media CSS tags excluded) and as a web application UI language, along with some push into semantic markup (but TEI or DocBook are much more comprehensive when it comes to semantic markup).
Some of the large problems of typesetting printed documents (page layout, with hyphenation, figure placement, orphans, justification...) are simply unsolved (or badly solved) with HTML+CSS, and they are hard problems even if you focus only on them (TeX systems will sometimes ask you to manually "pick" your poison — if you've ever seen those black bars in the margins).
Some of the beauty of TeX box model could have been transferred to screens though (like tunable and collapsible whitespace), and to an extent they have, but TeX's model remains incompatible with the HTML/CSS box model.
The fact that no language does all 3 (UI for apps, screen rendering of documents, paper rendering of documents) perfectly or even acceptably well — not to mention a fourth class that's a mix between screen and paper: ePub/eBooks — should tell anyone that this is a very hard problem to solve generically.
It's a somewhat difficult issue and I understand being hesitant because of this. Converting to SVG is one possible path around it which isn't too bad but having it natively is of course even better.
The thing is, inserting PDF for just the PDF export would be quite easy. The issue is the other export targets Typst supports (SVG and PNG) as that would require some form of rasterization / a full blown PDF engine written in Rust without C-bindings because of the web app and that simply does not exist yet.
And the developers are hesitant to just add features for one specific export target which I get.
While I appreciate these projects, I can't see any headway for something like this in our academic community. We have a very established ecosystem of LaTeX packages, styles and documents, some of which are more than 25 years old. Everyone knows it. Everyone collaborates with LaTeX. Knowledge is easy to pass on because it is well understood. Everyone knows (or are) the people who write the packages or maintain things behind the scenes. This is all quietly boiling away without a single thing on GitHub.
To move to Typst, we'd have to start again and build all that again, because I guarantee there's stuff you just can't do it in it. I mean I looked at the options for tikz. One publication we have has 520 tikz figures in it for example. And that's dead.
Sure but you have to take into account how easier it is to build these things in typst. It's like one year since the first public typst release and someone already built a very functional "TikZ" equivalent called CeTZ. Far from being as mature as TikZ but easier to extend yourself.
I was hoping that the syntax for equations would be borrowed from LaTeX but it is not the case unfortunately. I would like to switch away from LaTeX, but i think the syntax for equations in LaTeX is pretty sensible actually.
Have you tried with ConTeXt? As LaTeX, it's built atop TeX - though it's not as modular (and popular) it's more powerful.
I'd like to like Typst, but (as mentioned the other day) it follows the same model as LaTeX - great for some predefined styles, but the moment you want or need something different you'd need to get third party plugins, and with that all the perks and cons they may have.
Do give typst's syntax a try! I had the same worry as you but I now find typst's syntax more pleasant to write, and the resulting code is much more readable. Instead of
It took me a few hours to be able to do things I could never do in Latex, which I have had used for a number of documents like thesis, project reports, etc.
In Latex I always relied on googling random packages to fix weird stuff while in Typist I feel like I can do anything I want myself.
The scripting capabilities are powerful and compared to latex insanely easy to use.
This! My first actual project (besides some testing) has been my phd manuscript, and after ~2 days i actually had a tufte-style 1.5 column layout going, written from scratch. And its probably like ~250 lines.
There are some rough edges still, the dom model and advanced programming stuff is not quite there yet (user-defined elements, user-defined settables, advanced layout like chaining blocks for laying text flows). But like the quality of the user interface is several orders of magnitude better than (La)TeX.
The two baseline criteria I have for better-than-LaTeX options are:
1. Maths support equal to or better than amsmath
2. LaTeX-style macros
Both are needed to make writing large amounts of complex equations acceptable.
There should also be something similar to unicode-math, cleveref and biblatex, easy-to-use options to control layout/style/output (including metadata).
I wrote a recent paper in typst. We ended up converting it to latex at the last minute to work with the conference’s submission guidelines, and work around a small bug (now fixed) in typst. But I would 100% use typst again. I wish it output html so I could use it for blogs & documentation.
The maths support was more than good enough for what we needed, and I enjoyed writing it a lot more than latex maths. The macro-equivalent support in typst is fantastic. It’s a standout feature. It has a full, modern-feeling programming language built in, complete with modules, functions, variables, arrays, the whole works. And there’s a growing ecosystem of 3rd party packages you can use with typst. Our benchmark scripts output the results into json files. Then when the typst document compiled, our typst source pulled in the benchmarking data directly from those json files. Then it used that data to populate tables and render charts directly, straight into the pdf. It was a lovely way to work.
(Though that said, I ended up swapping to a more fully featured external charting library because the charts it created looked better).
For me, it's basically a non-starter for academic work because it doesn't support PDF and EPS images (there are currently issues with SVG too). They also have no plans to support PDF graphics (https://github.com/typst/typst/issues/145).
I really want to like this because it seems a lot more accessible to folks than latex but I'm getting that "uncanny valley" feeling like when I look at equations that have been typeset in MS Word. They look almost, but not quite, good.
Like if you look at the equation for Binet's closed form solution for Fibonacci numbers in the link below from their github, it looks to me like there is a bit too much space on either side of the plus sign in the equation for phi on the right hand side. And phi^n on the left-hand side looks too close to the 1/sqrt(5).
I think you're imagining things... This spacing stuff is mostly defined in the font files and typst uses the same math font (or a more recent version, depending on your LaTeX config). I made a small comparison:
https://imgur.com/a/0k6dsok
Note that by default, typst uses the book weight from New Computer Modern. This corresponds to the default settings in LaTeX with the "fontsetup" package.
The only difference I can see is the spacing after the comma. Not sure why typst does it differently. I think typst might be doing the right thing here actually, but it's easy to adjust if you want.
In the near future, I'll have to program the document generation part of an invoicing system.
In the past, I've done generated PDF documents through latex, and didn't really like the process (for one, escaping is just so weird in latex, \ to \textbackslash for example).
I've thought about generating HTML and using a headless browser that can produce PDFs for me, but I don't know how well you can e.g. control page breaks with CSS these days.
Maybe typst is actually a good alternative here? Does anybody have experience with typst and multi-page tables?
I think you're looking for Quarto. Quarto can also compile to Typst for typesetting, but you can get simultaneous HTML/PDF/Word outputs from a single markdown input.
I'm doing PDF document generation in typst, the format I'm generating is similar to invoices (specific to how the law in my country is, but that's a longer story).
Typst code generation was easy to automate with trivial python templates (jinja2). The core part of my document are multi-page tables, and typst splits them nicely.
I had to google around a bit, as there are multiple settings on how large tables are handled, I suggest that you give Typst a try, you can build a working prototype in no time
I have been building tools for document generation out of templates using Typst for a few months. It works great!
So far, I haven't found any bigger issues with multi-page tables in Typst. For example, it was no big deal, to get subtotals in an invoice for every page break.
Typst is a huge improvement over LaTeX, but makes the rather anachronistic decision to target paper-based media instead of screens. Unless you're planning to print out all your papers onto physical paper, and you have stacks of different sized paper lying around (A4, US Letter, US Legal, etc.), PDFs are kind of old-fashioned. Why constrain your document's width to eight and half twelfths of the length of some medieval king's foot, when we have cutting-edge 1980s technology like HTML which can adapt to your screen width?
Incidentally, there's an open issue with Typst for making HTML output, but I don't understand why that wasn't the project's first priority. Even if scientific journals require PDF uploads, you can still get those from printing HTML. The opposite isn't true at all.
I've tried typsit and Ive really been enjoying it. It's very easy to learn and easy to use. It's a new project so it can't as of yet replace the functionality of LaTeX's many packages. However it is good for quick and easy texts, it's replaced markdown and office for me for writing simple documents on a computer.
FWIW, as a long time user of tectonic I just started a project using typst yesterday,
I'm really curious if typst will be able to do parallel downloading of packages than tectonic.
This is something which I have found can affect initial first time document builds since it can cause sequential downloading of a lot of small files sequentially.
The reason why it is difficult to parallelize or fix in tectonic itself is the way latex itself is parsed in a turing complete fashion. Importing a package can affect subsequent parsing. This makes it basically impossible to build a map of package dependencies without interpreting the entire document.
Yup. I use both LaTeX and Typst (although I prefer Typst when possible) and I haven't used anything other than tectonic for the past few years. It simply has everything you need included, and is pretty darn fast too.
If I understand correctly the fees are only for an overleaf-type web collaborative editing experience. The typst program itself, the one you install on your computer, is free to use and open-source.
What is the story with the fonts Typst uses?
Does it come with a standard library of fonts?
I am not a fan of LaTex myself, but I admire it to some extent.
Other systems come along that are less verbose and easier to write,
and faster.
Yay.
And then people use it, and then someone thinks "oh we should have this
function", "We need to add a feature for it to work well" etc etc
and slowly the system either bloats, and at some point, a person will
look back at LaTeX and go
"Oh that is why this existed, and ah that
is why this is slow"
Or one can choose to keep the new system simple and simply use LateX
when something more is required.
Adding a font is just `#set text(font: "besley")` or you can use a list for fallback like `#set text(font: ("jost", "noto sans")`. Then you can select weight, italic/bold, opentype features, ligatures, etc. as options on `text` with the same syntax.
The command line comes with a few defaults such as the open source Libertinus for text or New CMM for math, but may fall back to your System fonts for characters like emoji (and there are flags to disable system fonts). You can also set a specific path to look up font files.
And then the web app has plenty of fonts in an extensive dropdown, and supports dropping in custom font files that will be automatically recognized.
I believe one current limitation is bitmap fonts not working properly, but that is being actively developed by a contributor.
I'm optimistic that Typst won't run into the issues you mention. I see it as doing well at incorporating the knowledge of the past into simpler, better interfaces.
First of all, today I almost exclusively write all my LateX in overleaf, so a lot of pain of LateX distros is taken away. But the main thing was always good templates, so I found a collection of ML conference templates [0], that shows also that typst still has some issues with acutely reproducing existing styles. Also when having to submit sources, I guess cross compile to latex would be the only possibility (typically they accept Latex or sometimes MS Word)
I'm using Markdown/LaTex to PDF/HTML converter for preparing various legal/rules documents. While this approach works for very simple documents, whenever I needed simple change (i.e. specific list numbering or break the page for chapters) the path to find the solution was long and painful.
Typst was a breath of fresh air, and I'm moving all my document generators to it and don't look back.
The only thing I miss at the moment is generation of HTML (in addition to PDF). It's possible to achieve via Typst+Pandoc I guess, but would be great to have it as an output target natively.
I have a love-hate relationship with LaTeX... in 2016, I wrote my PhD with it, for wich I defined lots of helpers and commands.I used xetex for some obscure reasons I don't remember.The final result was beautiful but I dread opening any of those files. And it doesnt compile anymore.
Among all the systems (tools, languages, devices...) I exploited professinaly, LaTeX is the one that remains the most obscure and frustrating to me. I'm not sure why.
Latex already has massive amounts of libraries. Simple things like chemistry or physics typesetting for example. That's hard to just switch away from.
can it do freetype fonts? I use XeLatex to change the fonts since the default gets boring. I've been doing all my math in latex for so long I feel like I can't just switch to something else.
There is overlap, with creating whole documents, but I can imagine at some point one could use Typst inside Quatro. (Like using Typst inside Obsidian.)
I'd rather see effort go into improving LaTeX performance instead of creating some new incompatible thing in a trendy language. One could also imagine an Elixer-style "resyntaxing" of LaTeX that would preserve compatibility with decades of packages. I don't think a long-developed ecosystem should be given up lightly.
Speed and nice error messages in (La)TeX, and to some extent ease of programming, are entirely doomed because of fundamental design choices. Being based on unhygienic macro expansion means that there is only one way to evaluate (the slow way), there will never be incremental compilation (everything can possibly be stateful in horrible ways), there will never be good error messages because there's basically no AST information anywhere (begin/end is a joke).
Regarding ecosystem: tons of undecipherable LaTeX packages are basically one-liners (ok, 10 liners) in typst. I know it from experience: I've written my PhD manuscript in typst. So perhaps one reason why there are so many (basically frozen) packages in LaTeX is because they are so hard to write and maintain.
edit: of course, being only a few years old, typst is nowhere near as solid as TeX, but you can already use it for a lot of things and its a breeze to use.
TeX has three actively-maintained engines, and there are a lot of folk putting work into improving LaTeX and its ecosystem. So effort is going into LaTeX, including performance, right now. Probably someone committed a perf improvement today, or in the last week.
There are problems with TeX which can't be fixed, problems which Typst is directly addressing. I wish them all success. I will never understand the attitude which holds that because some established system exists, nothing in the same category of program should ever be written. Let people cook.
I do understand Rust fatigue but the swipe here is uncalled for. This isn't a "rewrite it in Rust", it's a new language which happens to be implemented in Rust, and y'know what? Good choice frankly. There are tasks where "fast enough" isn't a meaningful concept, and compiling raw documents into a finished form is one of those tasks.
TeX and LaTeX aren't going anywhere, and Typst has years of work ahead of it to ever offer a comparable richness of capability. If it incrementally replaces the use of LaTeX over time, that will be because it earned it.
Have you used troff lately? Probably not. Things change. And yet man pages are written in nroff to this day. Dr. Knuth wrote TeX because what existed at the time wasn't working for him. Typst likewise.
I use typst to generate PDFs on the fly in my sass-platform. The only other reliable ways I could find to do that was by using LaTeX (slow) or various WebKit-based tools (also slow, and in carious states of unmaintained/deprecated). It works like a charm.
If the author is reading, there’s a bug with dark mode, the `aside` (for the TOC) gets a background color of #d3d3d3 which results in very bad contrast as the font and heading are adjusted for dark mode.
I tried typst several months (or was it already a year?) ago, and I found it really great. I was even able to easily modify a simple plugin after barely playing 1 hr with it, where in latex that I used for years, I never even tried (to be fair the amount of plugins meant I didn't need to).
I just wish I had a good reason to use it... maybe when the implement the html output ?
I'd like to throw my two cents into the "my experience is limited but I like it better than LaTeX" ring. Because, in my limited experience, Typst is easier and faster than LaTeX by a lot.
I'd like to emphasize how important it is that Typst is a collaborative web-app like Overleaf-- 100% of the LaTeX use I saw in academia was on Overleaf.
The central issue for new typesetting methods, unlike most software projects, is that to represent a solution, not a new problem, they must seamlessly communicate with other similar environments. So I have to ask:
* Can Typist seamlessly export Latex?
* Can Typist seamlessly import Latex?
And I must link to the definitive XKCD cartoon on this topic: "Standards" https://xkcd.com/927/ .
__mharrison__|1 year ago
It's:
- Fast—Compiling my books would take around 1 minute (I often had to compile twice due to indexing). With Typst, it takes less than 5 seconds.
- Easy to write—I actually don't write it, I wrote a bunch of Pandoc plugins to tweak the output from Pandoc (I write all my books in Jupyter these days, so lots of markdown).
- Easy to read—I've used LaTeX for years (and wrote a bunch of tooling around it) and still couldn't tell you when to use a { or a [. Typst is very readable.
- Easy to script—Okay, I did write some Typst the other day. I migrated my LaTeX-based invoicing system to Typst. I created a list of objects with pricing and count and was able to throw it into a table easily. It has less code than my LaTeX version, which was using a library, and is easier to read. (I did need to write a function to properly format $ because that doesn't exist. A few rounds with AI made that easy.)
- Has great error messages—If you've used LaTeX, you know what I mean.
My needs are different from others, but I'm writing PDFs that need to be printed into a real book that looks professional. This includes front matter, footnotes, callouts, page numbers, page headers and footers, and indexes. I don't do a lot of math-heavy stuff, so I can't comment on that. And the widow/orphan support is a little weak.
Otherwise, I'm happy to never use LaTeX again!
Jach|1 year ago
This trips people up a lot once they do anything involving cross-referencing or bibliographies. But for some reason some people use latex for a long time and never hear about latexmk, which automates all that, and can even "watch" your files so you can edit and save and see your PDF refresh all in real time. (I've only used latex for papers or blog math, not big books; I can't imagine waiting a minute per change back in college, let alone on modern hardware...)
akoboldfrying|1 year ago
Because that's where I lose the most time with LaTeX: packages often mess with the (piles of) global state in ways that sometimes conflict, and the only "solution" seems to be that, if you're very lucky, sometimes conscientious package authors will try to "detect" (through various hacks) whether some other known-conflicting package has already been loaded and adjust accordingly. I didn't see any mention in TFA of any module system or even local variables in Typst to contain this explosion of complexity, so I suspect it will be just as bad in this respect as LaTeX is once there are as many plugins available.
humanfromearth9|1 year ago
What I enjoy about Typst is the fact that the code is easy to write and read. Even code from some third-party library or template is easy to understand. There is a world of difference between this and LaTeX, which abstracts over TeX, and whose inner workings remain obscure even to experienced developers having used LaTeX over decades for tens of documents.
The compilation of Typst documents is indeed also extremely fast compared to LaTeX.
The runtime and libraries are lightweight and easy to install, compared to LaTeX distributions.
Writing custom logic or even a fully-fledged template with Typst is easy to do from day one.
The only reason I still see to use LaTeX nowadays is writing books and papers whose editor only accepts LaTeX.
I've switched to Typst some months ago and not once have I thought it might have been a mistake. The only thing I regret is that there is no automatic migration of older LaTeX documents to Typst.
Editors still have to be improved, though the Vscode plugin is absolutely usable.
laurmaedje|1 year ago
flakiness|1 year ago
Jupyter-to-PDF sounds like a perfect match here!
vestingz|1 year ago
Interesting! Would you share your solution and/or tell us a little more about it? Thanks!
heisenzombie|1 year ago
I find the whole system to be a bit house-of-cards and I’d love to try alternatives. What’s your workflow for using Typst with Jupyter?
amelius|1 year ago
I hope that Typst at least allows you to nest elements without any issues.
andrepd|1 year ago
necovek|1 year ago
Eg. both the article and docs at https://typst.app/docs/reference/model/ref/ use an inline reference that wouldn't work in Serbian.
Serbian (and many other languages) have suffix declensions, so while "Figure 4" is "Slika 4", when used like "in Figure 4", you really need "u Slici 4" (and lowercase, really) instead of "u Slika 4" as produced by Typst.
On the plus side, it seems to use OTF locl tables for substitution glyphs for language, though it only partially works for Serbian (might be due to bad locl tables for LinLibertine which seems to be the default font).
I am sure it's not too hard to only get the reference number (eg. @foo.context.something?), but defaults should be good or maybe per-language?
I can see how they wanted to avoid authors having to hard-code the reference type if they change eg. something from an image to a table, but it's hard to make it smart enough for any language.
cbolton|1 year ago
Also typst knows the type of the referenced element. It's easy to write more elaborate rules that behave differently depending on the type. And the rules can also check the current language to generate localized references.
teo_zero|1 year ago
darrensharm|1 year ago
devit|1 year ago
bboygravity|1 year ago
YmiYugy|1 year ago
On a different note, we got to find a better way to exchange data than pdf reports. In my totally made up estimation about 10% of development time for enterprise software is spend on variations of these pdf templating tools and another 20% on extracting data from such generated pdfs.
justinpombrio|1 year ago
1. In the content passed that the user passes to the template
2. In the template itself
3. By the user, outside the template
They take priority in that order.
OTOH, if the template really wants control, it can take optional styling arguments with defaults, and do as it likes with them. And if it wants content from the user that the user doesn't get to style, it can take that content as a string.
It's a fantastic system, so far as I've seen.
perlgeek|1 year ago
We have that, it's called HTML. The use case is quite different from PDF though.
mixmastamyk|1 year ago
BoingBoomTschak|1 year ago
Klasiaster|1 year ago
kaba0|1 year ago
vslavkin|1 year ago
The main problem is the popularity. It just does not have enough packages, at least for my use case.
I mainly do a lot of equations (simple math), and a loooot of tikz (forest, circuitikz, pgfplots, etc.) [https://gitlab.com/vslavkin/escuela/-/tree/main/5to?ref_type...] I'm not a fan of tikz, but it's the only way to mantain the graphics homogeneous, clean, easily editable, compiled with the document and with links/references. Cetz (the typst alternative) is years behind. I've been thinking of contributing, but tikz is really complex, and I don't have enough time ATM.
Besides the typst packages, it also lacks the editor packages. I am an emacs user insert joke here, and I use AucTeX, which is a really great, and gigant package to edit latex (+cdlatex). AFAIK there's nothing like it for typst, which makes me way slower.
Another thing is that they changed the math syntax. While the latex one wasn't perfect it was insanely popular, because of its use on markdown and a lot of pages (and this was thanks to mathjax iirc).
The good thing is that something like latex or typst will always be needed, so there'll always people that want to have something like it; latex/tex isn't really great, and it has a really low entry bar.
Maybe I'll switch when I have more time to study it and make packages. (It could be as soon as next year or a late as... never)
josephg|1 year ago
The typst editor plugin for vscode is pretty great. It gives you a split view of source & pdf, and you can cmd+click on either side to scroll to the corresponding source / rendered output. It also does things like give you autocomplete on fields from externally referenced json data.
Obviously, that might be no help if you’re married to eMacs. But if you’re a little promiscuous with editors like I am, give it a try.
cbolton|1 year ago
Can't comment on the AucTeX part, I'm using helix and typst support is not great but good enough.
tolerance|1 year ago
https://codeberg.org/meow_king/typst-ts-mode/wiki/
https://github.com/Myriad-Dreamin/tinymist/tree/main/editors...
sourcepluck|1 year ago
This is tangential, but have you any quick tips for someone looking to get started with AucTeX? I'm a comfortable Emacser who has started to occasionally think of some document I'd like to do in LaTeX (some maths questions for a student, or an overview of some topic). I've looked at AucTeX once or twice, and ran away thinking, oh, I'll do that some other time.
What is the order of events? Should I make a few really basic LaTeX documents first with a terminal, and then try AucTeX?
aulin|1 year ago
In my totally anecdotal experience the intersection between proficient LaTeX users and emacs users is pretty large.
So having good emacs support would be a big selling point.
My experience on the other hand is also those people never complain about LaTeX, so they're probably not the target for a new typesetting system.
andrepd|1 year ago
larsrc|1 year ago
Vt71fcAqt7|1 year ago
elashri|1 year ago
https://news.ycombinator.com/item?id=41014941
https://news.ycombinator.com/item?id=38354422
https://news.ycombinator.com/item?id=38047224
https://news.ycombinator.com/item?id=35250210
https://news.ycombinator.com/item?id=34423590
dang|1 year ago
Typst: An easy to learn alternative for LaTex - https://news.ycombinator.com/item?id=41014941 - July 2024 (187 comments)
Building the New Hypermedia Systems using Typst - https://news.ycombinator.com/item?id=40986352 - July 2024 (1 comment)
No-Signup Typst Tools - https://news.ycombinator.com/item?id=40905678 - July 2024 (1 comment)
Typst Symbol Classifier - https://news.ycombinator.com/item?id=39878069 - March 2024 (1 comment)
Show HN: A no-frills CV template using Typst and YAML to version control CV data - https://news.ycombinator.com/item?id=38990197 - Jan 2024 (8 comments)
TexText: Re-editable LaTeX/ typst graphics for Inkscape - https://news.ycombinator.com/item?id=38804431 - Dec 2023 (2 comments)
Typst – Compose Papers Faster - https://news.ycombinator.com/item?id=38354422 - Nov 2023 (134 comments)
I rewrote my CV in Typst and I'll never look back - https://news.ycombinator.com/item?id=38047224 - Oct 2023 (25 comments)
typst-conceal.vim: cute UTF-8 conceal for typst - https://news.ycombinator.com/item?id=37862666 - Oct 2023 (1 comment)
Typst 0.7: floating content, improved SVG support and better math layout - https://news.ycombinator.com/item?id=37038708 - Aug 2023 (1 comment)
Typst: Finally a Solid LaTeX Alternative - https://news.ycombinator.com/item?id=35835703 - May 2023 (3 comments)
Typst starts its public beta test and goes open source - https://news.ycombinator.com/item?id=35364822 - March 2023 (1 comment)
Typst, a new markup-based typesetting system, is now open source - https://news.ycombinator.com/item?id=35250210 - March 2023 (146 comments)
Typst: A Programmable Markup Language for Typesetting [pdf] - https://news.ycombinator.com/item?id=34423590 - Jan 2023 (53 comments)
What If LaTeX Had Instant Preview? - https://news.ycombinator.com/item?id=33222356 - Oct 2022 (23 comments)
Typst: Compose Papers Faster - https://news.ycombinator.com/item?id=32209794 - July 2022 (30 comments)
Typst: Compose Papers Faster - https://news.ycombinator.com/item?id=32205005 - July 2022 (1 comment)
alphazard|1 year ago
The selling point seems to be that this is more similar to Markdown. That makes sense, Markdown is objectively more common and has more users than Latex. I've used both, but Markdown way more often.
Here's something I don't understand: it would be trivial to make Typst even more similar to Markdown, and yet it exists at some strange middle point in the language design space, arbitrarily far from Markdown.
huijzer|1 year ago
More generally, I am really impressed by Typst’s abstractions. I have typset my whole PhD thesis in it without needing any external packages. It was so easy to use the basic building blocks and write a few extra functions for the rest.
sshine|1 year ago
Places I’ve switched from Markdown to Typst: Slides. There are some okay Markdown-to-HTML solutions, but they have this unfortunate side-effect that you move the slides to some other computer, and something breaks in your rendering. PDFs ftw.
mbivert|1 year ago
I remember reading — but can't find a source at the moment — that TeX originally didn't had counters; people came to rely on Church numerals[1] instead, before Knuth finally implemented them.
EDIT: found out where I've read about it: [2]
[0]: https://www.overleaf.com/learn/latex/A_six-part_series%3A_Ho...
[1]: https://en.wikipedia.org/wiki/Church_encoding
[2]: https://news.ycombinator.com/item?id=29713270
Animats|1 year ago
The problem is that extending Markdown syntax gets messy.
This is kind of a strange blend of Markdown, CSS, JSON, and HTML. TeX at least has a consistent syntax.SkiFire13|1 year ago
llm_trw|1 year ago
As evidenced by the fact that every project which uses it for more than that adds arbitrary extensions.
The minimum viable language for non-mathematical technical documentation is reStructuredText.
necovek|1 year ago
So, LaTeX being "unergonomic" is only relative — it's pretty ergonomic compared to things like HTML but especially DocBook or TEI SGML/XML schemas, but less ergonomic than Markdown or even Plain TeX. However, it inherits the most complex part where it is extremely ergonomic from Plain TeX (for the most part): editing math formulae.
But it's also much richer in expressing intent than any of those, and from what I can see, compared to Typst as well — LaTeX is basically semantic markup for excellent printed output (where Plain TeX is excellent printed output with no semantics, DocBook/TEI are pure semantic markup, and HTML/Markdown/Typst are somewhere in the middle too).
__mharrison__|1 year ago
prettymuchnoone|1 year ago
knuckleheads|1 year ago
laurmaedje|1 year ago
The reason there is no logging yet is because we want to get it _right_ rather than landing a permanent temporary solution. And there were simply more urgent things to do so far.
Also note that if you use an LSP or the web app, you can inspect the live values in your code simply by hovering over them.
cbolton|1 year ago
I agree typst needs better debugging tools, but you're a bit harsh. It has things like `repr` that can often be used to inspect objects, and `panic` can be used as a (admittedly crappy) substitute for printing a value to the console.
viralsink|1 year ago
1. The line spacing. It's not defined as baseline to baseline, but as the space inbetween two lines of text. Very difficult for an assignment with a prescribed line height since it usually refers to a baseline-baseline measure. 2. While having multiple columns is really easy, adding floating elements for the text to wrap around seems not possible. There's a reason all these CV templates have the info bar on the right instead of the left.
Aaron2222|1 year ago
suvadivian|1 year ago
This issue and others like it are dealbreakers for me. There are numerous related issues, but the developers are stubbornly sticking to their interpretation—using the older definition of leading from the days of metal type, rather than the more modern concept of line-spacing. No other software or modern typesetting system I know of uses this approach anymore. This is particularly frustrating since I work with a lot of multilingual text, including Arabic, and it's very difficult to align the baselines when setting text in more than one column.
bitexploder|1 year ago
It incorporates elements like templates and it is very easy to create reusable content “functions”. It is everything I want out of LaTeX while being super fast and easy to use.
Edit: pandoc can generate typst output if you want to explore :)
mbo|1 year ago
So Typst has its own styling system, and its own scripting system, and plugin system via WASM... isn't this just HTML with extra steps? Not to mention that Typst doesn't support HTML export https://github.com/typst/typst/issues/188#issuecomment-14933..., which is a major impediment to vision-impaired accessibility in the academic community.
I think this is all a bit of a shame that there's been no major efforts to reform HTML as the go-to file format for scientific publishing instead. All the elements are there - <cite>, citation.js, KaTex, Web Components, good plotting libraries (Observable Plot), WASM. Was all this extra engineering effort required to get us a Markdown style syntax? I know people hate XML-based markup... but it's not _that_ bad, right?
SkiFire13|1 year ago
But anyway here's a challenge for you: take some random small document in Latex/Typst and try converting it to HTML/CSS/JS while keeping the same layout and visual feelings. Make it a single file you can share with people and try seeing if all browsers display it the same way.
Onavo|1 year ago
It's also why LaTeX/PDF to HTML converters are so difficult to build, because the underlying engine has no semantic information about the structure (this may be changing with LLMs and multimodal setups).
necovek|1 year ago
HTML is specifically designed as a publishing system for our screens and has mostly evolved that way (media CSS tags excluded) and as a web application UI language, along with some push into semantic markup (but TEI or DocBook are much more comprehensive when it comes to semantic markup).
Some of the large problems of typesetting printed documents (page layout, with hyphenation, figure placement, orphans, justification...) are simply unsolved (or badly solved) with HTML+CSS, and they are hard problems even if you focus only on them (TeX systems will sometimes ask you to manually "pick" your poison — if you've ever seen those black bars in the margins).
Some of the beauty of TeX box model could have been transferred to screens though (like tunable and collapsible whitespace), and to an extent they have, but TeX's model remains incompatible with the HTML/CSS box model.
The fact that no language does all 3 (UI for apps, screen rendering of documents, paper rendering of documents) perfectly or even acceptably well — not to mention a fourth class that's a mix between screen and paper: ePub/eBooks — should tell anyone that this is a very hard problem to solve generically.
moelf|1 year ago
[1]: https://github.com/typst/typst/issues/145
xkevio|1 year ago
The thing is, inserting PDF for just the PDF export would be quite easy. The issue is the other export targets Typst supports (SVG and PNG) as that would require some form of rasterization / a full blown PDF engine written in Rust without C-bindings because of the web app and that simply does not exist yet.
And the developers are hesitant to just add features for one specific export target which I get.
me_jumper|1 year ago
hggigg|1 year ago
To move to Typst, we'd have to start again and build all that again, because I guarantee there's stuff you just can't do it in it. I mean I looked at the options for tikz. One publication we have has 520 tikz figures in it for example. And that's dead.
cbolton|1 year ago
sega_sai|1 year ago
Gualdrapo|1 year ago
I'd like to like Typst, but (as mentioned the other day) it follows the same model as LaTeX - great for some predefined styles, but the moment you want or need something different you'd need to get third party plugins, and with that all the perks and cons they may have.
cbolton|1 year ago
tcfhgj|1 year ago
In Latex I always relied on googling random packages to fix weird stuff while in Typist I feel like I can do anything I want myself. The scripting capabilities are powerful and compared to latex insanely easy to use.
lapinot|1 year ago
There are some rough edges still, the dom model and advanced programming stuff is not quite there yet (user-defined elements, user-defined settables, advanced layout like chaining blocks for laying text flows). But like the quality of the user interface is several orders of magnitude better than (La)TeX.
aragilar|1 year ago
1. Maths support equal to or better than amsmath 2. LaTeX-style macros
Both are needed to make writing large amounts of complex equations acceptable.
There should also be something similar to unicode-math, cleveref and biblatex, easy-to-use options to control layout/style/output (including metadata).
josephg|1 year ago
The maths support was more than good enough for what we needed, and I enjoyed writing it a lot more than latex maths. The macro-equivalent support in typst is fantastic. It’s a standout feature. It has a full, modern-feeling programming language built in, complete with modules, functions, variables, arrays, the whole works. And there’s a growing ecosystem of 3rd party packages you can use with typst. Our benchmark scripts output the results into json files. Then when the typst document compiled, our typst source pulled in the benchmarking data directly from those json files. Then it used that data to populate tables and render charts directly, straight into the pdf. It was a lovely way to work.
(Though that said, I ended up swapping to a more fully featured external charting library because the charts it created looked better).
daedac|1 year ago
For me, it's basically a non-starter for academic work because it doesn't support PDF and EPS images (there are currently issues with SVG too). They also have no plans to support PDF graphics (https://github.com/typst/typst/issues/145).
thoroughburro|1 year ago
https://www.reddit.com/r/typst/comments/1ej07al/comment/lq9u...
seanhunter|1 year ago
Like if you look at the equation for Binet's closed form solution for Fibonacci numbers in the link below from their github, it looks to me like there is a bit too much space on either side of the plus sign in the equation for phi on the right hand side. And phi^n on the left-hand side looks too close to the 1/sqrt(5).
https://user-images.githubusercontent.com/17899797/228031796...
cbolton|1 year ago
Note that by default, typst uses the book weight from New Computer Modern. This corresponds to the default settings in LaTeX with the "fontsetup" package.
The only difference I can see is the spacing after the comma. Not sure why typst does it differently. I think typst might be doing the right thing here actually, but it's easy to adjust if you want.
My typst code:
My LaTeX code:perlgeek|1 year ago
In the past, I've done generated PDF documents through latex, and didn't really like the process (for one, escaping is just so weird in latex, \ to \textbackslash for example).
I've thought about generating HTML and using a headless browser that can produce PDFs for me, but I don't know how well you can e.g. control page breaks with CSS these days.
Maybe typst is actually a good alternative here? Does anybody have experience with typst and multi-page tables?
Onawa|1 year ago
wint3rmute|1 year ago
Typst code generation was easy to automate with trivial python templates (jinja2). The core part of my document are multi-page tables, and typst splits them nicely.
I had to google around a bit, as there are multiple settings on how large tables are handled, I suggest that you give Typst a try, you can build a working prototype in no time
bobbylarrybobby|1 year ago
niklasei|1 year ago
So far, I haven't found any bigger issues with multi-page tables in Typst. For example, it was no big deal, to get subtotals in an invoice for every page break.
gxonatano|1 year ago
Incidentally, there's an open issue with Typst for making HTML output, but I don't understand why that wasn't the project's first priority. Even if scientific journals require PDF uploads, you can still get those from printing HTML. The opposite isn't true at all.
vivekd|1 year ago
vzaliva|1 year ago
ratmice|1 year ago
This is something which I have found can affect initial first time document builds since it can cause sequential downloading of a lot of small files sequentially.
The reason why it is difficult to parallelize or fix in tectonic itself is the way latex itself is parsed in a turing complete fashion. Importing a package can affect subsequent parsing. This makes it basically impossible to build a map of package dependencies without interpreting the entire document.
I'm curious to see how typst handles such things.
pcranaway|1 year ago
tiffanyh|1 year ago
Last thing you want to do is use a platform that goes defunct.
https://typst.app/pricing/
nihzm|1 year ago
cozzyd|1 year ago
ThinkBeat|1 year ago
I am not a fan of LaTex myself, but I admire it to some extent.
Other systems come along that are less verbose and easier to write, and faster. Yay.
And then people use it, and then someone thinks "oh we should have this function", "We need to add a feature for it to work well" etc etc and slowly the system either bloats, and at some point, a person will look back at LaTeX and go
"Oh that is why this existed, and ah that is why this is slow"
Or one can choose to keep the new system simple and simply use LateX when something more is required.
LectronPusher|1 year ago
You can see all the options for `text` here: https://typst.app/docs/reference/text/text It will likely need some reorganization in time, but is quite functional.
The command line comes with a few defaults such as the open source Libertinus for text or New CMM for math, but may fall back to your System fonts for characters like emoji (and there are flags to disable system fonts). You can also set a specific path to look up font files.
And then the web app has plenty of fonts in an extensive dropdown, and supports dropping in custom font files that will be automatically recognized.
I believe one current limitation is bitmap fonts not working properly, but that is being actively developed by a contributor.
I'm optimistic that Typst won't run into the issues you mention. I see it as doing well at incorporating the knowledge of the past into simpler, better interfaces.
enriquto|1 year ago
cbolton|1 year ago
What trouble did you have installing it? (It's literally a single binary with zero dependencies)
riedel|1 year ago
[0] https://github.com/daskol/typst-templates
divan|1 year ago
Typst was a breath of fresh air, and I'm moving all my document generators to it and don't look back.
The only thing I miss at the moment is generation of HTML (in addition to PDF). It's possible to achieve via Typst+Pandoc I guess, but would be great to have it as an output target natively.
HerrmannM|1 year ago
Among all the systems (tools, languages, devices...) I exploited professinaly, LaTeX is the one that remains the most obscure and frustrating to me. I'm not sure why.
puffybuf|1 year ago
darkteflon|1 year ago
ternaryoperator|1 year ago
timeon|1 year ago
quotemstr|1 year ago
But of course.
I'd rather see effort go into improving LaTeX performance instead of creating some new incompatible thing in a trendy language. One could also imagine an Elixer-style "resyntaxing" of LaTeX that would preserve compatibility with decades of packages. I don't think a long-developed ecosystem should be given up lightly.
lapinot|1 year ago
Regarding ecosystem: tons of undecipherable LaTeX packages are basically one-liners (ok, 10 liners) in typst. I know it from experience: I've written my PhD manuscript in typst. So perhaps one reason why there are so many (basically frozen) packages in LaTeX is because they are so hard to write and maintain.
edit: of course, being only a few years old, typst is nowhere near as solid as TeX, but you can already use it for a lot of things and its a breeze to use.
samatman|1 year ago
There are problems with TeX which can't be fixed, problems which Typst is directly addressing. I wish them all success. I will never understand the attitude which holds that because some established system exists, nothing in the same category of program should ever be written. Let people cook.
I do understand Rust fatigue but the swipe here is uncalled for. This isn't a "rewrite it in Rust", it's a new language which happens to be implemented in Rust, and y'know what? Good choice frankly. There are tasks where "fast enough" isn't a meaningful concept, and compiling raw documents into a finished form is one of those tasks.
TeX and LaTeX aren't going anywhere, and Typst has years of work ahead of it to ever offer a comparable richness of capability. If it incrementally replaces the use of LaTeX over time, that will be because it earned it.
Have you used troff lately? Probably not. Things change. And yet man pages are written in nroff to this day. Dr. Knuth wrote TeX because what existed at the time wasn't working for him. Typst likewise.
Munksgaard|1 year ago
mixmastamyk|1 year ago
Semaphor|1 year ago
beezle|1 year ago
volemo|1 year ago
poulpy123|1 year ago
I tried typst several months (or was it already a year?) ago, and I found it really great. I was even able to easily modify a simple plugin after barely playing 1 hr with it, where in latex that I used for years, I never even tried (to be fair the amount of plugins meant I didn't need to).
I just wish I had a good reason to use it... maybe when the implement the html output ?
unknown|1 year ago
[deleted]
rsrsrs86|1 year ago
lynndotpy|1 year ago
I'd like to emphasize how important it is that Typst is a collaborative web-app like Overleaf-- 100% of the LaTeX use I saw in academia was on Overleaf.
pseingatl|1 year ago
njkleiner|1 year ago
https://github.com/typst/typst/issues/188#issuecomment-14933...
iamgopal|1 year ago
lutusp|1 year ago
unknown|1 year ago
[deleted]
dsrtslnd23|1 year ago
zamazan4ik|1 year ago
TL;DR - Profile-Guided Optimization (PGO) can improve Typst's performance for 10%+
bitwize|1 year ago
hyperbrainer|1 year ago