Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Typst: A Programmable Markup Language for Typesetting [pdf]

user.tu-berlin.de

Post reply on HN
Print view View original

31–40 of 55 posts

Re: Typst: A Programmable Markup Language for Typesetting [pdf]

#31

Post by chrismorgan »

tannhaeuser wrote: post #22
chrismorgan wrote: post #21

Earlier quoted context omitted.

But HTML never was “an SGML application” in practice, and I highly doubt it was ever actually envisioned as that. There may have been some tools out there that processed HTML as SGML, but none of the ones I know of did (most notably browsers). And in fact, in practice you could just use your own custom elements without worrying about validity and it’d mostly just work. This wasn’t even particularly rare. (There was t…

HTML the markup language was clearly intended as an SGML vocabulary - TBL himself said as much [1] and HTML also reused element names from the SGML spec/handbook as example/folklore vocabulary such as for paragraphs and headings. What browsers made out of it isn't the matter here, but even if it were, the "practical, real-world HTML out there" argument is mostly used to pull up the ladder by an ad company/browser car…

Look, I’ve got to say it. Your entire approach to SGML (in this and many other threads) simply doesn’t match reality now, and, as far as I can tell (though it was before my time), never matched reality in matters pertaining to HTML and XML.

You seem to always start with the assumption that SGML was (and perhaps is) an end goal. I deny this.

HTML was designed as an SGML vocabulary, but, where it mattered, never implemented as an SGML vocabulary. If Tim Berners-Lee ever even expected it to be treated as SGML very much, I suspect he hadn’t thought things through well enough (though that could also just be hindsight bias on my part).

There has never been any particular virtue in HTML being an SGML vocabulary. No one that mattered (which mainly means browsers) cared about SGML, then or now, and no web developers or end users care about SGML, so being SGML is just needless complication and potential for confusion (due to that implying different behaviour from reality). SGML is a hideous, complex beast that no one wants to work with, and which almost everyone that has heard of it is glad is dead.

Yes, SGML had some nice ideas. Yes, we keep on reinventing parts of it. Yes, a variant of Greenspun’s tenth rule applies. But SGML was just too flexible/generic, large and ugly. It doesn’t actually solve things. And the current HTML parser is the best thing since sliced bread and my favourite popular file type spec by a large margin despite its size, because it’s clear, unambiguous, and implementable.

Re: Typst: A Programmable Markup Language for Typesetting [pdf]

#32

Post by virtualritz »

sitkack wrote: post #4
erk__ wrote: post #2

The program for it seems to be the one here https://typst.app/

Their supporting code is available on github and it is all in Rust. https://github.com/typst/

So for sub-pixel accurate font rasterization in Rust there are [1], [2], [3] and now the one from Typist, [4]. Possibly there are more (I know Raph Linus stopped maintaining [5] so that one is out).

All of these crates are actively maintained. Are people re-inventing the wheel?

[1] https://gitlab.redox-os.org/redox-os/rusttype

[2] https://github.com/alexheretic/ab-glyph

[3] https://github.com/mooman219/fontdue

[4] https://github.com/typst/pixglyph

[5] https://github.com/raphlinus/font-rs

Re: Typst: A Programmable Markup Language for Typesetting [pdf]

#33

Post by vitorsr »

Ghast wrote: post #28

This is exciting, as I've been waiting for something like this to come along as I'm typesetting an RPG book with LaTeX, and they generally have rather complex layouts: Random example: https://external-content.duckduckgo.com/iu/?u=https%3A%2F%2F... Calculating stat-blocks by hand is a nighmtare for one author, so I need a typesetting language so I can type `\elf`, and have a random elf, then generate all its derived s…

It is not my intention to overstep what you seem to be very engrossed in but have you tried LuaLaTeX? You can have Lua code that generates valid LaTeX and LaTeX macros that execute Lua code (see [1]). LuaLaTeX also supports TTF and OTF formats which plays well with other publishing software.

In relation to formatting, I cannot tell what could be the issue but this does not correspond to mine and others' experiences.

Typically you would typeset the book with the generally intended text areas with LaTeX, and then generate the preprint with previously not included graphical elements and fine-tuned text layouts with Adobe InDesign. This is what publishers typically do, again, from mine and others' experiences.

[1] http://mirrors.ctan.org/info/luatex/lualatex-doc/lualatex-do...

Re: Typst: A Programmable Markup Language for Typesetting [pdf]

#34

Post by vitorsr »

virtualritz wrote: post #32
sitkack wrote: post #4

Earlier quoted context omitted.

Their supporting code is available on github and it is all in Rust. https://github.com/typst/

So for sub-pixel accurate font rasterization in Rust there are [1], [2], [3] and now the one from Typist, [4]. Possibly there are more (I know Raph Linus stopped maintaining [5] so that one is out). All of these crates are actively maintained. Are people re-inventing the wheel? [1] https://gitlab.redox-os.org/redox-os/rusttype [2] https://github.com/alexheretic/ab-glyph [3] https://github.com/mooman219/fontdue [4] ht…

To me, all of these crates reinvent the wheel when we have FreeType and HarfBuzz which are actually used in the real world.

I see no net gain in implementing or in using subpar nonreal-world-tested libraries just to do so in Rust.

Re: Typst: A Programmable Markup Language for Typesetting [pdf]

#35

Post by less_less »

sebzim4500 wrote: post #19
mjburgess wrote: post #5

As far as I can tell it compiles directly to pdf, which seems a non-starter for submitting to many journals which accept either latex or word documents. This would need various compiler backends (perhaps via pandoc) to be that useful. Certainly it would help adoption if you could emit, eg., markdown/latex/etc. and others you're working with wouldn't need to adopt your tooling.

Markdown is not close to powerful enough to produce all the stuff that Typst can produce, and emitting latex would be a massive technical effort. I think the best hope is that whatever journals currently only accept latex or .docx will start accepting typst files (or at least pdf).

Supporting multiple formats is a bit problematic though, if you want to process everything in the journal together to prepare it for publication. It makes the tooling far more complicated than supporting only one format.

It might be possible to have a subset of typst output to latex though, and then grow that subset. Like you could just evaluate all the functions to get raw text/markdown and then translate that to latex, and at the beginning you just wouldn't support all possible styling choices.

Re: Typst: A Programmable Markup Language for Typesetting [pdf]

#36

Post by less_less »

Note for the authors:

As someone who writes a lot of math, I'm not sure I would want / as stacked fraction to be the default choice, as it is in Word (but not Latex). Many mathematical (sub)expressions, especially short ones, are more readable when written inline with the slash.

Re: Typst: A Programmable Markup Language for Typesetting [pdf]

#37

Post by virtualritz »

vitorsr wrote: post #34
virtualritz wrote: post #32

Earlier quoted context omitted.

So for sub-pixel accurate font rasterization in Rust there are [1], [2], [3] and now the one from Typist, [4]. Possibly there are more (I know Raph Linus stopped maintaining [5] so that one is out). All of these crates are actively maintained. Are people re-inventing the wheel? [1] https://gitlab.redox-os.org/redox-os/rusttype [2] https://github.com/alexheretic/ab-glyph [3] https://github.com/mooman219/fontdue [4] ht…

To me, all of these crates reinvent the wheel when we have FreeType and HarfBuzz which are actually used in the real world. I see no net gain in implementing or in using subpar nonreal-world-tested libraries just to do so in Rust.

How do you know something is sub-par if it is not tested? You can only make a statement about the former if the latter is true. But nice try.

Re: Typst: A Programmable Markup Language for Typesetting [pdf]

#38

Post by tannhaeuser »

chrismorgan wrote: post #31
tannhaeuser wrote: post #22

Earlier quoted context omitted.

HTML the markup language was clearly intended as an SGML vocabulary - TBL himself said as much [1] and HTML also reused element names from the SGML spec/handbook as example/folklore vocabulary such as for paragraphs and headings. What browsers made out of it isn't the matter here, but even if it were, the "practical, real-world HTML out there" argument is mostly used to pull up the ladder by an ad company/browser car…

Look, I’ve got to say it. Your entire approach to SGML (in this and many other threads) simply doesn’t match reality now, and, as far as I can tell (though it was before my time), never matched reality in matters pertaining to HTML and XML. You seem to always start with the assumption that SGML was (and perhaps is) an end goal. I deny this. HTML was designed as an SGML vocabulary, but, where it mattered, never implem…

> There has never been any particular virtue in HTML being an SGML vocabulary. No one that mattered (which mainly means browsers) cared about SGML

You can care about browsers, I care about documents and that they can be read and understood in a couple decades still. Preferably without kissing the ring of an ad company.

Defining your own vocabularies and SGML is also directly mentioned in the paper being discussed. SGML lets you define your own custom language and mapping to HTML as output/rendering language without further tools.

> SGML is a hideous, complex beast that no one wants to work with

As opposed to what? The web platform specs covering all of HTML, CSS, and JS roughly a thousand times the size of the SGML spec? Have you actually studied SGML or implemented a parser for a markup language, or are you repeating what you've heard elsewhere?

> And the current HTML parser is the best thing since sliced bread and my favourite popular file type spec by a large margin despite its size, because it’s clear, unambiguous, and implementable.

Which version of WHATWG HTML5? Oh, WHATWG don't bother versioning their phone-book sized specs. And parsing breaks all the time; eg. current head doesn't contain the param element anymore (as content of the object element still in the spec) which however requires that no end tag is specified, hence a parser for current WHATWG HTML will fail hard in the presence of param elements (similar story with legacy elements such as keygen). Then there are new "boolean attributes" being introduced all the time requiring special rules/markup declarations ...

With respect, the argument isn't particularly relevant anyway as those specs aren't aimed at folks having difficulties following a formal language spec/grammar but need procedural step-by-step instructions instead.

Re: Typst: A Programmable Markup Language for Typesetting [pdf]

#39

Post by laurmaedje »

Ghast wrote: post #28

This is exciting, as I've been waiting for something like this to come along as I'm typesetting an RPG book with LaTeX, and they generally have rather complex layouts: Random example: https://external-content.duckduckgo.com/iu/?u=https%3A%2F%2F... Calculating stat-blocks by hand is a nighmtare for one author, so I need a typesetting language so I can type `\elf`, and have a random elf, then generate all its derived s…

> What licence is typst under?

We will open source in March, probably with a permissive license, but that's not yet definitively decided.

> Will it be able to reference page numbers from a different book dynamically? (so if book-a and book-b are in the same directory, one can reference another's sections)

This is not currently implemented, but also shouldn't be fundamentally impossible.

> Will there be support for intelligent floating images?

There will be floating containers (also with text flowing around). We will probably keep the amount of "intelligence" low for more predicatability. So you would specify top or bottom and it would be placed on the next page with free space.

> Will it accept 'every-page' commands, so I can use that #rect command to show a chapter's name on side-tabs?

Yes, every-page headers, footers, foregrounds, and backgrounds are already available and a way to query for the current chapter name is coming in a future update.

> Will error messages tell me hbox underfull badness 10000 at least 3000 times per compile?

No!

Re: Typst: A Programmable Markup Language for Typesetting [pdf]

#40

Post by laurmaedje »

less_less wrote: post #36

Note for the authors: As someone who writes a lot of math, I'm not sure I would want / as stacked fraction to be the default choice, as it is in Word (but not Latex). Many mathematical (sub)expressions, especially short ones, are more readable when written inline with the slash.

This is interesting feedback. I imagine defining stackedness through global styling wouldn't help, as you would like to decide on a case-by-case basis which one is preferrable?
Post reply on HN