Of course, one of the main reasons to use TeX for xerif was that TeX is one of the technological building blocks of le-tex. The company also has little experience with other typesetting technologies such as XSL-FO and PrintCSS. But aside from the general tendency towards self-justification bias, there are valid reasons to prefer TeX over PrintCSS:
In contrast to TeX, CSS is not a programming but a formatting language. There is less you can do with PrintCSS and you are dependent on the functionality being provided by a layout engine, the PrintCSS renderer. PrintCSS has a quite smaller feature set compared to TeX and its vast ecosystem of packages. Although PrintCSS, unlike TeX, has a public specification, many things are missing that must be substituted by proprietary functions of the PrintCSS renderer.
PrintCSS might not be as intuitive as InDesign, but its core syntax and principles are beginner-friendly especially if you gained prior knowledge of CSS by web design. It provides a solid foundation for defining page-based layouts, and limitations in the specification could be addressed through vendor-specific CSS extensions.
TeX is a powerful typesetting engine capable of producing high-quality print documents and it might be tempting to think of TeX acting exclusively as a PrintCSS renderer. It is worth recalling that PassiveTeX, created by Michel Goossens and Sebastian Rahtz, served as an experimental solution for leveraging TeX as an XSL-FO formatter [10]. But is TeX also capable of being used as PrintCSS renderer?
Conceptually, mapping CSS properties to TeX equivalents (e.g., margins, page breaks, fonts) is possible. However, this approach present a few practical challenges:
Different paradigms: CSS is box-based and declarative; TeX is macro-based and procedural. A wide range of differences exist also between PrintCSS and TeX, from the underlying page model and font characteristics to the treatment of typographic issues.
Limited parsing capabilities: TeX doesn't natively understand XML, HTML or CSS.
Missing Features : CSS features like flexbox, grid, or advanced selectors have no direct TeX equivalent.
In this context, the three primary challenges involve parsing PrintCSS, transforming HTML to TeX, and accurately mapping CSS styling rules to corresponding TeX commands. However, relying solely on TeX doesn't seem practical for several reasons:
Creating a custom PrintCSS parser in TeX would be necessary, and the same challenge arises when handling HTML or XML. While TeX-based tools like xmltex could be used for XML parsing, they provide only limited configurability and do not support validation. Because of its procedural nature, TeX is not well-suited for navigating complex tree-based structures like XML and generating mixed content. So, there are additional layers needed, to facilitate the transformation between PrintCSS and TeX. The next section provides more details.
[10] 2 Martin Kraetke (2023): Bridging the Gaps Between XML and TEX. PassiveTeX. Available at https://markupuk.org/2023/webhelp/index.html#Sec2.html (Accessed: May 15, 2025)