one input, many output formats?

[Omikhleia]

From the website:

Single Source Publishing one input, many output formats; different approaches are taken to account for format-specific features

So (1 → N). That's a questionable requirement! Why not "many inputs, one output format" (N → 1), or even, let's go wild, (N → M)...

Regarding the (N → 1) case: accept more than one markup as input, but with all bells and whistles you can, and produce a nice output of a given type out of it, might be great enough. Just questioning! Doing one thing (e.g. outputting a print-ready PDF, or a re-flowable content), but doing it well? Without locking the user in a given input language and all its weirdness...

[Omikhleia]

To clarify my previous message and provide food for thought, going through (some of) the mentioned software on the website

• TeX (and derivative) "converts custom syntax to DVI"
  • Basically input is in TeX-macros usually = it boils down to (1 → 1) most of the time (TeX -> (DVI or not) -> PDF).
  • Some engines skip the DVI step, so the description is already kind of limited... Anyway, DVI/PDF are in the same game, sort of.
  • There are some good efforts to have it use other input formats quite natively (e.g. Markdown with https://github.com/Witiko/markdown, which I find pretty cool in its scope), so it could be considered (2 → 1) or more.
• Typst "converts custom syntax to PDF | PNG"
  • So (1 → 2)? (depending whether a bunch of raster PNG is an acceptable 'alternate' output ^^)
• Patoline "converts custom language to PDF | SVG"
  • So (1 → 2)? (depending whether a bunch of SVG is an acceptable 'alternate' output ^^)
• YeX "converts custom language to HTML | SVG"
  • So (1 → 2)? (depending whether a bunch of SVG is an acceptable 'alternate' output ^^)
• PageBot "converts python3 to ..."
  • Looks like a library to me, not a usable typesetting system (although from description, it could be part of one). I don't understand why it's listed, but I don't know much about it. You don't expect end-users to fully code their documents in python, right?
• SILE "converts custom language (Teχ-like), XML to PDF"
  • I am perhaps biased here, and what follows reflects my own personal views...
  • SILE has indeed a custom SIL (on the surface TeX-like in syntax, though that's not fully true) and an equivalent XML representation of it (to keep things simple here)...
  • ... But "inputters" are extensible elements by design, and there are native solutions for "Markdown, Djot, Pandoc JSON AST"[^1] and for natively processing various XML documents (that is, beyond the XML flavor of the SIL language), e.g. subsets of TEI, USFX/USX, DocBook... In all honesty, the latter are not very advanced and remain quite experimental at this date (these schemas are huge beasts), and the lack of involved developers might show there... but in my view it would be close to a (N → 1) approach, by design. (Well, "outputters" are extensible too, but let's face it, PDF is the only target at the time of writing)

[^1]: I didn't hide I was biased, so there you go: https://github.com/Omikhleia/markdown.sile

[tajpulo]

Thank you very much for the input.

I fully agree on the remarks regarding input. It was never my intention (to exclude multiple input formats), but I phrased it that way. I will fix this on Friday (“One or more input formats; many output formats; different approaches are taken to account for format-specific features”). Typesetting systems should always aim at typesetting content of an abstract tree, not a specific format. Which also happens mostly. Thank you!

Regarding PageBot: It was suggested to me as typesetting system, but I think I will remove it because I cannot see either how one can typeset without implementing some typesetting components oneself in python. Technically I cannot see a criterion against “a programming language as input language” (studying a markup language isn't always trivial either), but in general I think I will find a flaw which will remove it from the list again.

Regarding SILE: That triggers the difficult question how one should consider third-party components. Should we only take a look at components part of the distribution or also extensibility opportunities? I don't know either and currently my approach was “only builtin components”. Any opinions are appreciated.

[Omikhleia]

Regarding SILE: That triggers the difficult question how one should consider third-party components. Should we only take a look at components part of the distribution or also extensibility opportunities? I don't know either and currently my approach was “only builtin components”. Any opinions are appreciated.

(Plain-)TeX alone is fairly hard to use. What makes the TeX-based solutions so powerful is also the strong ecosystem it has built and the many 3rd-party components which are available (e.g. on the CTAN) to address additional needs. I don't think many people still use Plain-TeX (though I know some who still do, heh!): Most likely, people use LaTeX or ConTeXt, and a good bunch of extra packages (such as Tikz for graphs, or Koma classes etc.)

So a comparison based only on "builtin components" it probably too limited.

I think a possible way here is to check whether the proposed solutions have such an ecosystem, with extra components made available beyond the "bare" core distribution, and reasonable ways to install them.

TeX and friends obviously tick the checkbox positively here.

Speaking of SILE, that's only really true, IMHO, since quite recently (v0.14.0 in August 2022): The current main maintainer did a great job in my opinion at replacing the former package management system with a much easier to use solution based on luarocks. The ecosystem is thus therefore still small --- Currently, it mostly consists in my own contributions to it ^^ ... Yet I think it was a pretty good move and a game changer.

Regarding Typst, I don't know --- but it's probably too soon to say anyway.

It's not a definitive criteria. Speedata, for instance, might not have an 3rd-party ecosystem (or I am unaware of it), but it does a lot of cool things on its own! Still, it says something. Regarding other listed solutions, well, it may even raise other concerns about their actual viability...