6 ms·

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

• 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.