this post was submitted on 05 Jun 2025
86 points (97.8% liked)
Open Source
37597 readers
66 users here now
All about open source! Feel free to ask questions, and share news, and interesting stuff!
Useful Links
- Open Source Initiative
- Free Software Foundation
- Electronic Frontier Foundation
- Software Freedom Conservancy
- It's FOSS
- Android FOSS Apps Megathread
Rules
- Posts must be relevant to the open source ideology
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
- !libre_culture@lemmy.ml
- !libre_software@lemmy.ml
- !libre_hardware@lemmy.ml
- !linux@lemmy.ml
- !technology@lemmy.ml
Community icon from opensource.org, but we are not affiliated with them.
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
As a Typst enjoyer I have to say this isn’t it imo from a quick look at the readme. Typst’s mix of markup and code modes is excellently designed and a high bar for anything to beat, and this looks like it doesn’t come remotely close. (I do have to say, I also heavily dislike Markdown in general)
Well, Typst is explicitly a no-go for anyone who has to submit a manuscript, until it they get a damn HTML representation, so Pandoc can get it to LaTeX. There's practically nowhere I could use Typst except my own notes, and I've tried!
There’s experimental HTML support. I’m using Typst as a static site builder for my website.
Sure, but they can't build Pandoc translation against an experimental format, so no LaTeX anytime soon.
The experimental status is more about that not everything is implemented yet (not that everything can be implemented, for example due to HTML not being oriented around having multiple pages in a document), so you have to write a bit of raw HTML sometimes. This is an example of how raw HTML looks, it's the shell for my webpage.
Looking through some of the docs I'm afraid I won't be able to move off of Typst to this either. Typst has a long standing bug that I would have liked to avoid (lists that are too long will overflow memory and the maintainers seem to not want to temporarily dump to disk) but if even rust has an issue with those 100k+ row lists, I'm not sure kotlin will handle it better.
Lists with 100k items? Impressive. I can see how with a document like that it will run out of memory. Is it a stack overflow? You could try increasing the stack size in that case.