- Collect design decisions and criteria for a next-gen typesetting languaeg
- Learn from past mistakes of (La)TeX, Markdown, and other products
Everyone who is interested in good design of a TeX-successor. With some points, it might be required to have a bit of background in type theories.
- Navid Roux (CS student)
Alternative typesetting programs:
- SATySFi: "A statically-typed, functional typesetting system"
- Patoline: "A modern digital typesetting system"
- build on OCaml
- website currently down
- SILE: "SILE takes some textual instructions and turns them into PDF output. It has features inspired by TeX and InDesign, but seeks to be more flexible, extensible and programmable than them."
- tectonic: "Tectonic is a modernized, complete, self-contained TeX/LaTeX engine, powered by XeTeX and TeXLive."
Articles discussing up/downsides of LaTeX:
Multi-paradigm language with each paradigm being first-class citizen:
-
"produce semantic text paradigm"
This is the same paradigm as found in, say, Markdown and "simple", not too sophisticated LaTeX files.
-
"templating paradigm"
Support getting rid of redundancy; introduce templates as in many wiki languages (e.g. MediaWiki), LaTeX
\newcommand -
"automation paradigm"
Make things automatable, e.g. if you want to draw 10 equal, but shifted lines, then allow that.
-
imperative programming paradigm
TeX neglects this to a great extent.
-
"syntax paradigm"
Use syntax to express things. Do not change syntax' semantics. TeX does this a lot, say, with verbatim environments.
-
"structured paradigm"
Make lines of code, functions, files structured. "Make files non-flat blobs!" This should allow parallelization of, say, tikz figures!
-
"modularity on every level paradigm"
Embrace modularity, possibly allow interfacing with a vast amount of programming languages, too.
- As base, use a strictly-typed language.
- Separate the concerns of providing semantic contents and actual styling.
- Embrace multiple output providers (e.g. PDF, HTML, ...)
- The TeX environment woefully benefitted from TeX packages being a thing. These are
- centrally hosted on CTAN
- easily usable via
\usepackage(most TeX distros auto-install missing packages), but without package version information - usually used global to your TeX installation
- Employ a package system with central repository
- Provide an official package manager for
-
installing package versions project-locally
("project-locally" is to be understood logically. Where the packages end up being written to on your file system is a whole different question!)
-
updating project-local packages
-
flattening/archiving a typesetting document
(write out a file or directory containing everything needed for eternal compatibility)
-
- Make packages being maintainable project-locally by having
tex-packages.json(akin topackages.jsonand many other prog. language package managers; perhaps not JSON?) - Make packages have semantic version
- I think close to no caching, every included .tex file is read and executed again.
- Embrace the "structuring paradigm" and employ elaborated caching, e.g. as found in Scala.
- Upon initial parsing, build a "layout dependency graph".
- Then unrelated things can be computed in parallel (if deemed worth it - e.g. lots of figures)
- Dependencies can be fine-grained, e.g. if width X is known, then this is sufficient to typeset table Y. Even if it's unknown where it will be placed, possibly being split across pages afterwards.
Have mechanized tool support for creating a MWE: select something (say, a paragraph) and have all dependencies automatically puleld in + the option to pull in more indirect side-effect dependencies (e.g. for page layouting).