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

41–50 of 55 posts

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

#41

Post by vitorsr »

virtualritz wrote: post #37
vitorsr wrote: post #34

Earlier quoted context omitted.

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.

The linked libraries are not even close to solving limited subsets of problems solved by FreeType or HarfBuzz. No test is needed if they do not even have a working implementation of particular requisites: Do they work on heterogeneous layouts, directions, languages, locales, scripts, symbols and composites, extensions, variations, legacy, missing, partial or corrupted instructions, standards interpretations, platforms, output devices, nonstandard point structures and grids?

They do not. What they solve is almost a toy problem compared to the size, scope and breadth of these libraries.

Just because some project is implemented in Rust does not make it comparable never mind superior by default.

There is a world out there and it is not homogeneous format and standards-compliant Latin fonts in English LTR text in linear disposition with some generic rectangular subpixel rendering on a regular rectangular grid.

I warmly welcome you to browse closed issues of FreeType [1] and also the closed issues of HarfBuzz [2]. If you feel inspired please do also look into mailing lists and discussion pages related to the development, building, tracking and patching of packages of these projects in any of the numerous places it is used.

The only argument Rust people have is in relation WASM but if you insist in targeting WASM why not fork FreeType, strip it to the strict subset of features your application needs and target it?

Why do it in the first place? Why reinvent the wheel?

As such I will restate my view: I see no gain in using any of these subpar libraries.

[1] https://gitlab.freedesktop.org/freetype/freetype/-/issues/?s...

[2] https://github.com/harfbuzz/harfbuzz/issues?q=is%3Aclosed

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

#42

Post by less_less »

laurmaedje wrote: post #40
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?

Yeah, it would ideally be per fraction by the author's choice. In Latex notation, inline math is usually $a/b$ especially for simple fractions, because otherwise you expand the line spacing or have really small text. Block math is sometimes $$a/b$$ and sometimes $$\frac{a}{b}$$, depending on what looks cleaner. Exponents are often $x^{a/b}$ to avoid font size / layout issues. It's even fairly common to mix it within a single equation, especially with fractional exponents or fractions of fractions, e.g.:

$$\frac{ x^{2/3} + 7 }{ 4y/z + 9 }$$

This makes it easier to read: nested fractions kinda suck no matter what, but with bars on bars on bars they're even worse.

Anyway, there should at least be a way to specify which fraction notation you want. I would even suggest // for stacked-frac, but that's a comment. Microsoft Word and powerpoint have copied quite a bit of Latex in the past several years which have made them more usable for math, but their lack of fraction rendering control is one of my pet peeves.

Edited to add: Also the slash is used for things other than fractions, like group quotients, which are not conventionally written in the stacked notation.

See eg https://www.math.leidenuniv.nl/~psh/ANTproc/04psh.pdf

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

#43

Post by blacklion »

It is known, that TeX algorithm to split long text into strings to make paragraph is globally-optimal, but splitting stack of lines into pages are only locally-optimal due to memory constrains at the time of original TeX implementation.

Does this system uses globally-optimal algorithm for second step (page composition)? Does anybody know globally-optimal formatting system?

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

#44

Post by blacklion »

I'm reading thesis right now and I could say that it is very well-written text.

Markup-based DTP was my interest for many years, and I happy to see new full-featured players on this field.

MarkDown, AsciiDoc and others github-README formats are nice but disappointingly limited (and under-specified).

Edit:

> the table of contents is typically at the start of a book, not the end.

In my culture it is typical at the end, though in last 20 years a sheer amount of translated literature which layout is copy'n'pasted form originals (by people who was not trained in classical typesetting, but learned DTP on-the-fly) somewhat change this.

If authors want to continue to support & expand their product, they need to study very diverse typesetting traditions of different countries and languages.

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

#45

Post by laurmaedje »

less_less wrote: post #42
laurmaedje wrote: post #40

Earlier quoted context omitted.

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?

Yeah, it would ideally be per fraction by the author's choice. In Latex notation, inline math is usually $a/b$ especially for simple fractions, because otherwise you expand the line spacing or have really small text. Block math is sometimes $$a/b$$ and sometimes $$\frac{a}{b}$$, depending on what looks cleaner. Exponents are often $x^{a/b}$ to avoid font size / layout issues. It's even fairly common to mix it within…

Double slash for stacked fractions was also my first impulse upon reading your post. Currently, it starts a line comment even within math, but that could be changed. We'll consider it!

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

#46

Post by Ghast »

vitorsr wrote: post #33
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.…

I've heard of it, but never seen anything that suits my exact needs. If it solves image float problems, it'll be worth it.

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

#47

Post by Ghast »

laurmaedje wrote: post #39
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 in…

I hope it's FOSS, otherwise it won't be much use - there won't be any way to know if it will work in a couple of years.

> 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.

If it's not too 'intelligent', I hope there is - at a minimum - a floating image command that basically says 'place this floating image so it stays on the same page as this current line'. Currently I'm placing every float about 30 lines before where I want it and hoping for the best. It'd be a lot easier to just say 'place this float 50 lines back, typeset the page, and if the image is not in the right place, then start again 20 lines back', then loop until it's at no lines back or until it's with the right text.

That's ugly coding, but less ugly than the current hacks I do with LaTeX.

I hope the project goes well, and hope to see it in the standard repos before long.

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

#48

Post by laurmaedje »

vitorsr wrote: post #41
virtualritz wrote: post #37

Earlier quoted context omitted.

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.

The linked libraries are not even close to solving limited subsets of problems solved by FreeType or HarfBuzz. No test is needed if they do not even have a working implementation of particular requisites: Do they work on heterogeneous layouts, directions, languages, locales, scripts, symbols and composites, extensions, variations, legacy, missing, partial or corrupted instructions, standards interpretations, platform…

I would argue that font rendering and text shaping are completely separate problems. The font renderer doesn't need to know about directions, language, locales and scripts and using one of these simple libraries doesn't mean that an application cannot have a capable text layout and shaping implementation.

Although Typst uses pixglyph for rendering, it does support BiDi, complex script shaping, etc. For shaping, we use rustybuzz, which is pretty much a 1-1 port of harfbuzz to Rust. Although we would have gladly used harfbuzz, linking C and Rust in WASM is unfortunately not really possible. So we went for the practical choice of helping finish this port and using it.

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

#49

Post by vitorsr »

laurmaedje wrote: post #48
vitorsr wrote: post #41

Earlier quoted context omitted.

The linked libraries are not even close to solving limited subsets of problems solved by FreeType or HarfBuzz. No test is needed if they do not even have a working implementation of particular requisites: Do they work on heterogeneous layouts, directions, languages, locales, scripts, symbols and composites, extensions, variations, legacy, missing, partial or corrupted instructions, standards interpretations, platform…

I would argue that font rendering and text shaping are completely separate problems. The font renderer doesn't need to know about directions, language, locales and scripts and using one of these simple libraries doesn't mean that an application cannot have a capable text layout and shaping implementation. Although Typst uses pixglyph for rendering, it does support BiDi, complex script shaping, etc. For shaping, we us…

Thanks. Yes, rendering and shaping are distinct but some of the linked libraries did one, the other, or both and the parent commenter singled out rastering which is how I ended up putting FreeType and HarfBuzz in the same sentence. Even then both are commonly used in tandem (see [1]-[9]) and have a few overlapping functionalities.

> it does support BiDi, complex script shaping

Hey, that is indeed quite good. Would you mind if I ask you how well is the support for popular Asian languages?

> linking C and Rust in WASM is unfortunately not really possible

Damn. I am not very experienced in Rust but I would not have guessed that. I apologize if I misrepresented difficulties related to targeting WASM.

[1] https://github.com/apple-oss-distributions/WebKit/tree/WebKi...

[2] https://github.com/apple-oss-distributions/WebKit/tree/WebKi...

[3] https://github.com/chromium/chromium/tree/main/third_party/f...

[4] https://github.com/chromium/chromium/tree/main/third_party/h...

[5] https://searchfox.org/mozilla-central/source/modules/freetyp...

[6] https://searchfox.org/mozilla-central/source/gfx/harfbuzz

[7] https://cs.android.com/android/platform/superproject/+/maste...

[8] https://cs.android.com/android/platform/superproject/+/maste...

[9] https://www.amazon.com/gp/help/customer/display.html?nodeId=...

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

#50

Post by virtualritz »

vitorsr wrote: post #41
virtualritz wrote: post #37

Earlier quoted context omitted.

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.

The linked libraries are not even close to solving limited subsets of problems solved by FreeType or HarfBuzz. No test is needed if they do not even have a working implementation of particular requisites: Do they work on heterogeneous layouts, directions, languages, locales, scripts, symbols and composites, extensions, variations, legacy, missing, partial or corrupted instructions, standards interpretations, platform…

I'm sorry but I can't help but conclude that you decided to bring in text shaping to have a reason for your counterpoint to be valid after my last reply.

As someone who studied typography and worked in that field professionally I understand the complexity of these subjects.

If you re-read my question it was about rasterisers. I.e. something that takes a bunch of lines, quadrics and cubics and draws a filled shape.

Everything else you read between the lines of my question but it wasn't there.

Post reply on HN