The current documentation lacks the necessary descriptions such as show, set, function, etc. Some of the considerations for defining a function, such as not being able to modify global variables, are not mentioned at all. :( The documentation needs to get better.
I feel your frustration; weāre aware that the documentation needs improvement. See e.g. here:
there are probably some other responses in that thread you may be interested in, in case you want some more context of the existing discussion.
Re the āin the near-ish futureā in the post I linked: the plan is to migrate the docs themselves to Typst, which requires some more work on Typstās HTML export. Once these two steps are finished, Iām fairly confident that doc improvements will come more into focus, maybe/hopefully also in terms of community contributions.
Re your concrete criticisms:
I assume you have seen Formatting ā Typst Documentation; do you see any specific things missing from it? Iāll add a first thing: the only show
rule there is for text, which is not even recommended most of the time (this is addressed on the next page of the tutorial though), and thereās no show
-set
example, even though thatās super important in practice.
Functions in general are at Scripting ā Typst Documentation, but yes, a detailed description what modifying a variable in Typst can and canāt achieve is necessary.
fwiw, the shortcomings mentioned in the previous thread were as a consequence reported on Github and promptly improved, so if you have concrete suggestions, please bring them. And if you have concrete questions, please ask them here on the forum.
I also have a similar issue in the formatting section and in the text function that there should be an explicit example of how to use custom fonts locally. It is missing. There is a statement but I think an example would do justice.
Some functions should can be found easily, like symbol
function. First time I read the big Symbol. Beacuse it is more easilier to found but it doesnāt have any information about symbol
function. You can say it is a problem about my ability, but change itās site can be better.
I have the opposite feeling. I find the doc well written, although it could be improved (e.g. query
section). I found many answers in the descriptions of the functions (such as the font
argument of the text
function).
For people coming from LaTeX or having some knowledge in programming language, Typst is quite easy to use.
An efficient way to learn Typst is to read the source code of Typst packages. I have learned a lot by doing this.
Donāt let your frustration to stop you using Typst
I feel Iām a counterexample on the programmer/non-programmer divide.
I am an ocasional programmer with experience in a bunch of languages and even more experience in reading and parsing tech documentation, and I still have my gripes with parts of the docs.
Donāt get me wrong: I love that it is very systematic and easier to skim than LaTeXās. But the two points I sometimes struggle with are:
- Examples. Some parameters take very specific values (e.g. strings that expect a specific format) and it sometimes takes too many links and a bit of guesswork to figure out how things are supposed to work. I find that happens most often to me with complex APIs like
cetz
, but also happened to mr recently while trying to understand the format of a function forfilter
. Many more examples for table configs (or a sort of formatting assistant for it) wouldnāt hurt either. - It is sometimes tricky to find the right docs when you know what you want but not how Typst calls it. I seem to remember I struggled recently figuring how to draw an arc (part of a circle) because I wasnāt searching for the right word.
But this is just anecdotical. As usual, the groundwork is already amazing!
Building off of what @Sergio said, I really think there should be a dedicated āExamplesā section in the documentation. Iām aware there are already examples within many of the function descriptions, but I would like to see a entire collection of examples for common use cases.
I believe that examples are a great way to introduce Typst concepts in a more nonlinear way. This could be exceptionally helpful for people just trying to get familiar with the Typst syntax, or people who just prefer to learn from following others.
I think this also has the potential to also address common formatting challenges and how others in the community have approached them. Speaking from personal experience, I did the vast majority of learning from looking at templates, the examples from the āTutorialā section, and the overview example in the Typst Repo README.md
.
I think that About - Typst Examples Book fills some of your requirements.
For me, the thing that is missing from the documentation is explicit documentation about show, show-set, show-if, and set rules. The section in the tutorial is not helpful when trying to get a quick reference.
I want a reference on these language features, with a quick overview over the syntax forms (it took me forever to figure out that conditional rules (set if) rules even exist) and a complete list of āelementā functions ā i.e. what is set/show-able and what is locate-able.
(Maybe it would help if Styling ā Typst Documentation was labelled āset and show rulesā instead of the vague āstylingā)
In general though, I think the individual documentation entries are quite good, maybe my issue is with finding the correct one? It took me a while to get an intuition for how stuff is classified as āfoundationsā, āmodelā, ālayoutā and āvisualizeā. For example, I would expect Ratio Type ā Typst Documentation and Float Type ā Typst Documentation to be near each other (both are numerical types).
(sorry, this is a bit rambly)
I also miss reference pages for each and all Typst keywords. And proper well specified types for all parameters of all Typst functions.
Now they are severely lacking or Iām just blind. It is stated that some parameter has the type dictionary
but not stated what kind of dictionary the parameter should be.
For example, many inset
parameters can either a relative
or a dictionary
. And the example might show only inset: 5pt
so it is very hard to guess what the dictionary should look like. Well I now know it takes properties like left
or top
but it should be documented. On some functions the dictionaries are documented but on some they are not.
I hope Typst gets a proper documentation some day but I understand it is not the main focus when the API is still changing a lot.
+1, Iāve been using symbols for a long time, but I only learned that I can use symbol(ā¦)
a few days ago. I am adding the missing link in Miscellaneous minor doc improvements by YDX-2147483647 Ā· Pull Request #6651 Ā· typst/typst Ā· GitHub. Hope it will help people in the next release cycle.
This is really cool! Thanks for sharing this with me!
Some things that I would like to see more of (both in the official Typst documentation and in this resource in general) are examples structured around common use cases rather than specific Typst feature sets. In my opinion, we want to minimize the time the user spending trying to find specific functions to accomplish a specific output, rather than having to first go discover what functionality Typst actually has.
Wait, I didnāt even know that set if
is a thingā¦
I second this. Learning these fundamentals took way to long for me since I didnāt understand how to use them.
Hey, author of the Examples Book here!
Can you please give some examples or specify what do you mean? How could it look?
In general, Iām very open to any suggestions, though canāt spend as much time on the book as I want. Would be glad to hear any thoughts on that.
Pleasure meeting you @sitandr! I think you have already done a great job of providing a thorough alternative to the official documentation, and I have already learned a couple of new things :)
Iāve had to take some time to figure out how to best answer your question, and I believe that my thoughts primarily concern example categorization and organization. Reasonably so, youāve opted to structure your book primarily around concepts, starting from the tools and then demonstrating their outputs, which mirrors the approach of the official documentation.
My main thought is that I would be interested in seeing some content organized by the desired output. For instance, instead of a section titled āTablesā showing how to use the table tool, a user looking to create a ātimes tableā would first identify that specific output and then learn that the ātableā function is the tool to achieve it.
In other words, I donāt think thereās necessarily a scarcity of examples, but rather that when Iām trying to make something, I donāt typically start with the tools; I start with the desired end result.
I would be curious to hear your thoughts on this
(P.S. This output-first approach could also be supported by a small layout change: you may consider changing the example layout so we can see the output first instead of the source. This way, users immediately understand what the code snippet is working towards, before diving into the implementation details.)
@jdpieck, thank you for the feedback!
In the case of ātimes tableā Iām not sure it is okay to be a whole visible chapter. If there is a specific labelled example, the book search will most likely give it out immediately.
(well, in case of multiplication table the example wasnāt labelled, but I will fix it)
Iāve tried to split the book into two major parts: an extended tutorial part (Typst Basics) that covers all major concepts user really needs to know to master Typst, and Typst Snippets part. The latter tries to categorise examples roughly by the thing they try to accomplish. Sometimes only the headings are descriptive enough, so the examples would be accessible from search. Categorising them better isnāt easy, Iām afraid.
I really like your idea of moving the preview up, before the text. Thatās not appliable everywhere, unfortunately. In the tutorial, for examples, it is important that person first sees the example, then the output.
I would like to make it configurable. Maybe I should try also using side-by-side view when possible, for better content-code correspondence.
The final note: I hope one day to migrate Typst Book to pure Typst with html export. That will (I hope) make it much easier to contribute and verify results with instant preview and other nice things. But that would certainly require big effort.
Good news: Andrew improved the docs of ratio
in January in Improved ratio and relative length docs by Andrew15-5 Ā· Pull Request #5750 Ā· typst/typst Ā· GitHub. Now the page of ratio
includes a table with links to related types. It will appear on Typst Documentation after the next release.
Besides, the Documentation forge on Discord has been created a few days ago.
If you find any tiny docs problem (so tiny that itās not worth a dedicated issue or post), or want to join in improving the document, you can chat on that channel.
(Improving docs is really easy. No need to know rust.)