[necovek]

Or HTML + CSS for that matter (with media tags for page-specific formatting, but most of the formatting is not page-specific — only page breaks really are, though they are a large area of focus for widow lines, paragraph breaks etc)

[giraffe_lady]

There's a meaningful distinction between the typesetting engine and the markup or interface you use to typeset documents. This project seems only concerned with the underlying engines. But for example go look at a raw groff file, it's obviously not intended to be written by hand and no one does. Latex on the other hand is a complete system, with a language to set documents and an engine to render them.

Html + css or markdown for that matter are only the interface layer, to compare them this way you'd need to specify an implementation. Minute typographic details are still one of the places where browsers diverge from each other in their behavior.

[necovek]

CSS is both a language and specification defining the typesetting (box) model. While there are certainly incompatibilities between different implementations, where CSS + HTML are well-defined, those would be bugs. That's why it's today actually possible to write one set of HTML and CSS and have it render identically in different browsers.

One could say the same for different TeX "formats" like LaTeX or Plain TeX which can be all be rendered with multiple mostly-compatible TeX engines. If you are familiar with TeX internals, it's outputting layouts of boxes for letters (TFM metrics files for fonts) inside pages (DVI files) that get filled later with bitmapped glyphs from bitmap font files (PK fonts). This is entirely different for PDF/PS-based TeX engines which use vector sizing and which are not identical to original TeX.

There are certainly more nuances (eg. hinting for vector fonts that aligns curves to pixel/dot grid), but languages and layout engines are usually tightly coupled.

[bux93]

paged.js and weasyprint ingest HTML, as shown in the helloworld example.

[necovek]

Thanks for highlighting that.

My point was that you don't need anything extra: HTML + CSS define a lot of the laying-out definitions, they are ubiquitouos, and rendering for the screen requires "typesetting" just as much as it does for paper.