Typst: A Programmable Markup Language for Typesetting [pdf]
user.tu-berlin.de
Typst: A Programmable Markup Language for Typesetting [pdf]
1–10 of 55 posts
Re: Typst: A Programmable Markup Language for Typesetting [pdf]
#2Re: Typst: A Programmable Markup Language for Typesetting [pdf]
#3Re: Typst: A Programmable Markup Language for Typesetting [pdf]
#4The program for it seems to be the one here https://typst.app/
Re: Typst: A Programmable Markup Language for Typesetting [pdf]
#5This would need various compiler backends (perhaps via pandoc) to be that useful. Certainly it would help adoption if you could emit, eg., markdown/latex/etc. and others you're working with wouldn't need to adopt your tooling.
Re: Typst: A Programmable Markup Language for Typesetting [pdf]
#6I've been recently working on a book project, and I've reviewed all the tools available. My current conclusion is that I found nothing that would combine the simplicity of Markdown or Asciidoc with the typographical control of LaTeX.
This project seems to hit the sweet spot.
Is the source code of the thesis available somewhere? Of other works created with Typst? That would help making a more educated bet.
Edit: this doesn't seem to be an open source project. So not what I'm looking for.
Re: Typst: A Programmable Markup Language for Typesetting [pdf]
#7Impressive, as a Master's thesis, but also as a long-term project. I've been recently working on a book project, and I've reviewed all the tools available. My current conclusion is that I found nothing that would combine the simplicity of Markdown or Asciidoc with the typographical control of LaTeX. This project seems to hit the sweet spot. Is the source code of the thesis available somewhere? Of other works created…
Re: Typst: A Programmable Markup Language for Typesetting [pdf]
#8Impressive, as a Master's thesis, but also as a long-term project. I've been recently working on a book project, and I've reviewed all the tools available. My current conclusion is that I found nothing that would combine the simplicity of Markdown or Asciidoc with the typographical control of LaTeX. This project seems to hit the sweet spot. Is the source code of the thesis available somewhere? Of other works created…
There isn't much Typst source code out there yet, but you can find some examples and discussion on our Discord server [1] and in our documentation [2].
Re: Typst: A Programmable Markup Language for Typesetting [pdf]
#9Impressive, as a Master's thesis, but also as a long-term project. I've been recently working on a book project, and I've reviewed all the tools available. My current conclusion is that I found nothing that would combine the simplicity of Markdown or Asciidoc with the typographical control of LaTeX. This project seems to hit the sweet spot. Is the source code of the thesis available somewhere? Of other works created…
Re: Typst: A Programmable Markup Language for Typesetting [pdf]
#10As SGML pedant however, I can't resist commenting on the following:
> The second offspring of SGML is XML, specified by the World Wide Web Consortium (W3C) in 1998. It has a reduced feature set compared to SGML (for example, it forbids unclosed tags and concurrent markup). But it retains the most important aspect of SGML, one that HTML is lacking: The ability to define custom structural elements. This lets XML represent documents with much more semantic detail than HTML.
As the SGML vocabulary HTML was once envisioned, HTML itself doesn't need extensibility. When used as an SGML application, defining your own elements in HTML is as easy as declaring those in the "internal subset" or in a custom DTD right away. Assuming any wellformed element is accepted as of ISO 8879 Annex K's FEATURES IMPLYDEF ELEMENT rather than rejecting undeclared elements, that's actually only necessary if you want to validate/infer custom content models, or use any of the other things markup declarations provide, such as custom SHORTREF syntax a la markdown.
Arguably, HTML5's "custom elements" do provide a facility to define new elements, if incredibly lousy; ie. custom elements can't have content model restrictions (see above) and can't be used with tag omission/inference (important for customized elements), aren't integrated with DOM parsing, and need JavaScript for declaration - the latter point making them completely pointless as a markup feature.