5 ms·

TeX is one of those bits of software that's so complex to replace, it'll take another few decades (and likely a few false starts) before we can get there. The

TeX is one of those bits of software that's so complex to replace, it'll take another few decades (and likely a few false starts) before we can get there. The fundamentals of TeX's typesetting are amazing, but everything else is just bolted on. You'd probably want to rebuild it with its own, custom language, perhaps inspired more by modern XML/markdown rather than the old TeX language. The biggest problem that we're going to have moving past TeX is that it's something of a standard for math representation in text. MathML never _really_ took off. Re-training millions of people skilled in typesetting math is going to be _tough_.

ilammy 4y ago
TeX itself is not really complex. The implementation is fine. The hard part is the ecosystem. Any contender is going to face a daunting task of explaining why adopters should throw away 50 years of collective work of thousands of people that went into TeX packages in CTAN. Math notation is at best 1% of the reasons why people use TeX. Packages are.
- mmastrac 4y ago
  > TeX itself is not really complex I'm not sure if we're getting hung up on the word "complex", but here's 60+ pages on paragraph line breaking alone: http://www.eprg.org/G53DOC/pdfs/knuth-plass-breaking.pdf http://www.eprg.org/G53DOC/pdfs/knuth-plass-breaking.pdf Digital Typography is 700 pages long (not everything is going to be TeX fundamentals, but...): https://archive.org/details/digitaltypograph0000knut/page/n7/mode/2up https://archive.org/details/digitaltypograph0000knut/page/n7...
  - svat 4y ago
    The 66-page "Breaking Paragraphs into Lines" is a research paper, and much of it is is the "complexity" of the problem itself, rather than TeX's elegant solution in particular (e.g. pages 48–59 are about history). In a sense, the generality shown in the paper (the various different things that TeX's algorithm can accomplish) shows how TeX reduces the real-world complexity of typesetting with a simple approach that covers all of them. The book "Digital Typography" is, somewhat misleadingly, not a book that was written about digital typography, but simply a collection (https://cs.stanford.edu/~knuth/selected.html https://cs.stanford.edu/~knuth/selected.html) of several papers that Knuth wrote about TeX and Metafont and some related topics, over several decades. Maybe the several hundred pages of the "Computers and Typesetting" series would be a better example for your point: https://cs.stanford.edu/~knuth/abcde.html https://cs.stanford.edu/~knuth/abcde.html In any case, I agree with the comment you're replying to: if you use TeX itself without dragging behind you the entire ecosystem and all the packages (in particular, use plain TeX rather than LaTeX) you'll see it's not really complex, and the implementation is fine. Especially today, with things like LuaTeX scripting (and, say, opTeX) it is feasible to bypass LaTeX and packages and do things yourself — that is, unless external circumstances require you to use LaTeX and packages etc, which is still often the case (e.g. submitting papers to journals).
- tomrod 4y ago
  I think the argument comes down to complexity. Getting Markdown --> Pandoc featureset up to a reasonable fidelity is the next stage IMO, especially if Markdown can be made to support the most common downloaded TeX extension packages.
  - lixtra 4y ago
    Please keep Markdown simple as it is. Feel free to come up with something new that supports Markdown as a subset or overlaps with Markdown.
    - tomrod 4y ago
      I'm unsure of the naming & organizational conventions for Markdown. Are extensions called flavors? If so, I was envisioning a flavor. Markdown as-is is lovely.
  - 0cf8612b2e1e 4y ago
    Not going to happen. If you look at the CommonMark discussions, you will find people adamant that X features not be included for varying reasons. I think the best future option is going to be djot[0]. It is being created by the author of pandoc, who might possibly be the most qualified person in the world to appreciate all if the nuances of marking up text and parsing it. [0] https://www.djot.net/ https://www.djot.net/
    - leephillips 4y ago
      djot syntax looks just like Pandoc’s markdown. What’s the difference?
      - 0cf8612b2e1e 4y ago
        Clean slate design. I think pandoc markdown is a superset of markdown, which must parse the ambiguous parts of the spec. Djot has a goal to eliminate the corner cases and be able to represent all things without requiring the html escape hatch (eg bold text within a word). The rationale page can do a better job than myself. https://github.com/jgm/djot#rationale https://github.com/jgm/djot#rationale
- mapierce2 4y ago
  Working as a mathematician, the math notation is 100% why I use (La)TeX. Packages are just a bonus.
  - KolenCh 4y ago
    amsthm, mathtools, etc.? I doubt one can survive long in typesetting math without the La part of TeX.
macjc 4y ago
MathML is not really for human to type, just as you rarely type long XML by hand. I don’t see the point of MathML at all.
- dkarl 4y ago
  I think it was designed as a low-level browser standard, not an authoring language. It is supposed to provide a stable, standardized target for authoring languages to compile to. Think of it as WASM for math markup. It makes sense if languages for authoring math is an unsettled design space where we need diversity and experimentation. As a browser standard, like WASM, MathML should enable people to experiment with new ideas and hopefully evolve a better authoring language than we would have got if we had tried to invent a language and standardize it at the same time.
cossatot 4y ago
Ideally there would be a replacement of TeX that shares little of its non-math typesetting capabilities but retains (or only slightly modifies) the math syntax. The rest of the system is where the the problems lie, or at least where I waste a lot of time on little things.
- Shorel 4y ago
  Read the Sile documentation. As far as I could get, Sile is exactly that.
the__alchemist 4y ago
I never figured the purpose of MathML. It's ugly/impractical to type as a text-based format. Verbose and inefficient compared to a binary format. A middle ground some people might like, but I can't stand. I'd prefer one of these: - A human-writable text format that's displayed in a formatted way, eg TeX or MathJax - A binary format that represents structs and enums in code with a clear documentation of how it's packed and unpacked. That can be formatted for reading, and perhaps has a TeX-like API (or is just constructed programmatically using an API) MathML, in contrast, provides neither the speed and small size of a binary format, while being unreadable and unwriteable.
- int_19h 4y ago
  Like SVG, the point is to easily embed it into other XML documents.

ilammy 4y ago

TeX itself is not really complex. The implementation is fine. The hard part is the ecosystem. Any contender is going to face a daunting task of explaining why adopters should throw away 50 years of collective work of thousands of people that went into TeX packages in CTAN. Math notation is at best 1% of the reasons why people use TeX. Packages are.

mmastrac 4y ago
> TeX itself is not really complex I'm not sure if we're getting hung up on the word "complex", but here's 60+ pages on paragraph line breaking alone: http://www.eprg.org/G53DOC/pdfs/knuth-plass-breaking.pdf http://www.eprg.org/G53DOC/pdfs/knuth-plass-breaking.pdf Digital Typography is 700 pages long (not everything is going to be TeX fundamentals, but...): https://archive.org/details/digitaltypograph0000knut/page/n7/mode/2up https://archive.org/details/digitaltypograph0000knut/page/n7...
- svat 4y ago
  The 66-page "Breaking Paragraphs into Lines" is a research paper, and much of it is is the "complexity" of the problem itself, rather than TeX's elegant solution in particular (e.g. pages 48–59 are about history). In a sense, the generality shown in the paper (the various different things that TeX's algorithm can accomplish) shows how TeX reduces the real-world complexity of typesetting with a simple approach that covers all of them. The book "Digital Typography" is, somewhat misleadingly, not a book that was written about digital typography, but simply a collection (https://cs.stanford.edu/~knuth/selected.html https://cs.stanford.edu/~knuth/selected.html) of several papers that Knuth wrote about TeX and Metafont and some related topics, over several decades. Maybe the several hundred pages of the "Computers and Typesetting" series would be a better example for your point: https://cs.stanford.edu/~knuth/abcde.html https://cs.stanford.edu/~knuth/abcde.html In any case, I agree with the comment you're replying to: if you use TeX itself without dragging behind you the entire ecosystem and all the packages (in particular, use plain TeX rather than LaTeX) you'll see it's not really complex, and the implementation is fine. Especially today, with things like LuaTeX scripting (and, say, opTeX) it is feasible to bypass LaTeX and packages and do things yourself — that is, unless external circumstances require you to use LaTeX and packages etc, which is still often the case (e.g. submitting papers to journals).
tomrod 4y ago
I think the argument comes down to complexity. Getting Markdown --> Pandoc featureset up to a reasonable fidelity is the next stage IMO, especially if Markdown can be made to support the most common downloaded TeX extension packages.
- lixtra 4y ago
  Please keep Markdown simple as it is. Feel free to come up with something new that supports Markdown as a subset or overlaps with Markdown.
  - tomrod 4y ago
    I'm unsure of the naming & organizational conventions for Markdown. Are extensions called flavors? If so, I was envisioning a flavor. Markdown as-is is lovely.
- 0cf8612b2e1e 4y ago
  Not going to happen. If you look at the CommonMark discussions, you will find people adamant that X features not be included for varying reasons. I think the best future option is going to be djot[0]. It is being created by the author of pandoc, who might possibly be the most qualified person in the world to appreciate all if the nuances of marking up text and parsing it. [0] https://www.djot.net/ https://www.djot.net/
  - leephillips 4y ago
    djot syntax looks just like Pandoc’s markdown. What’s the difference?
    - 0cf8612b2e1e 4y ago
      Clean slate design. I think pandoc markdown is a superset of markdown, which must parse the ambiguous parts of the spec. Djot has a goal to eliminate the corner cases and be able to represent all things without requiring the html escape hatch (eg bold text within a word). The rationale page can do a better job than myself. https://github.com/jgm/djot#rationale https://github.com/jgm/djot#rationale
mapierce2 4y ago
Working as a mathematician, the math notation is 100% why I use (La)TeX. Packages are just a bonus.
- KolenCh 4y ago
  amsthm, mathtools, etc.? I doubt one can survive long in typesetting math without the La part of TeX.

macjc 4y ago

MathML is not really for human to type, just as you rarely type long XML by hand. I don’t see the point of MathML at all.

dkarl 4y ago
I think it was designed as a low-level browser standard, not an authoring language. It is supposed to provide a stable, standardized target for authoring languages to compile to. Think of it as WASM for math markup. It makes sense if languages for authoring math is an unsettled design space where we need diversity and experimentation. As a browser standard, like WASM, MathML should enable people to experiment with new ideas and hopefully evolve a better authoring language than we would have got if we had tried to invent a language and standardize it at the same time.

cossatot 4y ago

Ideally there would be a replacement of TeX that shares little of its non-math typesetting capabilities but retains (or only slightly modifies) the math syntax. The rest of the system is where the the problems lie, or at least where I waste a lot of time on little things.

Shorel 4y ago
Read the Sile documentation. As far as I could get, Sile is exactly that.

the__alchemist 4y ago

I never figured the purpose of MathML. It's ugly/impractical to type as a text-based format. Verbose and inefficient compared to a binary format. A middle ground some people might like, but I can't stand. I'd prefer one of these: - A human-writable text format that's displayed in a formatted way, eg TeX or MathJax - A binary format that represents structs and enums in code with a clear documentation of how it's packed and unpacked. That can be formatted for reading, and perhaps has a TeX-like API (or is just constructed programmatically using an API) MathML, in contrast, provides neither the speed and small size of a binary format, while being unreadable and unwriteable.

int_19h 4y ago
Like SVG, the point is to easily embed it into other XML documents.