Polytype: A Rosetta Stone for typesetting engines

Re:Polytype: A Rosetta Stone for typesetting engines by giraffe_lady on Monday June 24, 2024 @09:15AM (#40775656)

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.

[ Parent | on HN ]

Re:Polytype: A Rosetta Stone for typesetting engines by necovek on Monday June 24, 2024 @02:22PM (#40779175)

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.

[ Parent | on HN ]