Polytype: A Rosetta Stone for typesetting engines(polytype.dev)
polytype.dev
Polytype: A Rosetta Stone for typesetting engines
https://polytype.dev/
4 comments
Interesting idea, although I'm not sure of the choice of engines. I recognize LaTeX and groff, but none of the others. And conversely, engines that I would expect to be there like plain TeX, Lout, and even just Markdown (which combined with pandoc can be used to typeset documents). aren't there.
Markdown is not a typesetting engine. It is a markup language. What pandoc does is convert the markdown syntax into LaTeX syntax and then run a TeX engine to produce the desired PDF.
Typst is a new entry in the document typesetting field.
Typst is a new entry in the document typesetting field.
> Markdown is not a typesetting engine. It is a markup language. What pandoc does is convert the markdown syntax into LaTeX syntax and then run a TeX engine to produce the desired PDF.
If we're going to go that route, neither is LaTeX a typesetting engine; it is a macro package built on the typesetting engine of TeX.
If we're going to go that route, neither is LaTeX a typesetting engine; it is a macro package built on the typesetting engine of TeX.
Latex maybe is a typesetting system: a core engine + other stuff.
>although I'm not sure of the choice of engines
If have not searched for (LaTeX-)alternative typesetting engines/systems (nor are an avid HN visitor; all those had at least one popular submission here), unsurprising to not have heard of them. Lout strangely omitted though, yes.
If have not searched for (LaTeX-)alternative typesetting engines/systems (nor are an avid HN visitor; all those had at least one popular submission here), unsurprising to not have heard of them. Lout strangely omitted though, yes.
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)
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.
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.
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.
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.
paged.js and weasyprint ingest HTML, as shown in the helloworld example.
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.
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.
Chrestomathy:
1 : a selection of passages used to help learn a language
2 : a volume of selected passages or stories of an author
1 : a selection of passages used to help learn a language
2 : a volume of selected passages or stories of an author
Is this “typesetting” only referring to things like page layout? For glyph rendering and shaping, I thought FreeType and HarfBuzz were the most popular open source engines, which I don’t see here.
Cool idea. Suggestion: side-by-side output.