It seems to have started slowly. For me, Github releases have failed to serve requests for hours already.
143 karma · joined October 13, 2022
$ f_\abs{x} $
$ f_\pi{x} $
In fact, not using backslashes for symbols can actually give an _edge_ with this problem because it would allow distinguishing `pi` and `#abs` (option E in the post).
[1]: https://pandoc.org/
The preferences there were honestly rather ad-hoc w.r.t to the pull request and the approach the pull request took. And (as the author laid out), the PR was a rather ad-hoc solution for a problem we discovered literally one night before Typst 0.14 was supposed to be released.
The design thoughts there were a bit half-baked, which is why we've closed the PR and reverted the original change, to get more time to properly reconsider things.
The math syntax has seen little change since Typst's initial release (except for the infamous precedence change in 0.3 that triggered all this) and just has some quirks that haven't been properly ironed out yet. However, it will remain a focus now and we want to give it a proper cleanup.
- You can add an arbitrary number of trailing `[..]` blocks and they are just trailing arguments. So 2 & 3 are really the same.
- 3 & 4 are different because argument lists may _never_ have a space before them in Typst. you can also not write `calc.min (1, 2)`
The reason why the space may not be added is that you can write
#for x in range(5) [
Value is #x
]
The same contributor has recently put a lot work into building a better foundation for Typst's PDF export [1], which decreases file sizes further, and brings many further benefits.
The reason there is no logging yet is because we want to get it _right_ rather than landing a permanent temporary solution. And there were simply more urgent things to do so far.
Also note that if you use an LSP or the web app, you can inspect the live values in your code simply by hovering over them.
One problem we had was over-eager hyphenation. We've addressed that recently. [2]
[1]: https://github.com/typst/typst/blob/9b001e21121ab7b5645aa36f...
That said, our plans for HTML export have definitely become more substantiated and concrete over the past year and once the current work on layout finishes, it is the next big thing on our list.
See also: https://typst.app/docs/reference/text/text/#parameters-lang
> 1) Is it possible to create new structure elements and rules how they can be nested? Now there are headers of several levels, and it's all?
At the moment you cannot define custom structural elements, but you can define a function that produces some layout and the result is very similar. The structural aspect becomes more important when different parties need to agree on the meaning of something, i.e. you and Typst's standard library or you and a package author, so that the styling system also works with for those elements. We will add support for defining custom structural elements down the road.
> 2) What's about tables? 2.a) Multipage tables? 2.b) Multipage tables which have alternative orientation - like landscape table in portrait book?
Tables exist, also multipage tables. The table sizing is already quite flexible (and inspired by CSS grid), otherwise the customization is still quite primitive, though. We will improve tables in the future, for sure. See also here: https://typst.app/docs/reference/basics/table/
> 3) What's about inserts, which must be placed in exact break in the main text?
Do you just mean a block between two paragraphs? If so, that's possible, yes.
> 4) What's about marginalia? Marginalia which must be synchronized with text?
Not implemented at the moment, but planned.
> 5) What's about multicolumn layout? 5.a) What about multicolumn layout which is interrupted by single floating object (which belongs to page, not one column) - there could be two styles, when columns above and under floating object are independent and when they are continue after interruption.
Typst does support multicolumn layout. Floating objects that interrupt both columns are not possible at the moment, but we're aware of the requirement.
> 6) What's about multiple flows of text, synchronized? Think about bi- and triple-lingual texts, like translations of legal documents or poetry. Different flows could go to different pages (odd-even) or different columns on one page, but each page/column must contain same text, even if one language is more compact than another and one page/column will be systematically underfilled.
This is obviously a bit more complicated. I can see supporting something like this, but only in the long term.
> 7) What's about poetry, and modern poetry especially, where each line can require its own indentation (look up Mayakovsky's poetry).
You can create manual line breaks and insert horizontal spacing. Do you imagine a more automatic way?
> 8) What's about footnotes? 8.a) Long, multi-page footnotes? 8.b) Nested footnotes, more than 2 levels of them? 8.c) Nested multi-page footnotes?
This is one of the basic things that is still missing, unfortunately. But it has relatively high priority and we want to ship them before the public beta launch in March.
> 9) Is it possible to create "Problem / Solution" object typical for textbooks? I want to type problems and solutions together and automatically place all problems where they are typed, but move all solutions in designated place (like, last chapter)?
This will be possible with Typst's introspection system (which is already implemented, but not yet fully exposed to the user).
> 10) Is it possible to have Initials automatically?
Not yet, but planned.
> 11) What's with custom alignment rules? For example, in some typographic traditions last line of aligned paragraph must be not shorter than 1/3 of paragraph's width, and must be aligned too if it is longer than 2/3.
Exposing more control over paragraph layout is something I've wanted to do, but we haven't designed such a system yet.
> 12) What's with layout engine in general? Is it TeX' box-and-glue model? Is orphan/widow control customizable?
It's not boxes and glue, but we use TeX's optimal paragraph layout algorithm. Orphan/widow handling is currently baked-in, but similarly to exposing more control over paragraph layout, we also want to expose more control over flow (i.e. page or subbox) layout in the future.
> 13) What's about non-rectangular images? 13.a) Alpha channel support for runaround? 13.b) Additional vector path for runaround? 13.c) Choice should image be trimmed or become background?
Not prioritized, but planned.
> 14) What's about layouts typical for magazines, like "Cosmopolitan"? It is weakest point of TeX-like DTP systems :-(
This is a hard problem. We want to support content flowing across multiple boxes, which is of course a requirement for such a layout. But overall, I think the hardest part is not making it possible, but making the creation of a magazine in a markup-based system actually hassle-free. When creating a magazine, you just benefit much more from dragging stuff around with the mouse than if you're writing a research paper.
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.
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!