Typst Extra Docs

This is an unofficial collection of extra official documentations for Typst.

• Typst’s official GitHub repositories (github.com/typst) contain some files that are missing in the official Typst Documentation (typst.app/docs). These files are collected here to help reading and searching.

• Snapshots of the official Typst Documentation are also stored here, for reading offline or using previous versions.

See also

• hypher — Docs.rs lists the languages supported by Typst for hyphenation.

• typst(1) — Arch manual pages provides an online preview of typst --help.

• 📚 Documentation — Best of Typst (TCDM) lists a number of unofficial supplementary materials:

  • Typst Examples Book
  • Typst CLI Documentation
  • Typst 日本語ドキュメント
  • Typst 中文社区导航
  • …

License

Files from the official Typst repositories are licensed under their respective licenses.

Other files to build this website are licensed as MIT.

Typst

Note

The following is an unofficial copy of the file in Typst’s official repository as of 2026-01-26.

Typst is a new markup-based typesetting system that is designed to be as powerful as LaTeX while being much easier to learn and use. Typst has:

• Built-in markup for the most common formatting tasks
• Flexible functions for everything else
• A tightly integrated scripting system
• Math typesetting, bibliography management, and more
• Fast compile times thanks to incremental compilation
• Friendly error messages in case something goes wrong

This repository contains the Typst compiler and its CLI, which is everything you need to compile Typst documents locally. For the best writing experience, consider signing up to our collaborative online editor for free.

Example

A gentle introduction to Typst is available in our documentation. However, if you want to see the power of Typst encapsulated in one image, here it is:

Let’s dissect what’s going on:

• We use set rules to configure element properties like the size of pages or the numbering of headings. By setting the page height to auto, it scales to fit the content. Set rules accommodate the most common configurations. If you need full control, you can also use show rules to completely redefine the appearance of an element.

• We insert a heading with the = Heading syntax. One equals sign creates a top level heading, two create a subheading and so on. Typst has more lightweight markup like this; see the syntax reference for a full list.

• Mathematical equations are enclosed in dollar signs. By adding extra spaces around the contents of an equation, we can put it into a separate block. Multi-letter identifiers are interpreted as Typst definitions and functions unless put into quotes. This way, we don’t need backslashes for things like floor and sqrt. And phi.alt applies the alt modifier to the phi to select a particular symbol variant.

• Now, we get to some scripting. To input code into a Typst document, we can write a hash followed by an expression. We define two variables and a recursive function to compute the n-th fibonacci number. Then, we display the results in a center-aligned table. The table function takes its cells row-by-row. Therefore, we first pass the formulas $F_1$ to $F_8$ and then the computed fibonacci numbers. We apply the spreading operator (..) to both because they are arrays and we want to pass the arrays’ items as individual arguments.

#set page(width: 10cm, height: auto)
#set heading(numbering: "1.")

= Fibonacci sequence
The Fibonacci sequence is defined through the
recurrence relation $F_n = F_(n-1) + F_(n-2)$.
It can also be expressed in _closed form:_

$ F_n = round(1 / sqrt(5) phi.alt^n), quad
  phi.alt = (1 + sqrt(5)) / 2 $

#let count = 8
#let nums = range(1, count + 1)
#let fib(n) = (
  if n <= 2 { 1 }
  else { fib(n - 1) + fib(n - 2) }
)

The first #count numbers of the sequence are:

#align(center, table(
  columns: count,
  ..nums.map(n => $F_#n$),
  ..nums.map(n => str(fib(n))),
))

Installation

Typst’s CLI is available from different sources:

• You can get sources and pre-built binaries for the latest release of Typst from the releases page. Download the archive for your platform and place it in a directory that is in your PATH. To stay up to date with future releases, you can simply run typst update.

• You can install Typst through different package managers. Note that the versions in the package managers might lag behind the latest release.

  • Linux:
    • View Typst on Repology
    • View Typst’s Snap
  • macOS: brew install typst
  • Windows: winget install --id Typst.Typst

• If you have a Rust toolchain installed, you can install

  • the latest released Typst version with cargo install --locked typst-cli
  • a development version with cargo install --git https://github.com/typst/typst --locked typst-cli

• Nix users can

  • use the typst package with nix-shell -p typst
  • build and run the Typst flake with nix run github:typst/typst-flake -- --version.

• Docker users can run a prebuilt image with docker run ghcr.io/typst/typst:latest --help.

Usage

Once you have installed Typst, you can use it like this:

# Creates `file.pdf` in working directory.
typst compile file.typ

# Creates a PDF file at the desired path.
typst compile path/to/source.typ path/to/output.pdf

You can also watch source files and automatically recompile on changes. This is faster than compiling from scratch each time because Typst has incremental compilation.

# Watches source files and recompiles on changes.
typst watch file.typ

Typst further allows you to add custom font paths for your project and list all of the fonts it discovered:

# Adds additional directories to search for fonts.
typst compile --font-path path/to/fonts file.typ

# Lists all of the discovered fonts in the system and the given directory.
typst fonts --font-path path/to/fonts

# Or via environment variable (Linux syntax).
TYPST_FONT_PATHS=path/to/fonts typst fonts

For other CLI subcommands and options, see below:

# Prints available subcommands and options.
typst help

# Prints detailed usage of a subcommand.
typst help watch

If you prefer an integrated IDE-like experience with autocompletion and instant preview, you can also check out our free web app. Alternatively, there is a community-created language server called Tinymist which is integrated into various editor extensions.

Community

The main places where the community gathers are our Forum and our Discord server. The Forum is a great place to ask questions, help others, and share cool things you created with Typst. The Discord server is more suitable for quicker questions, discussions about contributing, or just to chat. We’d be happy to see you there!

Typst Universe is where the community shares templates and packages. If you want to share your own creations, you can submit them to our package repository.

If you had a bad experience in our community, please reach out to us.

Contributing

We love to see contributions from the community. If you experience bugs, feel free to open an issue. If you would like to implement a new feature or bug fix, please follow the steps outlined in the contribution guide.

To build Typst yourself, first ensure that you have the latest stable Rust installed. Then, clone this repository and build the CLI with the following commands:

git clone https://github.com/typst/typst
cd typst
cargo build --release

The optimized binary will be stored in target/release/.

Another good way to contribute is by sharing packages with the community.

Pronunciation and Spelling

IPA: /taɪpst/. “Ty” like in Typesetting and “pst” like in Hipster. When writing about Typst, capitalize its name as a proper noun, with a capital “T”.

Design Principles

All of Typst has been designed with three key goals in mind: Power, simplicity, and performance. We think it’s time for a system that matches the power of LaTeX, is easy to learn and use, all while being fast enough to realize instant preview. To achieve these goals, we follow three core design principles:

• Simplicity through Consistency: If you know how to do one thing in Typst, you should be able to transfer that knowledge to other things. If there are multiple ways to do the same thing, one of them should be at a different level of abstraction than the other. E.g. it’s okay that = Introduction and #heading[Introduction] do the same thing because the former is just syntax sugar for the latter.

• Power through Composability: There are two ways to make something flexible: Have a knob for everything or have a few knobs that you can combine in many ways. Typst is designed with the second way in mind. We provide systems that you can compose in ways we’ve never even thought of. TeX is also in the second category, but it’s a bit low-level and therefore people use LaTeX instead. But there, we don’t really have that much composability. Instead, there’s a package for everything (\usepackage{knob}).

• Performance through Incrementality: All Typst language features must accommodate for incremental compilation. Luckily we have comemo, a system for incremental compilation which does most of the hard work in the background.

Acknowledgements

We’d like to thank everyone who is supporting Typst’s development, be it via GitHub sponsors or elsewhere. In particular, special thanks¹ go to:

• Posit for financing a full-time compiler engineer
• NLnet for supporting work on Typst via multiple grants through the NGI Zero Core fund:
  • Work on HTML export
  • Work on PDF accessibility
• Science & Startups for having financed Typst development from January through June 2023 via the Berlin Startup Scholarship
• Zerodha for their generous one-time sponsorship

1. This list only includes contributions for our open-source work that exceed or are expected to exceed €10K. ↩

Note

The following is an unofficial copy of the file in Typst’s official repository as of 2026-01-26.

Typst Compiler Architecture

Wondering how to contribute or just curious how Typst works? This document covers the general structure and architecture of Typst’s compiler, so you get an understanding of what’s where and how everything fits together.

Directories

Let’s start with a broad overview of the directories in this repository:

• crates/typst: The main compiler crate which defines the complete language and library.
• crates/typst-cli: Typst’s command line interface. This is a relatively small layer on top of the compiler and the exporters.
• crates/typst-eval: The interpreter for the Typst language.
• crates/typst-html: The HTML exporter.
• crates/typst-ide: Exposes IDE functionality.
• crates/typst-kit: Contains various default implementation of functionality used in typst-cli.
• crates/typst-layout: Typst’s layout engine.
• crates/typst-library: Typst’s standard library.
• crates/typst-macros: Procedural macros for the compiler.
• crates/typst-pdf: The PDF exporter.
• crates/typst-realize: Typst’s realization subsystem.
• crates/typst-render: A renderer for Typst frames.
• crates/typst-svg: The SVG exporter.
• crates/typst-syntax: Home to the parser and syntax tree definition.
• crates/typst-timing: Performance timing for Typst.
• crates/typst-utils: Utilities for Typst.
• docs: Generates the content of the official documentation from markdown files and the inline Rust documentation. Only generates the content and structure, not the concrete HTML (that part is currently closed source).
• tests: Integration tests for Typst compilation.
• tools: Tooling for development.

Compilation

The source-to-PDF compilation process of a Typst file proceeds in four phases.

1. Parsing: Turns a source string into a syntax tree.
2. Evaluation: Turns a syntax tree and its dependencies into content.
3. Layout: Layouts content into frames.
4. Export: Turns frames into an output format like PDF or a raster graphic.

The Typst compiler is incremental: Recompiling a document that was compiled previously is much faster than compiling from scratch. Most of the hard work is done by comemo, an incremental compilation framework we have written for Typst. However, the compiler is still carefully written with incrementality in mind. Below we discuss the four phases and how incrementality affects each of them.

Parsing

The syntax tree and parser are located in crates/typst-syntax. Parsing is a pure function &str -> SyntaxNode without any further dependencies. The result is a concrete syntax tree reflecting the whole file structure, including whitespace and comments. Parsing cannot fail. If there are syntactic errors, the returned syntax tree contains error nodes instead. It’s important that the parser deals well with broken code because it is also used for syntax highlighting and IDE functionality.

Typedness: The syntax tree is untyped, any node can have any SyntaxKind. This makes it very easy to (a) attach spans to each node (see below), (b) traverse the tree when doing highlighting or IDE analyses (no extra complications like a visitor pattern). The typst::syntax::ast module provides a typed API on top of the raw tree. This API resembles a more classical AST and is used by the interpreter.

Spans: After parsing, the syntax tree is numbered with span numbers. These numbers are unique identifiers for syntax nodes that are used to trace back errors in later compilation phases to a piece of syntax. The span numbers are ordered so that the node corresponding to a number can be found quickly.

Incremental: Typst has an incremental parser that can reparse a segment of markup or a code/content block. After incremental parsing, span numbers are reassigned locally. This way, span numbers further away from an edit stay mostly stable. This is important because they are used pervasively throughout the compiler, also as input to memoized functions. The less they change, the better for incremental compilation.

Evaluation

The evaluation phase lives in crates/typst-eval. It takes a parsed Source file and evaluates it to a Module. A module consists of the Content that was written in it and a Scope with the bindings that were defined within it.

A source file may depend on other files (imported sources, images, data files), which need to be resolved. Since Typst is deployed in different environments (CLI, web app, etc.) these system dependencies are resolved through a general interface called a World. Apart from files, the world also provides configuration and fonts.

Interpreter: Typst implements a tree-walking interpreter. To evaluate a piece of source, you first create a Vm with a scope stack. Then, the AST is recursively evaluated through trait impls of the form fn eval(&self, vm: &mut Vm) -> Result<Value>. An interesting detail is how closures are dealt with: When the interpreter sees a closure / function definition, it walks the body of the closure and finds all accesses to variables that aren’t defined within the closure. It then clones the values of all these variables (it captures them) and stores them alongside the closure’s syntactical definition in a closure value. When the closure is called, a fresh Vm is created and its scope stack is initialized with the captured variables.

Incremental: In this phase, incremental compilation happens at the granularity of the module and the closure. Typst memoizes the result of evaluating a source file across compilations. Furthermore, it memoizes the result of calling a closure with a certain set of parameters. This is possible because Typst ensures that all functions are pure. The result of a closure call can be recycled if the closure has the same syntax and captures, even if the closure values stems from a different module evaluation (i.e. if a module is reevaluated, previous calls to closures defined in the module can still be reused).

Layout

The layout phase takes Content and produces one Frame per page for it. To layout Content, we first have to realize it by applying all relevant show rules to the content. Since show rules may be defined as Typst closures, realization can trigger closure evaluation, which in turn produces content that is recursively realized. Realization is a shallow process: While collecting list items into a list that we want to layout, we don’t realize the content within the list items just yet. This only happens lazily once the list items are layouted.

When we a have realized the content into a layoutable element, we can then layout it into regions, which describe the space into which the content shall be layouted. Within these, an element is free to layout itself as it sees fit, returning one Frame per region it wants to occupy.

Introspection: How content layouts (and realizes) may depend on how it itself is layouted (e.g., through page numbers in the table of contents, counters, state, etc.). Typst resolves these inherently cyclical dependencies through the introspection loop: The layout phase runs in a loop until the results stabilize. Most introspections stabilize after one or two iterations. However, some may never stabilize, so we give up after five attempts.

Incremental: Layout caching happens at the granularity of the element. This is important because overall layout is the most expensive compilation phase, so we want to reuse as much as possible.

Export

Exporters live in separate crates. They turn layouted frames into an output file format.

• The PDF exporter takes layouted frames and turns them into a PDF file.
• The SVG exporter takes a frame and turns it into an SVG.
• The built-in renderer takes a frame and turns it into a pixel buffer.
• HTML export does not exist yet, but will in the future. However, this requires some complex compiler work because the export will start with Content instead of Frames (layout is the browser’s job).

IDE

The crates/typst-ide crate implements IDE functionality for Typst. It builds heavily on the other modules (most importantly, syntax and eval).

Syntactic: Basic IDE functionality is based on a file’s syntax. However, the standard syntax node is a bit too limited for writing IDE tooling. It doesn’t provide access to its parents or neighbours. This is fine for an evaluation-like recursive traversal, but impractical for IDE use cases. For this reason, there is an additional abstraction on top of a syntax node called a LinkedNode, which is used pervasively across the ide module.

Semantic: More advanced functionality like autocompletion requires semantic analysis of the source. To gain semantic information for things like hover tooltips, we directly use other parts of the compiler. For instance, to find out the type of a variable, we evaluate and realize the full document equipped with a Tracer that emits the variable’s value whenever it is visited. From the set of resulting values, we can then compute the set of types a value takes on. Thanks to incremental compilation, we can recycle large parts of the compilation that we had to do anyway to typeset the document.

Incremental: Syntactic IDE stuff is relatively cheap for now, so there are no special incrementality concerns. Semantic analysis with a tracer is relatively expensive. However, large parts of a traced analysis compilation can reuse memoized results from a previous normal compilation. Only the module evaluation of the active file and layout code that somewhere within evaluates source code in the active file needs to re-run. This is all handled automatically by comemo because the tracer is wrapped in a comemo::TrackedMut container.

Tests

Typst has an extensive suite of integration tests. These tests cover parsing, evaluation, realization, layout, and rendering. PDF output is sadly untested so far, but most bugs are in earlier phases of the compiler. For more details about testing, see the tests directory and its README.

Snapshots of Docs

This page lists unofficial snapshots of the official Typst Documentation for reading offline (#2089) or using previous versions (#5387).

Download links (each one is ~15 MB):

• v0.14.2 (retrieved on 2025-12-19)
• v0.14.1 (retrieved on 2025-12-10)
• v0.14.0 (retrieved on 2025-11-04)
• v0.13.1 (retrieved on 2025-09-11)

The above *.zim files were created by running Zimit against typst.app/docs.

To view the contents, you will need a ZIM file reader, which usually means Kiwix. The screenshot below shows how it looks in the Kiwix Firefox extension. It’s in the browser, but totally offline, and even the search box works. Kiwix is also available on other browsers, desktop computers, mobile devices, and more platforms.

See also

• typst-docs-web hosts multiple versions of the Typst documentation, but in an alternative layout and with full-text search.

• 🏗 Documentation infrastructure — Best of Typst (TCDM) lists more tools for building the Typst documentation.

Tip

This chapter only contains the design and changelog of symbols. For regular use, read the official documentation:

• Symbol Type – Typst Documentation — how to use symbols
• Symbols – Typst Documentation — what symbols are available, categorized as sym and emoji
• Math – Typst Documentation — how to write mathematical formulae

Note

The following is an unofficial copy of the file in Typst’s official repository as of 2026-01-26.

codex

Human-friendly notation for Unicode symbols.

License

This crate is licensed under the Apache 2.0 license.

Note

The following is an unofficial copy of the file in Typst’s official repository as of 2026-01-26.

Contributing Guidelines

Contributions are welcome! This document provides some resources and guidelines to help with the process.

Codex collects related Unicode symbols as different variants of the same symbol.¹ For example, → ⇒ ↑ ⇑ are four variants of the arrow symbol. Each symbol has a default variant (here →). To refer to a particular variant, modifiers can be appended to the symbol name using dot separators. For example ⇒ is arrow.r.double, ↑ is arrow.t and ⇑ is arrow.t.double. Modifiers are order-independent, so the latter can also be referred to as arrow.double.t. Additionally, not all modifiers have to be specified, in which case the best match² will be taken. For example, ⇒ can also be referred to as arrow.double. Groups of related symbols are collected into modules. Modules can also contain other modules. Codex exports two top-level modules: sym for text-style symbols and emoji for emoji; Their source code is found in src/modules/.

If you need help with a contribution, you can also ask us on Discord.

Proposals used to be written in a dedicated Proposals document, but new proposals should now be filed as GitHub issues instead. The document has been repurposed to serve as a collection of useful information and naming ideas.

Pull Requests

• All PRs require two approvals by collaborators to be merged.
• PRs with breaking changes require three such approvals instead.
• PRs with changes to the public Rust API also require an approval by @laurmaedje.

To remove a symbol or variant, it is first marked as deprecated (This is considered a breaking change). After a Typst version that includes this deprecation notice has been released, the deprecated symbol or variant will be removed (This is not considered a breaking change). Instead of being removed, the name can also be repurposed for a different symbol, which can be seen as a combination of removing the old symbol or variant and adding a new one with the same name.

Conventions

When adding new modules, symbols or variants, please try to be consistent with existing ones. Below are some guidelines based on existing symbols. These aren’t always hard rules, especially because of how messy Unicode can be, but you should adhere to them if possible.

General Conventions

• English words use US spelling.
• Modifier and module names are entirely lowercase.
• Symbol names are lowercase unless the symbol is an uppercase letter.
• Symbol names should be at least two characters long so they can be used easily in Typst’s math mode.
• When a symbol is added to a base, the symbol name is used as a modifier on the base.³ This can have the following meanings:
  1. The symbol is added around or inside the base as a subordinate (smaller than the base), e.g. eq.quest, triangle.stroked.dot.
  2. The symbol is stacked below the base, e.g. gt.lt.
  3. The symbol is stacked to the right of the base, e.g. colon.eq.
  4. The symbol is overlaid at the center of the base, e.g. integral.dash.
  5. The symbol surrounds the base, e.g. plus.square.
• Notable exceptions to the previous convention:
  • When .eq is used in the second sense (stacked below), it only adds a single line and not two, e.g. lt.eq. For two lines below, .equiv is used, e.g. lt.equiv.

Established Generic Modifiers

These have a broad meaning and can have varying interpretations.

• .l/.r/.t/.b: The four main directions (left/right/top/bottom), e.g. arrow.l, times.r.
  • For delimiters, .l means opening and .r means closing, e.g. paren.l, quote.r.
• .tl/.tr/.bl/.br: The four corners, e.g. arrow.tl, triangle.stroked.tr.
  • Generally, these are used for a single, diagonal direction, whereas combinations of two main directions (like .t.l) are used to mean both of them at once, e.g. arrow.t.l, if it existed, would be a bidirectional arrow that points both top and left, similarly to how arrow.l.r is an arrow pointing both left and right.
• .cw/.ccw: Clockwise/Counterclockwise, e.g. arrow.cw, integral.ccw.
• .tiny/.small/.medium/.big: A geometric shape with a certain size, e.g. square.stroked.small.

• .stroked/.filled: A symbol that has an empty/filled interior, e.g. circle.stroked, arrow.r.filled. (They correspond to Unicode’s “white”/“black”.)
• .dotted: A shape with a dotted line instead of a full stroke, e.g. circle.dotted.
• .light/.heavy: A shape with a certain stroke weight, e.g. checkmark.heavy.

• .alt: An alternate glyph for the symbol, e.g. phi.alt.
• .double, .triple, .quad: A symbol that has 2-4 of something, e.g. excl.double, eq.quad.

Established Concrete Modifiers

These have a specific meaning that is not open to much interpretation.

• .big: A large (n-ary) version of an operator, e.g. union.big.
• .inv: Either vertically mirrored or a 180° rotated version of a symbol, e.g. amp.inv, Omega.inv.
  • See also #108.
• .not: A negation of the symbol, e.g. eq.not.
• .o: A symbol with a circle around it, e.g. plus.o.
  • See also #62
• .rev: A horizontally mirrored version of a symbol, e.g. in.rev.
  • See also #108.
• .sq: A “squarified” version of a symbol, e.g. subset.sq.
  • See also #110

1. This document also uses “symbol” in the more abstract sense of a graphical symbol. ↩

2. See the documentation of ModifierSet::best_match_in for the exact details. ↩

3. Though a modifier can also just coincidentally be a symbol name, e.g. .not. ↩

Note

The following is an unofficial copy of the file in Typst’s official repository as of 2026-01-26.

Changelog

Unreleased

General changes

• Trivially updated to Unicode 17.0.0

New in sym

• Mathematical symbols

  • union.serif: ∪︀
  • union.sq.serif: ⊔︀
  • inter.serif: ∩︀
  • inter.sq.serif: ⊓︀
  • gt.double.nested: ⪢
  • lt.double.nested: ⪡
  • gt.arc ⪧
  • gt.arc.eq ⪩
  • lt.arc: ⪦
  • lt.arc.eq: ⪨
  • subset.approx: ⫉
  • subset.closed: ⫏
  • subset.closed.eq: ⫑
  • subset.eq.dot: ⫃
  • subset.equiv: ⫅
  • subset.nequiv: ⫋
  • subset.plus: ⪿
  • subset.tilde: ⫇
  • subset.times: ⫁
  • supset.approx: ⫊
  • supset.closed: ⫐
  • supset.closed.eq: ⫒
  • supset.eq.dot: ⫄
  • supset.equiv: ⫆
  • supset.nequiv: ⫌
  • supset.plus: ⫀
  • supset.tilde: ⫈
  • supset.times: ⫂
  • pee: ℘
  • gt.closed: ⊳
  • gt.closed.eq: ⊵
  • gt.closed.eq.not: ⋭
  • gt.closed.not: ⋫
  • lt.closed: ⊲
  • lt.closed.eq: ⊴
  • lt.closed.eq.not: ⋬
  • lt.closed.not: ⋪

• Miscellaneous technical

  • bowtie.stroked: ⋈
  • bowtie.stroked.big: ⨝
  • bowtie.stroked.big.l: ⟕
  • bowtie.stroked.big.r: ⟖
  • bowtie.stroked.big.l.r: ⟗
  • bowtie.filled: ⧓
  • bowtie.filled.l: ⧑
  • bowtie.filled.r: ⧒

• Currency

  • riyal: ⃁

New in emoji

• bigfoot: 🫈
• dancing.ballet: 🧑‍🩰
• face.distorted: 🫪
• fightcloud: 🫯
• landslide: 🛘
• orca: 🫍
• treasure: 🪎
• trombone: 🪊

Deprecations in sym

• gt.tri and variants in favor of gt.closed
• lt.tri and variants in favor of lt.closed
• join and its variants in favor of bowtie.big with the same variants

Removals (Breaking change)

These previously deprecated items were removed:

• paren.double.*
• brace.double.*
• bracket.double.*
• shell.double.*
• bar.circle
• ast.small
• ast.circle
• backslash.circle
• dash.circle
• dot.circle, dot.circle.big
• quote.angle.*
• plus.circle, plus.circle.*
• plus.small
• minus.circle
• div.circle
• times.circle, times.circle.big
• eq.circle
• eq.small
• gt.circle
• gt.small
• lt.circle
• lt.small
• sect, sect.*
• diff
• integral.sect
• angle.l, angle.l.*
• angle.r, angle.r.*
• angle.oblique
• angle.right.sq
• angle.spheric.top
• parallel.circle
• perp.circle
• franc
• circle.nested
• kai, Kai
• alef
• bet
• gimmel
• dalet
• shin
• planck.reduce

Version 0.2.0 (October 7, 2025)

General changes

• Codepoints that have a symbol and emoji presentation now have the correct variation selector attached depending on whether they appear in sym or emoji
• Added support for multi-character symbols (Breaking change)
• Added support for deprecated symbol variants (Breaking change)
• Added ModifierSet type and made use of it in public API (Breaking change)
• Added Symbol::get, Symbol::variants, and Symbol::modifiers functions
• Added Rust module for styling mathematical codepoints (behind styling feature flag, enabled by default)

Changed codepoint (Breaking change)

• sym.planck from ℎ to ħ
• sym.peso from ₱ to $
• emoji.dancing.bunny from women to gender neutral
• emoji.handholding from men to gender neutral

New in sym

• Arrows

  • arrow.r.double.struck: ⤃
  • arrow.r.struck: ⇸
  • arrow.r.dstruck: ⇻
  • arrow.r.tail.struck: ⤔
  • arrow.r.tail.dstruck: ⤕
  • arrow.r.twohead.struck: ⤀
  • arrow.r.twohead.dstruck: ⤁
  • arrow.r.twohead.tail: ⤖
  • arrow.r.twohead.tail.struck: ⤗
  • arrow.r.twohead.tail.dstruck: ⤘
  • arrow.r.open: ⇾
  • arrow.l.double.struck: ⤂
  • arrow.l.struck: ⇷
  • arrow.l.dstruck: ⇺
  • arrow.l.tail.struck: ⬹
  • arrow.l.tail.dstruck: ⬺
  • arrow.l.twohead.struck: ⬴
  • arrow.l.twohead.dstruck: ⬵
  • arrow.l.twohead.tail: ⬻
  • arrow.l.twohead.tail.struck: ⬼
  • arrow.l.twohead.tail.dstruck: ⬽
  • arrow.t.struck: ⤉
  • arrow.t.dstruck: ⇞
  • arrow.b.struck: ⤈
  • arrow.b.dstruck: ⇟
  • arrow.l.r.double.struck: ⤄
  • arrow.l.r.struck: ⇹
  • arrow.l.r.dstruck: ⇼
  • arrow.l.open: ⇽
  • arrow.l.r.open: ⇿

• Delimiters

  • bracket.l.tick.t: ⦍
  • bracket.l.tick.b: ⦏
  • bracket.r.tick.t: ⦐
  • bracket.r.tick.b: ⦎
  • paren.l.flat: ⟮
  • paren.r.flat: ⟯
  • paren.l.closed: ⦇
  • paren.r.closed: ⦈
  • shell.l.filled: ⦗
  • shell.r.filled: ⦘
  • chevron.l.closed: ⦉
  • chevron.r.closed: ⦊
  • corner.l.t: ⌜
  • corner.l.b: ⌞
  • corner.r.t: ⌝
  • corner.r.b: ⌟
  • bag.l: ⟅
  • bag.r: ⟆
  • mustache.l: ⎰
  • mustache.r: ⎱

• Punctuation

  • comma.inv: ⸲
  • comma.rev: ⹁
  • interrobang.inv: ⸘
  • semi.inv: ⸵
  • slash.o: ⊘
  • ast.op.o: ⊛
  • dot.o: ⊙
  • dot.o.big: ⨀
  • colon.currency: ₡
  • permyriad: ‱

• Arithmetic

  • plus.o: ⊕
  • plus.o.arrow: ⟴
  • plus.o.big: ⨁
  • plus.o.l: ⨭
  • plus.o.r: ⨮
  • minus.o: ⊖
  • div.o: ⨸
  • div.slanted.o: ⦼
  • times.o: ⊗
  • times.o.big: ⨂
  • times.o.l: ⨴
  • times.o.r: ⨵
  • times.o.hat: ⨶

• Function and category theory

  • compose.o: ⊚
  • convolve.o: ⊛

• Geometry

  • angle.obtuse: ⦦
  • angle.azimuth: ⍼
  • angle.right.arc.dot: ⦝
  • angzarr: ⍼

• Shapes

  • bullet.op: ∙
  • bullet.o: ⦿
  • bullet.stroked: ◦
  • bullet.stroked.o: ⦾
  • bullet.hole: ◘
  • bullet.hyph: ⁃
  • bullet.tri: ‣
  • bullet.l: ⁌
  • bullet.r: ⁍

• Miscellaneous

  • cc: 🅭
  • cc.by: 🅯
  • cc.nc: 🄏
  • cc.nd: ⊜
  • cc.public: 🅮
  • cc.sa: 🄎
  • cc.zero: 🄍

• Currency

  • afghani: ؋
  • baht: ฿
  • cedi: ₵
  • cent: ¢
  • currency: ¤
  • dong: ₫
  • dorome: ߾
  • dram: ֏
  • guarani: ₲
  • hryvnia: ₴
  • kip: ₭
  • lari: ₾
  • manat: ₼
  • naira: ₦
  • pataca: $
  • riel: ៛
  • peso.philippine: ₱
  • rupee.indian: ₹
  • rupee.generic: ₨
  • rupee.tamil: ௹
  • rupee.wancho: 𞋿
  • shekel: ₪
  • som: ⃀
  • taka: ৳
  • taman: ߿
  • tenge: ₸
  • togrog: ₮
  • yuan: ¥

• Miscellaneous Technical

  • smile: ⌣
  • frown: ⌢
  • power.standby: ⏻
  • power.on: ⏽
  • power.off: ⭘
  • power.on.off: ⏼
  • power.sleep: ⏾

• Cyrillic

  • sha: ш
  • Sha: Ш

• Greek

  • digamma: ϝ
  • epsilon.alt.rev: ϶
  • iota.inv: ℩
  • Digamma: Ϝ
  • Theta.alt: ϴ

• Astronomical

  • earth: 🜨
  • earth.alt: ♁
  • jupiter: ♃
  • mars: ♂
  • mercury: ☿
  • neptune: ♆
  • neptune.alt: ⯉
  • saturn: ♄
  • sun: ☉
  • uranus: ⛢
  • uranus.alt: ♅
  • venus: ♀

• Gender

  • gender.female: ♀
  • gender.female.double: ⚢
  • gender.female.male: ⚤
  • gender.intersex: ⚥
  • gender.male: ♂
  • gender.male.double: ⚣
  • gender.male.female: ⚤
  • gender.male.stroke: ⚦
  • gender.male.stroke.t: ⚨
  • gender.male.stroke.r: ⚩
  • gender.neuter: ⚲
  • gender.trans: ⚧

New in emoji

• donkey: 🫏
• face.shaking: 🫨
• faith.khanda: 🪯
• flower.hyacinth: 🪻
• flute: 🪈
• ginger: 🫚
• goose: 🪿
• hairpick: 🪮
• hand.pushing.l: 🫷
• hand.pushing.r: 🫸
• handfan: 🪭
• heart.gray: 🩶
• heart.lightblue: 🩵
• heart.pink: 🩷
• jellyfish: 🪼
• maracas: 🪇
• moose: 🫎
• peapod: 🫛
• wing: 🪽
• wireless: 🛜
• dancing.bunny.men: 👯‍♂
• dancing.bunny.women: 👯‍♀

Deprecated

• Hebrew

  • alef, use aleph instead
  • bet, use beth instead
  • gimmel, use gimel instead
  • dalet, use daleth instead
  • shin, perhaps use sha instead

• CJK compatibility

  • ast.small, use ﹡ or \u{fe61} instead
  • plus.small, use ﹢ or \u{fe62} instead
  • eq.small, use ﹦ or \u{fe66} instead
  • gt.small, use ﹥ or \u{fe65} instead
  • lt.small, use ﹤ or \u{fe64} instead

• circle -> o for mathematical operators

  • bar.v.circle, use bar.v.o instead
  • ast.circle, use convolve.o or ast.op.o instead
  • backslash.circle, use backslash.o instead
  • dash.circle, use dash.o instead
  • dot.circle, use dot.o instead
  • dot.circle.big, use dot.o.big instead
  • plus.circle, use plus.o instead
  • plus.circle.arrow, use plus.o.arrow instead
  • plus.circle.big, use plus.o.big instead
  • minus.circle, use minus.o instead
  • div.circle, use div.o instead
  • times.circle, use times.o instead
  • times.circle.big, use times.o.big instead
  • eq.circle, use eq.o instead
  • gt.circle, use gt.o instead
  • lt.circle, use lt.o instead
  • parallel.circle, use parallel.o instead
  • perp.circle, use perp.o instead
  • circle.nested, use compose.o instead

• angle -> chevron

  • angle.l and angle.r to chevron.l and chevron.r, respectively
  • quote.angle to quote.chevron

• double -> stroked for double-struck delimiters

  • paren.double, use paren.stroked instead
  • bracket.double, use bracket.stroked instead
  • shell.double, use shell.stroked instead

• Other

  • diff, use partial instead
  • angle.spheric.top, use angle.spheric.t instead
  • angle.right.sq, use angle.right.square instead
  • planck.reduce, use planck instead
  • angle.oblique, use angle.obtuse instead
  • kai, use ϗ or \u{3d7} instead
  • Kai, use Ϗ or \u{3c5} instead
  • franc, because the symbol was never used in practice

Version 0.1.1 (February 5, 2025)

Brings back angstrom, but uses U+00C5 LATIN CAPITAL LETTER A WITH RING ABOVE, which is the one that should be used in place of the deprecated U+212B ANGSTROM SIGN.

Version 0.1.0 (February 4, 2025)

As this is the first release of codex, the symbol changes are relative to Typst 0.12.0.

• New
  • inter, inter.and, inter.big, inter.dot, inter.double, inter.sq, inter.sq.big, inter.sq.double, integral.inter
  • asymp, asymp.not
  • mapsto, mapsto.long
  • divides.not.rev, divides.struck
  • interleave, interleave.big, interleave.struck
  • eq.triple.not, eq.dots, eq.dots.down, eq.dots.up
  • smt, smt.eq, lat, lat.eq
  • colon.tri, colon.tri.op
  • dagger.triple, dagger.l, dagger.r, dagger.inv
  • hourglass.stroked, hourglass.filled
  • die.six, die.five, die.four, die.three, die.two, die.one
  • errorbar.square.stroked, errorbar.square.filled, errorbar.diamond.stroked, errorbar.diamond.filled, errorbar.circle.stroked, errorbar.circle.filled
  • numero
  • Omega.inv
• Renamed
  • ohm.inv to Omega.inv
• Changed codepoint
  • angle.l.double from 《 to ⟪
  • angle.r.double from 》 to ⟫
• Deprecated
  • sect and all its variants
  • integral.sect
• Removed
  • degree.c, degree.f, ohm, ohm.inv, angstrom, kelvin

Tip

You might want to read the official documentation first:

• Bibliography Function – Typst Documentation
• Cite Function – Typst Documentation

For most Typst users, only YAML format and changelog in this chapter might be relevant.

Besides, the installation method below requires a Rust toolchain. If you don’t have one, you can download unofficial pre-built binaries from Typst dev builds.

Note

The following is an unofficial copy of the file in Typst’s official repository as of 2025-12-27.

Hayagriva

Rusty bibliography management.

Hayagriva is a tool that can help you or your apps deal with literature and other media. Its features include:

• Data structures for literature collections
• Reading and writing said collections from YAML files
• Formatting literature into reference list entries and in-text citations as defined by popular style guides
• Interoperability with BibTeX
• Querying your literature items by type and available metadata

Hayagriva can be used both as a library and as a Command Line Interface (CLI). Skip to the section “Usage” for more information about usage in your application or to the section “Installation” to learn about how to install and use Hayagriva on your terminal.

Supported styles

Hayagriva supports all styles provided in the official Citation Style Language repository, currently over 2,600.

Usage

#![allow(unused)]
fn main() {
use hayagriva::io::from_yaml_str;

let yaml = r#"
crazy-rich:
    type: Book
    title: Crazy Rich Asians
    author: Kwan, Kevin
    date: 2014
    publisher: Anchor Books
    location: New York, NY, US
"#;

// Parse a bibliography
let bib = from_yaml_str(yaml).unwrap();
assert_eq!(bib.get("crazy-rich").unwrap().date().unwrap().year, 2014);

// Format the reference
use std::fs;
use hayagriva::{
    BibliographyDriver, BibliographyRequest, BufWriteFormat,
    CitationItem, CitationRequest,
};
use hayagriva::citationberg::{LocaleFile, IndependentStyle};

let en_locale = fs::read_to_string("tests/data/locales-en-US.xml").unwrap();
let locales = [LocaleFile::from_xml(&en_locale).unwrap().into()];

let style = fs::read_to_string("tests/data/art-history.csl").unwrap();
let style = IndependentStyle::from_xml(&style).unwrap();

let mut driver = BibliographyDriver::new();

for entry in bib.iter() {
    let items = vec![CitationItem::with_entry(entry)];
    driver.citation(CitationRequest::from_items(items, &style, &locales));
}

let result = driver.finish(BibliographyRequest {
    style: &style,
    locale: None,
    locale_files: &locales,
});

for cite in result.citations {
    println!("{}", cite.citation.to_string())
}
}

To format entries, you need to wrap them in a CitationRequest. Each of these can reference multiple entries in their respective CitationItems. Use these with a BibliographyDriver to obtain formatted citations and bibliographies.

You can either supply your own CSL files or choose from about 100 bundled citation styles using the archive feature.

If the default features are enabled, Hayagriva supports BibTeX and BibLaTeX bibliographies. You can use io::from_biblatex_str to parse such bibliographies.

Should you need more manual control, the library’s native Entry struct also offers an implementation of the From<&biblatex::Entry>-Trait. You will need to depend on the biblatex crate to obtain its Entry. Therefore, you could also use your BibLaTeX content like this:

#![allow(unused)]
fn main() {
use hayagriva::Entry;
let converted: Entry = your_biblatex_entry.into();
}

If you do not need BibLaTeX compatibility, you can use Hayagriva without the default features by writing this in your Cargo.toml:

[dependencies]
hayagriva = { version = "0.9", default-features = false }

Selectors

Hayagriva uses a custom selector language that enables you to filter bibliographies by type of media. For more information about selectors, refer to the selectors.md file. While you can parse user-defined selectors using the function Selector::parse, you may instead want to use the selector macro to avoid the run time cost of parsing a selector when working with constant selectors.

#![allow(unused)]
fn main() {
use hayagriva::select;
use hayagriva::io::from_yaml_str;

let yaml = r#"
quantized-vortex:
    type: Article
    author: Gross, E. P.
    title: Structure of a Quantized Vortex in Boson Systems
    date: 1961-05
    page-range: 454-477
    doi: 10.1007/BF02731494
    parent:
        issue: 3
        volume: 20
        title: Il Nuovo Cimento
"#;

let entries = from_yaml_str(yaml).unwrap();
let journal = select!((Article["date"]) > ("journal":Periodical));
assert!(journal.matches(entries.nth(0).unwrap()));
}

There are two ways to check if a selector matches an entry. You should use [Selector::matches] if you just want to know if an item matches a selector and [Selector::apply] to continue to work with the data from parents of a matching entry. Keep in mind that the latter function will return Some even if no sub-entry was bound / if the hash map is empty.

Installation

Run this in your terminal:

cargo install hayagriva --features cli

Cargo will install the Hayagriva Command Line Interface for you. Now, you just need a Hayagriva YAML literature file or a Bib(La)TeX file to get started. The Hayagriva YAML file is intuitive to write and can represent a wealth of media types, learn how to write one in its dedicated documentation.

Suppose you have this file saved as literature.yaml in your current working directory:

dependence:
    type: Article
    title: The program dependence graph and its use in optimization
    author: ["Ferrante, Jeanne", "Ottenstein, Karl J.", "Warren, Joe D."]
    date: 1987-07
    serial-number:
        doi: "10.1145/24039.24041"
    parent:
        type: Periodical
        title: ACM Transactions on Programming Languages and Systems
        volume: 9
        issue: 3

feminism:
    type: Article
    title: She swoons to conquer
    author: Ungard-Sargon, Batya
    editor: Weintraub, Pam
    date: 2015-09-25
    url: https://aeon.co/essays/can-you-enjoy-romance-fiction-and-be-a-feminist
    parent:
        type: Blog
        title: Aeon

You can then issue the following command to get reference list entries for both of these articles.

hayagriva literature.yaml reference

Hayagriva defaults to the Author-Date style of the Chicago Manual of Style (17th edition). If you prefer to use another style, you can, for example, do the following to use the style of the American Psychological Association instead:

hayagriva literature.yaml reference --style apa

Available values for the --style argument can be viewed by calling hayagriva help reference.

If you now need an in-text citation to the second article in the above file, you can call:

hayagriva literature.yaml cite --key feminism

The --key takes a comma-separated list of keys (or a single one). The sub-command will then only work on the specified keys. Just like the reference sub-command, the cite command also allows the --style argument. Its possible values can be viewed with hayagriva help cite. It will default to the Author Date style.

Instead of the --key argument, you can also use --select to provide a custom Hayagriva selector. For example, you could run the following to only reference entries that have a URL or DOI at the top level:

hayagriva literature.yaml --select "*[url] | *[doi]" reference

This expression would match both entries in our example and therefore the command would return the same result as the first reference command.

Hayagriva also allows you to explore which values were bound to which sub-entries if the selector matches. This is especially useful if you intend to consume Hayagriva as a dependency in your application and need to debug an expression. Consider this selector which always binds the sub-entry with the volume field to a, regardless of if it occurred at the top level or in the first parent: a:*[volume] | * > a:[volume]. You can then use the command below to show which sub-entry the selector bound as a for each match:

hayagriva literature.yaml --select "a:*[volume] | * > a:[volume]" --show-bound

The --show-bound flag shows all keys matching the selector or key filter and details which sub-entries of each entry were bound by the selector. If, instead, you only want to obtain a list of matching keys, use the --keys flag.

If you are working with BibTeX, you can use your .bib file with Hayagriva just like you would use a .yaml/.yml file. If you want to convert your .bib file to a .yaml file, you can simply pass the .bib file to the CLI without any additional arguments. It will then show the YAML-formatted bibliography with key and selector filters applied on standard output. If you therefore want to convert your .bib file and save the result somewhere, you can just use >:

hayagriva literature.bib > converted.yaml

Contributing

We are looking forward to receiving your bugs and feature requests in the Issues tab. We would also be very happy to accept PRs for bug fixes, minor refactorings, features that were requested in the issues and greenlit by us, as well as the planned features listed below:

• Implementing the YAML-to-BibLaTeX conversion
• Documentation improvements
• CSL bugfixes
• CSL-M Support

We wish to thank each and every prospective contributor for the effort you (plan to) invest in this project and for adopting it!

License

Hayagriva is licensed under a MIT / Apache 2.0 dual license.

Users and consumers of the library may choose which of those licenses they want to apply whereas contributors have to accept that their code is in compliance and distributed under the terms of both of these licenses.

Hayagriva includes CSL styles that are licensed as CC-BY-SA 3.0 Deed if the archive feature is enabled. The file styles.cbor.rkyv is a collection of these works and falls under this license. Retrieve attribution information by deserializing it using the styles function and reading the StyleInfo structs.

Note

The following is an unofficial copy of the file in Typst’s official repository as of 2025-12-27.

The Hayagriva YAML File Format

The Hayagriva YAML file format enables you to feed a collection of literature items into Hayagriva. It is built on the YAML standard. This documentation starts with a basic introduction with examples into the format, explains how to represent several types of literature with parents, and then explores all the possible fields and data types. An example file covering many potential use cases can be found in the test directory of the repository.

Overview

In technical terms, a Hayagriva file is a YAML document that contains a single mapping of mappings. Or, in simpler terms: Every literature item needs to be identifiable by some name (the key) and have some properties that describe it (the fields). Suppose a file like this:

harry:
    type: Book
    title: Harry Potter and the Order of the Phoenix
    author: Rowling, J. K.
    volume: 5
    page-total: 768
    date: 2003-06-21

electronic:
    type: Web
    title: Ishkur's Guide to Electronic Music
    serial-number: v2.5
    author: Ishkur
    url: http://www.techno.org/electronic-music-guide/

You can see that it refers to two items: The fifth volume of the Harry Potter books (key: harry) and a web page called “Ishkur’s Guide to Electronic Music” (key: electronic). The key always comes first and is followed by a colon. Below the key, indented, you can find one field on each line: They start with the field name, then a colon, and then the field value.

Sometimes, this value can be more complex than just some text after the colon. If you have an article that was authored by multiple people, its author field can look like this instead:

author: ["Omarova, Saule", "Steele, Graham"]

Or it could also be this:

author:
    - Omarova, Saule
    - Steele, Graham

The author field can be an array (a list of values) to account for media with more than one creator. YAML has two ways to represent these lists: The former, compact, way where you wrap your list in square braces and the latter, more verbose way where you put each author on their own indented line and precede them with a hyphen so that it looks like a bullet list. Since in the compact form both list items and authors’ first and last names are separated by commas you have to wrap the names of individual authors in double-quotes.

Sometimes, fields accept composite data. If, for example, you would want to save an access date for an URL for your bibliography, you would need the url field to accept that. This is accomplished like this:

url:
    value: http://www.techno.org/electronic-music-guide/
    date: 2020-11-30

There is also a more compact form of this that might look familiar if you know JSON:

url: { value: http://www.techno.org/electronic-music-guide/, date: 2020-11-30 }

By now, you must surely think that there must be an abundance of fields to represent all the possible information that could be attached to any piece of literature: For example, an article could have been published in an anthology whose title you would want to save, and that anthology belongs to a series that has a title itself… For this, you would already need three different title-fields? Hayagriva’s data model was engineered to prevent this kind of field bloat, read the next section to learn how to represent various literature.

Representing publication circumstance with parents

Hayagriva aims to keep the number of fields it uses small to make the format easier to memorize and therefore write without consulting the documentation. Other contemporary literature management file formats like RIS and BibLaTeX use many fields to account for every kind of information that could be attached to some piece of media.

We instead use the concept of parents: Many pieces of literature are published within other media (e. g. articles can appear in newspapers, blogs, periodicals, …), and when each of these items is regarded isolatedly and without consideration for that publication hierarchy, there are substantially fewer fields that could apply.

How does this look in practice? An article in a scientific journal could look like this:

kinetics:
    type: Article
    title: Kinetics and luminescence of the excitations of a nonequilibrium polariton condensate
    author: ["Doan, T. D.", "Tran Thoai, D. B.", "Haug, Hartmut"]
    serial-number:
        doi: "10.1103/PhysRevB.102.165126"
    page-range: 165126-165139
    date: 2020-10-14
    parent:
        type: Periodical
        title: Physical Review B
        volume: 102
        issue: 16
        publisher: American Physical Society

This means that the article was published in issue 16, volume 102 of the journal “Physical Review B”. Notice that the title field is in use for both the article and its parent - every field is available for both top-level use and all parents.

To specify parent information, write the parent field name and a colon and then put all fields for that parent on indented lines below.

The line type: Periodical could also have been omitted since each entry type has the notion of a default parent type, which is the type that the parents will have if they do not have a type field.

Sometimes, media is published in multiple ways, i. e. one parent would not provide the full picture. Multiple parents are possible to deal with these cases:

wwdc-network:
    type: Article
    author:  ["Mehta, Jiten", "Kinnear, Eric"]
    title: Boost Performance and Security with Modern Networking
    date: 2020-06-26
    parent:
        - type: Conference
          title: World Wide Developer Conference 2020
          organization: Apple Inc.
          location: Mountain View, CA
        - type: Video
          runtime: "00:13:42"
          url: https://developer.apple.com/videos/play/wwdc2020/10111/

This entry describes a talk presented at a conference and for which a video is available from which the information was ultimately cited.

Just like the author field, parents can be a list. If it does, a hyphen indicates the start of a new parent.

Parents can also appear as standalone items and can have parents themselves. This is useful if you are working with articles from a journal that belongs to a series or cases like the one below:

plaque:
    type: Misc
    title: Informational plaque about Jacoby's 1967 photos
    publisher:
        name: Stiftung Reinbeckhallen
        location: Berlin, Germany
    date: 2020
    parent:
        type: Artwork
        date: 1967
        author: Jacoby, Max
        parent:
            type: Anthology
            title: Bleibtreustraße
            archive: Landesmuseum Koblenz
            archive-location: Koblenz, Germany

This plaque was created by a museum for a photo by Jacoby that belongs to a series that is usually archived at a different museum.

Reference

This section lists all possible fields and data types for them.

Fields

type

title

author

date

parent

parent:
    type: Anthology
    title: Automata studies
    editor: [“Shannon, C. E.”, “McCarthy, J.”]

abstract

genre

editor

editor:
    - Stringer, Gary A.
    - Pebworth, Ted-Larry

affiliated

affiliated:
    - role: Director
      names: Cameron, James
    - role: CastMember
      names: [“Schwarzenegger, Arnold”, “Hamilton, Linda”, “Patrick, Robert”]

call-number

publisher

publisher: Penguin Books

publisher:
    name: Penguin Books
    location: London

location

organization

issue

volume

volume-total

chapter

edition

page-range

page-total

time-range

runtime

url

serial-number

serial-number:
    doi: “10.22541/au.148771883.35456290”
    arxiv: “1906.00356”
    serial: “8516”

language

archive

archive-location

note

Data types

Entry

Entries are collections of fields that could either have a key or be contained in the parent field of another entry.

Entry Type

Needs a keyword with one of the following values:

• article. A short text, possibly of journalistic or scientific nature, appearing in some greater publication (default parent: periodical).
• chapter. A section of a greater containing work (default parent: book).
• entry. A short segment of media on some subject matter. Could appear in a work of reference or a data set (default parent: reference).
• anthos. Text published within an Anthology (default parent: anthology).
• report. A document compiled by authors that may be affiliated to an organization. Presents information for a specific audience or purpose.
• thesis. Scholarly work delivered to fulfill degree requirements at a higher education institution.
• web. Piece of content that can be found on the internet and is native to the medium, like an animation, a web app, or a form of content not found elsewhere. Do not use this entry type when referencing a textual blog article, instead use an article with a blog parent (default parent: web).
• scene. A part of a show or another type of performed media, typically all taking place in the same location (default parent: video).
• artwork. A form of artistic/creative expression (default parent: exhibition).
• patent. A technical document deposited at a government agency that describes an invention to legally limit the rights of reproduction to the inventors.
• case. Reference to a legal case that was or is to be heard at a court of law.
• newspaper. The issue of a newspaper that was published on a given day.
• legislation. Legal document or draft thereof that is, is to be, or was to be enacted into binding law (default parent: anthology).
• manuscript. Written document that is submitted as a candidate for publication.
• original. The original container of the entry before it was re-published.
• post. A post on a micro-blogging platform like Twitter (default parent: post).
• misc. Items that do not match any of the other Entry type composites.
• performance. A live artistic performance.
• periodical. A publication that periodically publishes issues with unique content. This includes scientific journals and news magazines.
• proceedings. The official published record of the events at a professional conference.
• book. Long-form work published physically as a set of bound sheets.
• blog. Set of self-published articles on a website.
• reference. A work of reference. This could be a manual or a dictionary.
• conference. Professional conference. This Entry type implies that the item referenced has been an event at the conference itself. If you instead want to reference a paper published in the published proceedings of the conference, use an article with a proceedings parent.
• anthology. Collection of different texts on a single topic/theme.
• repository. Publicly visible storage of the source code for a particular software, papers, or other data and its modifications over time.
• thread. Written discussion on the internet triggered by an original post. Could be on a forum, social network, or Q&A site.
• video. Motion picture of any form, possibly with accompanying audio (default parent: video).
• audio. Recorded audible sound of any kind (default parent: audio).
• exhibition. A curated set of artworks.

The field is case insensitive. It defaults to Misc or the default parent if the entry appears as a parent of an entry that defines a default parent.

Formattable String

A formattable string is a string that may run through a text case transformer when used in a reference or citation. You can disable these transformations on segments of the string or the whole string.

The simplest scenario for a formattable string is to provide a string that can be case-folded:

publisher: UN World Food Programme

If you want to preserve a part of the string but want to go with the style’s behavior otherwise, enclose the string in braces like below. You must wrap the whole string in quotes if you do this.

publisher: "{imagiNary} Publishing"

To disable formatting altogether and instead preserve the casing as it appears in the source string, put the string in the value sub-field and specify another sub-field as verbatim: true:

publisher:
    value: UN World Food Programme
    verbatim: true

Title and sentence case folding will always be deactivated if your item has set the language key to something other than English.

You can also include mathematical markup evaluated by Typst by wrapping it in dollars.

Furthermore, every formattable string can include a short form that a citation style can choose to render over the longer form.

journal:
    value: International Proceedings of Customs
    short: Int. Proc. Customs

Person

A person consists of a name and optionally, a given name, a prefix, and a suffix for the (family) name as well as an alias. Usually, you specify a person as a string with the prefix and the last name first, then a comma, followed by a given name, another comma, and then finally the suffix. Following items are valid persons:

• Doe, Janet
• Luther King, Martin, Jr.
• UNICEF
• von der Leyen, Ursula

The prefix and the last name will be separated automatically using the same algorithm as BibTeX (p. 24) which can be summarized as “put all the consecutive lower case words at the start into the prefix.”

Usually, this is all you need to specify a person’s name. However, if a part of a name contains a comma, the prefix is not lowercased, or if one needs to specify an alias, the person can also be specified using sub-fields:

author:
    given-name: Gloria Jean
    name: Watkins
    alias: bell hooks

The available sub-fields are name, given-name, prefix, suffix, and alias. The name field is required.

List of persons with role

This data type requires a mapping with two fields: names which contains a list of persons or a single person and a role which specifies their role with the item:

role: ExecutiveProducer
names: ["Simon, David", "Colesberry, Robert F.", "Noble, Nina Kostroff"]

Possible role values

• translator. Translated the work from a foreign language to the cited edition.
• afterword. Authored an afterword.
• foreword. Authored a foreword.
• introduction. Authored an introduction.
• annotator. Provided value-adding annotations.
• commentator. Commented on the work.
• holder. Holds a patent or similar.
• compiler. Compiled the works in an Anthology.
• founder. Founded the publication.
• collaborator. Collaborated on the cited item.
• organizer. Organized the creation of the cited item.
• cast-member. Performed in the cited item.
• composer. Composed all or parts of the cited item’s musical/audible components.
• producer. Produced the cited item.
• executive-producer. Lead Producer for the cited item.
• writer. Did the writing for the cited item.
• cinematography. Shot film/video for the cited item.
• director. Directed the cited item.
• illustrator. Illustrated the cited item.
• narrator. Provided narration or voice-over for the cited item.

The role field is case insensitive.

Date

A calendar date as ISO 8601. This means that you specify the full date as YYYY-MM-DD with an optional sign in front to represent years earlier than 0000 in the Gregorian calendar. The year 1 B.C.E. is represented as 0000, the year 2 B.C.E. as -0001 and so forth.

The shortened forms YYYY or YYYY-MM are also possible.

Timestamp

A timestamp represents some time in a piece of media. It is given as a string of the form DD:HH:MM:SS,msms but everything except MM:SS can be omitted. Wrapping the string in double-quotes is necessary due to the colons.

The left-most time denomination only allows values that could overflow into the next-largest denomination if that is not specified. This means that the timestamp 138:00 is allowed for 2 hours and 18 minutes, but 01:78:00 is not.

Timestamp range

A range of timestamps is a string containing two timestamps separated by a hyphen. The first timestamp in the string indicates the starting point, whereas the second one indicates the end. Wrapping the string in double-quotes is necessary due to the colons in the timestamps.

time-range: "03:35:21-03:58:46"

String

Strings are sequences of characters as a field value. In most cases you can write your string after the colon, but if it contains a special character (:, {, }, [, ], ,, &, *, #, ?, |, -, <, >, =, !, %, @, \) it should be wrapped with double-quotes. If your string contains double-quotes, you can write those as this escape sequence: \". If you instead wrap your string in single quotes, most YAML escape sequences such as \n for a line break will be ignored.

Numeric

Numeric variables are one or more numbers that are delimited by commas, ampersands, and hyphens. Numeric variables can express a single number or a range and contain only integers, but may contain negative numbers. Numeric variables can have a non-numeric prefix and suffix.

page-range: S10-15

Unicode Language Identifier

A Unicode Language Identifier identifies a language or its variants. At the simplest, you can specify an all-lowercase two-letter ISO 639-1 code like en or es as a language. It is possible to specify regions, scripts, or variants to more precisely identify a variety of a language, especially in cases where the ISO 639-1 code is considered a “macrolanguage” (zh includes both Cantonese and Mandarin). In such cases, specify values like en-US for American English or zh-Hans-CN for Mandarin written in simplified script in mainland China. The region tags have to be written in all-caps and are mostly corresponding to ISO 3166-1 alpha_2 codes.

Consult the documentation of the Rust crate unic-langid we use for parsing these language identifiers for more information.

Tip

This page is only relevant if you are using the hayagriva CLI or library.

Note

The following is an unofficial copy of the file in Typst’s official repository as of 2025-12-27.

Selectors

As you have seen in the Readme and the file format documentation, a Hayagriva entry not only has a type but also parents that can have their own type. With this architecture, differentiation between articles from blogs, newspapers, and conference proceedings is easy without having a dedicated type for each of them!

However, this also means that you cannot just match on the top-level type of an entry to make all the distinctions that you or your citation and reference styles may require.

Enter selectors: They provide a convenient way to query entries by structure and retrieve parents that hold crucial information for your use case.

Two ways of macro usage are offered: Either as a string (used on the command line) or, if you are depending on Hayagriva as a library, with the select! macro. Library users can parse string selectors using Selector::parse. The Readme explains the fundamental differences between the two formats. If there are divergences between both forms, we will provide both variants as examples.

Entry type selector

The most basic selectors are entry types; they will match any entry that has the same top-level type:

This works with any of the entry types. Be aware that you have to capitalize exactly like in the EntryType struct variants when using the macro. The string selectors are case-insensitive.

Wildcard

There is also a wildcard selector that applies to every entry:

*

This might seem pointless on its own but is quite useful in conjunction with other selector constructs.

Required fields

Sometimes you want to filter for entries that have certain fields set. This can be accomplished with the fields selector. Attach square brackets to a selector and put the fields you want to be set inside, separated by commas. All specified fields have to contain some value for the selector to match.

This example finds all artworks with a known archive (including its location). The macro needs the attributes to be strings.

Negation

The exclamation mark allows you to select everything that does not match the following selector.

Disjunction

The disjunction operator | allows you to offer multiple alternative selectors, only one of which has to be matched for the whole construction to match. Think about it as an ‘or.’

Either an anthology or anything with a volume field.

Matches every video, audio, and web (with runtime field) entry, given that it has the affiliated field set.

Ancestrage

Require that a parent has to match some selector with the > operator. The conditions to its left have to apply for the top-level, the selector on the right side must match any of the parents. The operator can also be chained to examine nested parents.

This selector finds published conference articles.

This selects a chapter in a monograph (a long-form text on a subject published in another book).

Bindings

Less interesting for CLI users.

Once you know that a matching entry has some parents, you might need to access their fields. You can be sure you got the right parent with bindings. Create a binding using the : operator. To the left of the selector, you provide a name which you can freely choose. The parent (or the top-level entry) that matches the selector to the right will then appear in the resulting map under the key that you have chosen.

The binding name has to be a string for macro use. This binds the blog or newspaper parent of an article to ‘parent’ if the selector matches. It is possible to write selectors that only sometimes bind a variable if it matches. You could reformulate the right part of the above selector as (parent:blog | newspaper), then it would not bind ‘parent’ if the selector matches with a newspaper-type parent.

Note that all bindings within a negation are discarded.

Require multiple parents

Sometimes, a single parent does not provide the full picture. For example, a dataset (type repository) could be both published on the web and presented in a paper, so it would have a web and an article parent (with the latter possibly having an periodical or proceedings parent). To capture such entries with selectors, we need to define multiple conditions for parents, that all must be satisfied. This can be done using the &-operator. The operator may only be used to the right of an ancestrage operator.

This selector matches conference talks published as a video.

Note

The following is an unofficial copy of the file in Typst’s official repository as of 2025-12-27.

0.9.1

• Export the TransparentLocator struct so LocatorPayload::Transparent can be constructed (#397)
• Fixes the location conditional in CSL styles for citations with no locator (#399)
• Fix a bug where accessing year suffix resulted in wrong CSL renders (#400)

0.9.0

• Add chapter field corresponding to CSL chapter-number and BibLaTeX chapter (#361, #383)
• Support locator/supplement in alphanumeric style, also clean it up (#298, #307, #353)
• Support BibLaTeX language field (#317)
• Support date seasons, which are displayed when the month is missing (#391)
• Improve translation of BibLaTeX fields to genre and serial-number (#296, #369)
• Breaking change: Allow differentiating custom locators/supplements for styles that handle repeated locators. Due to this change, LocatorPayload::Transparent now contains a TransparentLocator (#299)
• Breaking change: The types CitationRequest, CitationItem, SpecificLocator and LocatorPayload no longer derive Hash and Eq. That also removes some automatically derived traits.
• Breaking change: Updated biblatex to version 0.11.0
• Update most archived CSL styles and locales
  • Breaking change: Styles chicago-fullnotes and modern-humanities-research-association were renamed to chicago-notes and modern-humanities-research-association-notes, and the old names are now deprecated, but still available. ArchivedStyle::ChicagoFullnotes and ArchivedStyle::ModernHumanitiesResearchAssociation were removed and the discriminant of ArchivedStyle::ChicagoNotes has changed. (#350, #372, #389)
• Fixes and improvements to BibLaTeX parsing (#388)
  • Support % comment syntax, as well as top-level @comment{}
  • Allow omitting editor for @InProceedings
• Fix regression where page variables were no longer supported in styles’ <number> elements (#289)
• Fix handling of ibid-with-locator and ibid positions in styles (#301)
• Fix sorting and formatting of name parts (#287, #313)
• Correctly use terms for “AD” and “BC” from chosen locale (#364)
• Fix year suffix collapsing (#367)
• Fix delimiters in locale-specific date formatting (#385)
• Fix rendering of date ordinals (#366)
• Fix rendering and sorting of dates with BC years (#334, #368)
• Fix sorting for empty sort values (#390)

0.8.1

• Use editor names in prose and author-only citations if the author names are unavailable
• Recognize some non-standard but widely used BibLaTeX editortypes like producer, writer, scriptwriter, and none (defined by widespread style biblatex-chicago to mean performers within music and video entries)
• Allow CSL styles to render affixes around the bibliography
• Correctly process the PubMed ID for BibTeX entries with eprinttype = {pubmed}
• Fix bugs around the handling of CSL delimiting characters (#109, #180)
• Whitespace handling for the strings delimiting initialized names has been improved
• Fix problem with parsing multibyte characters in page ranges that could prevent Hayagriva from parsing some BibTeX page ranges (#241)
• Uppercase spelling after apostrophes used as quotation marks is now possible
• Fix a panic with the CLI’s --format argument
• Updated CSL APA style
• Updated CSL locales for Finnish, Swiss German, Austrian German, German, and Arabic

0.8.0

• Breaking change: Fixed deserialization of page ranges, removing From<u64> for PageRanges
• Added support for disambiguation to alphanumeric citation style
• Raised limit for disambiguation resolving in complex cases
• The year 0 will now render as 1BC for CSL

0.7.0

• Breaking change: Entry::page_range now returns Option<&MaybeTyped<PageRanges>> instead of Option<&PageRanges>. This fixes a panic that occurred when a page range had an unknown format
• MaybeTyped now has an as_typed method

0.6.0

• Breaking change: Fix that the page range labels were not pluralized, NumericValue::Range now returns an inclusive range (#142)
• Breaking change: The field publisher can now accept a dictionary with a location. The top-level location key is now primarily for event and item locations.
• Breaking change: The field annote has been removed
• Allow multiple page ranges with prefixes and suffixes
• Fixes with sorting bibliography entries
• Fix sorting citations by their number (#115)
• Fix how citation number ranges collapse (#154)
• BibliographyItem is now exported (#157)
• Fix when the short form of a title was used (#173)
• Bumped the biblatex crate to 0.10.0 to fix a BibLaTeX parsing bug (https://github.com/typst/biblatex/issues/53) and allow the Unknown and Director editor types (https://github.com/typst/biblatex/issues/52).

We also updated our collection of Citation Styles.

0.5.3

• Fixed a bug with initials (#150)
• Fixed suppression of title when no author was provided (#144)
• Fixed et al handling on subsequent citations by bumping citationberg

0.5.2

• Allow the abstract, annote, and genre fields to Hayagriva files and process them from BibTeX files.
• Fix retrieval of an item’s editor (#94)
• Fixed issue with pulling punctuation into quotation marks (#85)
• Allow non-range values in the pages field (#103)
• Fix multiple subsequent prose citations to the same item (#122)
• Interpret the eprint BibTeX key as serial-number.arxiv if the eprinttype is set to arxiv
• Fixed issue with multiple subsequent citations (#122)
• Improved handling of empty CSL objects

0.5.1

• Fixed spacing around math blocks
• Fixed title case formatting next to {verbatim} blocks and apostrophes

0.5.0

• Breaking change: The API for archived styles has changed.
• Breaking change: The name of the GB/T 7714 family of styles have been corrected to gb-7714-... from gb-7114-....
• Breaking change: The reexported TypeErrorKind and ParseErrorKind enums in biblatex have added variants and become non-exhaustive.
• Date parsing will not panic anymore (https://github.com/typst/typst/issues/2553).
• Anthos entries now properly recognize their parent (#72, https://github.com/typst/typst/issues/2572). Thanks, @zepinglee!
• Proceedings titles will now be printed correctly (#78). Thanks, @vtta!
• Citation numbers will now collapse if the style requests it.
• Escaping in format and chunked strings now works (https://github.com/typst/typst/issues/2669).
• The old behavior of the alphanumeric style has been restored.
• Bibliographies now forcibly print the alphanumeric citation-label instead of the citation-number if the cite only printed the former (and vice-versa; https://github.com/typst/typst/issues/2707).
• We dropped the dependency on rkyv in favor of code generation in a test. This should resolve build problems on some platforms.
• The retrieval of the volume variable is now more robust (#82). Thanks, @mpmdean!
• Fixed delimiter order for contributors (#73). Thanks, @zepinglee!
• Page ranges can now be strings (#83).
• Page ranges will now use the correct delimiter, even if printed with cs:text
• Fixed a bug with the suppression of empty groups (https://github.com/typst/typst/issues/2548).
• Bumped citationberg to solve a CSL locale fallback issue that affected https://github.com/typst/typst/issues/2548
• Bumped the biblatex crate to 0.9.0 to fix BibLaTeX parsing bugs (e.g. https://github.com/typst/biblatex/issues/41, https://github.com/typst/biblatex/issues/33, https://github.com/typst/biblatex/issues/40, https://github.com/typst/typst/issues/2751, #81)

0.4.0

Breaking changes:

Hayagriva now uses the Citation Style Language to encode formatting styles. This means that Hayagriva’s own formatting styles have been deprecated.

For users:

• The YAML input format has changed.
  • Titles and formattable strings have been merged into one type. All formattable strings can have a shorthand now.
  • Formattable Strings do not have title-case and sentence-case keys anymore. shorthand has been renamed to short. To prevent changes of the text case of formattable strings, you can use braces. Enclose a part of a formattable string (or short) in {braces} to print it as-is.
  • The fields doi, isbn, and issn have been moved to serial-number which can now be a dictionary containing these and arbitrary other serial numbers like a pmid (PubMed ID) and arxiv (ArXiv Identifier).
  • The tweet entry type has been renamed to post.
  • All numeric variables can now also contains strings. Numbers can have string affixes.

Refer to the updated file format docs for examples.

For developers:

• To use a CSL style, you can either supply a CSL file or use an archive of provided styles with the archive feature.
• The from_yaml_str function will now return the new Library struct, with the entries within.
• The Database struct has been replaced by the easier to handle BibliographyDriver.
• We switched from yaml_rust to serde_yaml. The Entry now implements serde’s Serialize and Deserialize traits. Hence, the from_yaml and to_yaml functions have been deleted.
• Brackets are no longer individually overridable. Instead, use the new CitePurpose.
• Entry::kind has been renamed to Entry::entry_type.
  • The citation styles AuthorTitle and Keys have been removed but can be realized with CSL.

This release fixes many bugs and makes Hayagriva a serious contender for reference management.

Other changes

• We added the entry types Performance and Original.
• We added the field call-number.

0.3.2

Fixes a title case formatting bug introduced in the previous release.

0.3.1

Bug Fixes:

• Added an option to turn off abbreviation of journals (thanks to @CMDJojo)
• Fixed bugs with title case formatting (thanks to @jmskov)
• Fixed off-by-one error with dates in APA style (thanks to @bluebear94)
• Fixed supplements in the Alphanumeric and AuthorTitle styles (thanks to @lynn)
• Fixed bugs with sentence case formatting
• Fixed verbatim option
• Fixed terminal formatting
• Fixed some typos (thanks to @kianmeng and @bluebear94)

0.3.0

Breaking:

• Updated to biblatex 0.8.0

Bug Fixes:

• Fixed string indexing for titles, removed panic
• More permissive BibLaTeX parsing

0.2.1

Bug Fixes:

• Fixed APA bibliography ordering

0.2.0

Breaking:

• Replaced NoHyphenation formatting with Link formatting
• Switched to newest BibLaTeX (which is part of the public API)

Bug Fixes:

• Fixed IEEE bibliography ordering
• Fixed A, B, C, … suffixes for Author Date citations
• Removed println calls

0.1.1

🐞 This release fixes the documentation of the CLI in the README.md file. ✨ There are new options for bracketed citations in the CLI. ✅ No breaking changes.

0.1.0

🎉 This is the initial release!

Tip

This chapter focuses on submitting packages.

If that’s not what you want:

• Visit Typst Universe to search and use existing packages.
• Read Scripting – Typst Documentation to learn how to develop a package.
• Read Tutorial – Typst Documentation to learn how to make a template.

Note

The following is an unofficial copy of the file in Typst’s official repository as of 2026-01-26.

Typst Packages

The package repository for Typst, where package authors submit their packages. The packages submitted here are available on Typst Universe.

Package format

A package is a collection of Typst files and assets that can be imported as a unit. A typst.toml manifest with metadata is required at the root of a package. Read more about the manifest format.

Published packages

This repository contains a collection of published packages. Due to its early and experimental nature, all packages in this repository are scoped in a preview namespace. A package that is stored in packages/preview/{name}/{version} in this repository will become available in Typst as #import "@preview/{name}:{version}". You must always specify the full package version.

You can use template packages to create new Typst projects with the CLI with the typst init command or the web application by clicking the Start from template button.

If you want to submit your own package, you can follow our documentation on publishing packages that will guide you through the process and give you some tips.

Downloads

The Typst compiler downloads packages from the preview namespace on-demand. Once used, they are cached in {cache-dir}/typst/packages/preview where {cache-dir} is

• $XDG_CACHE_HOME or ~/.cache on Linux
• ~/Library/Caches on macOS
• %LOCALAPPDATA% on Windows

Importing a cached package does not result in network access.

Local packages

Want to install a package locally on your system without publishing it or experiment with it before publishing? You can store packages in {data-dir}/typst/packages/{namespace}/{name}/{version} to make them available locally on your system. Here, {data-dir} is

• $XDG_DATA_HOME or ~/.local/share on Linux
• ~/Library/Application Support on macOS
• %APPDATA% on Windows

You can create an arbitrary {namespace}. A good namespace for system-local packages is local. Using this namespace:

• Store a package in {data-dir}/typst/packages/local/mypkg/1.0.0
• Import from it with #import "@local/mypkg:1.0.0": *.

Packages in the data directory have precedence over ones in the cache directory.

Note that future iterations of Typst’s package management may change/break this local setup.

License

The infrastructure around the package repository is licensed under the terms of the Apache-2.0 license. Packages in packages/ are licensed under their respective license.

Note

The following is an unofficial copy of the file in Typst’s official repository as of 2026-01-26.

Package submission guidelines

Before creating and submitting your package, please carefully read through the package submission guidelines listed below. These rules ensure that published packages meet a certain quality standard and work properly for everyone.

• Functionality: Packages should conceivably be useful to other users and should expose their capabilities in a reasonable fashion.

• Name: We have somewhat unusual naming rules that all packages must adhere to. Please read them carefully. The naming rules ensure that multiple packages for the same purpose can co-exist without one having an unfair advantage.

• Correctness: Typst files and the manifest should not contain any syntax errors. More generally, your package should be importable without errors. (This does not mean that the package must be flawless; it’s always possible for bugs to slip in. If you find a mistake or bug after the package is accepted, you can simply submit a patch release.) If your package includes a template, it should compile out-of-the-box. In particular, it should use the absolute package-style import and not a relative file import (i.e @preview/my-package:0.1.0 rather than ../lib.typ).

• Documentation: Your package must include a README.md file, documenting its purpose succinctly. This README should include examples, and may contain illustrations. Examples in the README and other documentation files should be up-to-date and compile. In particular, version numbers in package imports should be updated with each release. The contents of the README file will be displayed on Typst Universe.

• Licensing: The license provided in the package manifest should match the contents of the license file. The authors and copyright year in the license file should be correct. Your package should not contain any copyrighted material for which you don’t have distribution rights.

• Size: Packages should not contain large files or a large number of files. This will be judged on a case-by-case basis, but any exception should be well-motivated. To keep the package small and fast to download, please exclude images for the README or PDF files with documentation from the bundle. For more detailed guidelines, please refer to the “What to commit? What to exclude?” section.

• Security and Safety: Packages must not attempt to exploit the compiler or packaging implementation, in particular not to exfiltrate user data. Names and package contents must be safe for work.

If you don’t meet our requirements, it may take a bit more time for your package to be published, as we will ask you to make changes, but it will not prevent your package from being published once the required changes are made.

Please note that the list above may be extended over time as improvements/issues to the process are discovered. Given a good reason, we reserve the right to reject any package submission.

Package submission in practice

Once you checked that your package meets all the above criteria, make a pull request with the package to this repository. Start by cloning the repository (we recommend using a sparse checkout), and create a new directory for your package named packages/{namespace}/{package-name}/{version}. For now, the only allowed namespace is preview. You can then copy your package files here, commit your changes and open a pull request.

Note

The author of a package update should be the same person as the one who submitted the previous version. If not, the previous author will be asked before approving and publishing the new version.

We have collected tips to make your experience as a package author easier and to avoid common pitfalls. They are split into the following categories:

• The package manifest
• Typst files (including template and example files)
• Images, fonts and other assets
• The README file, and documentation in general
• Licensing of your package
• Further Tips

When a package’s PR has been merged and CI has completed, the package will be available for use. However, it can currently take up to 30 minutes until the package will be visible on Typst Universe.

Fixing or removing a package

Once submitted, a package will not be changed or removed without good reason to prevent breakage for downstream consumers. By submitting a package, you agree that it is here to stay. If you discover a bug or issue, you can of course submit a new version of your package.

Note

The following is an unofficial copy of the file in Typst’s official repository as of 2026-01-26.

Writing a package manifest

A Typst package should contain a file named typst.toml. It is called the “package manifest” or “manifest” for short. This file contains metadata about the package, such as its name, version or the names of its authors.

As suggested by the extension, manifest are written in TOML.

Package metadata

The only required section (“table” in TOML lingo) is named package and contains most of the metadata about your package. Here is an example of what it can look like.

[package]
name = "example"
version = "0.1.0"
entrypoint = "lib.typ"
authors = ["The Typst Project Developers"]
license = "MIT"
description = "Calculate elementary arithmetics with functions."

The following fields are required by the compiler:

• name: The package’s identifier in its namespace. We have some specific rules for packages submitted to Typst Universe, detailed below.
• version: The package’s version as a full major-minor-patch triple. Package versioning should follow SemVer.
• entrypoint: The path to the main Typst file that is evaluated when the package is imported.

If you plan to use your package only on your machine or to distribute it by your own means, you don’t have to include more than these three fields. However, for your package to be published on Typst Universe, a few more fields are required.

Required for submissions to this repository:

• authors: A list of the package’s authors. Each author can provide an email address, homepage, or GitHub handle in angle brackets. The latter must start with an @ character, and URLs must start with http:// or https://.
• license: The package’s license. Must contain a valid SPDX-2 expression describing one or multiple licenses. Please make sure to meet our licensing requirements if you want to submit your package to Typst Universe.
• description: A short description of the package. Double-check this for grammar and spelling mistakes as it will appear in the package list. If you want some tips on how to write a great description, you can refer to the dedicated section below.

Optional:

• homepage: A link to the package’s web presence, where there could be more details, an issue tracker, or something else. Will be linked to from the package list. If there is no dedicated web page for the package, don’t link to its repository here. Omit this field and prefer repository.
• repository: A link to the repository where this package is developed. Will be linked to from Typst Universe if there is no homepage.
• keywords: An array of search keywords for the package.
• categories: An array with up to three categories from the list of categories to help users discover the package.
• disciplines: An array of disciplines defining the target audience for which the package is useful. Should be empty if the package is generally applicable.
• compiler: The minimum Typst compiler version required for this package to work.
• exclude: An array of globs specifying files that should not be part of the published bundle that the compiler downloads when importing the package. These files will still be available on typst universe to link to from the README.
  To be used for large support files like images or PDF documentation that would otherwise unnecessarily increase the bundle size. Don’t exclude the README or the LICENSE, see what to exclude. Globs provided here have the same semantics as lines in a gitignore file. They are applied recursively throughout the project directory. Prepend a forward slash (e.g., /assets*/) to avoid recursive matching.

Packages always live in folders named as {name}/{version}. The name and version in the folder name and manifest must match. Paths in a package are local to that package. Absolute paths start in the package root, while relative paths are relative to the file they are used in.

Naming rules

Package names should not be the obvious or canonical name for a package with that functionality (e.g. slides is forbidden, but sliding or slitastic would be ok). We have this rule because users will find packages with these canonical names first, creating an unfair advantage for the package author who claimed that name. Names should not include the word “typst” (as it is redundant). If they contain multiple words, names should use kebab-case. Look at existing packages and PRs to get a feel for what’s allowed and what’s not.

Additional guidance for template packages: It is often desirable for template names to feature the name of the organization or publication the template is intended for. However, it is still important to us to accommodate multiple templates for the same purpose. Hence, template names shall consist of a unique, non-descriptive part followed by a descriptive part. For example, a template package for the fictitious American Journal of Proceedings (AJP) could be called organized-ajp or eternal-ajp. Package names should be short and use the official entity abbreviation. Template authors are encouraged to add the full name of the affiliated entity as a keyword.

The unamended entity name (e.g. ajp) is reserved for official template packages by their respective entities. Please make it clear in your PR if you are submitting an official package. We will then outline steps to authenticate you as a member of the affiliated organization.

If you are an author of an original template not affiliated with any organization, only the standard package naming guidelines apply to you.

These rules also apply to names in other languages, including transliterations for languages that are not generally written using the Latin alphabet.

Writing a good description

A good package description is simple, easily understandable and succinct. Here are some rules to follow to write great descriptions:

• Keep it short. Try to maximize the content to length ratio and weigh your words thoughtfully. Ideally, it should be 40 to 60 characters long.

• Terminate your description with a full stop.

• Avoid the word “Typst”, which is redundant unless your package or template actually has to do with Typst itself or its ecosystem (like in the case of mantys or t4t).

• Avoid the words “package” for packages and “template” for templates; instead:

  • Packages allow the user to do things; use the imperative mood. For example, Draw Venn diagrams. is better than A package for drawing Venn diagrams..
  • Templates allow the user to write certain types of documents; clearly indicate the type of document your template allows. For example, Master’s thesis at the Unseen University. is better than A template for writing a master’s thesis at the Unseen University.. Omit the indefinite article (“A …”, “An …”) at the beginning of the description for conciseness.

Templates

Packages can act as templates for user projects. In addition to the module that a regular package provides, a template package also contains a set of template files that Typst copies into the directory of a new project.

In most cases, the template files should not include the styling code for the template. Instead, the template’s entrypoint file should import a function from the package. Then, this function is used with a show rule to apply it to the rest of the document.

Template packages (also informally called templates) must declare the [template] key in their typst.toml file. A template package’s typst.toml could look like this:

[package]
name = "charged-ieee"
version = "0.1.0"
entrypoint = "lib.typ"
authors = ["Typst GmbH <https://typst.app>"]
license = "MIT-0"
description = "IEEE-style paper to publish at conferences and journals."

[template]
path = "template"
entrypoint = "main.typ"
thumbnail = "thumbnail.png"

Required by the compiler:

• path: The directory within the package that contains the files that should be copied into the user’s new project directory.
• entrypoint: A path relative to the template’s path that points to the file serving as the compilation target. This file will become the previewed file in the Typst web application.

Required for submissions to this repository:

• thumbnail: A path relative to the package’s root that points to a PNG or lossless WebP thumbnail for the template. The thumbnail must depict one of the pages of the template as initialized. The longer edge of the image must be at least 1080 px in length. Its file size must not exceed 3 MiB. Exporting a PNG at 250 PPI resolution is usually a good way to generate a thumbnail. You can use the following command for that: typst compile -f png --pages 1 --ppi 250 main.typ thumbnail.png. You are encouraged to use oxipng to reduce the thumbnail’s file size. The thumbnail will automatically be excluded from the package files and must not be referenced anywhere in the package.

Template packages must specify at least one category in categories (under the [package] section).

If you’re submitting a template, please test that it works locally on your system. The recommended workflow for this is as follows:

• Add a symlink from $XDG_DATA_HOME/typst/packages/preview to the preview folder of your fork of this repository (see the documentation on local packages).
• Run typst init @{namespace}/{name}:{version}. Note that you must manually specify the version as the package is not yet in the index, so the latest version won’t be detected automatically.
• Compile the freshly instantiated template.

Third-party metadata

Third-party tools can add their own entry under the [tool] section to attach their Typst-specific configuration to the manifest.

[package]
# ...

[tool.mytool]
foo = "bar"

Note

The following is an unofficial copy of the file in Typst’s official repository as of 2026-01-26.

Writing high-quality Typst files

No specific code style is mandated, but two spaces of indent and kebab-case for variable and function names are recommended. There can be exceptions (for instance it can make sense to have a variable called Alpha and not alpha) and if you have a strong preference for camelCase or snake_case, it can be accepted.

Use package specifications in imports

When writing example files, it is better to use the full package specification when importing your own package, instead of relative imports. The reasoning here is that it should be possible to copy any provided file as is and start working from that. In other words, it is better to write:

#import "@preview/my-package:1.0.0": my-function

than:

#import "../lib.typ": my-function

For template files, this is not only a recommendation but a requirement. Users should never have to edit a project freshly created from a template to make it compile.

This recommendation does not apply to files that are directly part of the package however, as this could cause a cyclic import.

Only exposing specific functions publicly

When writing your package, you will probably create internal functions and variables that should not be accessible to the end user. However, Typst currently doesn’t provide any keyword to indicate that a given binding should be public or private, as most other programming languages do.

Fortunately, there is an easy pattern to select specific items to be public, and keep the rest private to your package: instead of putting actual code in the entrypoint of the package, simply import the items you want to be public from other files.

Let’s look at an example. Here is my package.typ file:

#let private(a, b) = a + b
#let public(a, b, c) = private(a, b) * private(b, c)

Then, if your package entrypoint is set to lib.typ, you can chose what to export to the user by writing the following in lib.typ:

#import "package.typ": public

The user won’t be able to call the private function, but can access the one named public as they wish.

Template customization

When providing a template, it is often desirable to let users customize the styles you provide. You may also want to let them override the default contents you provide (for example, what elements are shown on the title page and how they are displayed).

However, the way Typst templates currently work, this code often lives in the library part of the package, that is not copied to the users project, and thus cannot be modified to fit their needs. Only placeholder configuration and content is generally part of the template code that the user can edit in their own project.

There is no proper solution to that problem for now. In the future, types and custom elements will be a good way to give user control over the template contents and appearance if they need, while providing good defaults.

Note

The following is an unofficial copy of the file in Typst’s official repository as of 2026-01-26.

Images, fonts and other resources

Typst packages can ship more than just code. This document explains how to properly handle resource files and avoid common mistakes.

Paths are package scoped

When reading external files, the path that is given to the function (like image, json or read) is relative to the current file and can only access files in the current package. This means it can’t access files from other packages. But more importantly, in case your package is a template, it can’t access files in the user’s project.

For instance, let’s say you have the following file hierarchy:

preview/my-template/1.0.0/
  README.md
  LICENSE
  typst.toml
  thumbnail.png
  src/
    lib.typ
  template/
    main.typ
    logo.png

In lib.typ, calling image("../template/logo.png") will seem to work. But this won’t refer to the copy of logo.png in the users project: if they were to replace the provided logo with their own, your package would still use the original one.

It also means that allowing for customization using a string parameter called logo-path that is passed to image in your package won’t work either: the file access is made relatively to where the image function is called, not to where the path string is created.

The proper way to let the people using your template overwrite the file to use is to take content as an argument directly, not a string. For example, you should replace this:

#let cover-page(logo-path: "logo.png", title) = {
  image(logo-path)
  heading(title)
}

With something like:

#let cover-page(logo: image("logo.png"), title) = {
  logo
  heading(title)
}

It is still possible to customize define some default values to configure how the image is displayed (its width for example), using a set image(..) rule.

It will be possible to take paths as arguments directly, once a dedicated type exists.

Fonts are not supported in packages

As of now, it is not possible to ship font files within a package. Fonts need to be present in the user’s project to be detected in the web app, or be included with the --font-path argument on the command line, and a package can’t interfere with either of these.

Technically, it would be possible to ship fonts with templates by putting them into the template directory and asking command line users to specify the correct directory when compiling. But this experience would be suboptimal, and would result in a lot of large font files being duplicated both in this repository and in user projects. For these reasons, it is not allowed.

The current solution if your package requires specific fonts is simply to document how to download them and use them in the web app or on the command line.

This is not a perfect solution either. The situation will be improved in future Typst versions.

Licensing non-code assets

We have specific guidelines for licensing assets distributed in your packages.

Note

The following is an unofficial copy of the file in Typst’s official repository as of 2026-01-26.

Writing package documentation

Packages must contain a README.md file documenting (at least briefly) what the package does and all definitions intended for usage by downstream users. Examples in the README should show how to use the package through a @preview import. Also consider running typos through your package before release.

More complete documentation (usually written in Markdown, or in a PDF generated from a Typst file) can be linked from this README. In general there are two options for linking these resources:

If the resources are committed to this repository, you should link them locally. For example like this: [manual.pdf](docs/manual.pdf). Most of these files should be excluded in your manifest, see what to exclude.

If the resources are stored elsewhere, you can link to their URL as usual. When linking to files from another git repository, consider linking to a specific tag or revision, instead of the main branch. This will ensure that the linked resources always match the version of the package. So for example, prefer linking to the first URL instead of the second one:

1. https://github.com/micheledusi/Deckz/blob/v0.3.0/docs/manual-deckz.pdf
2. https://github.com/micheledusi/Deckz/blob/main/docs/manual-deckz.pdf

If your package has a dedicated documentation website, it can be linked in the README, but also via the homepage field of your manifest.

Differences from standard Markdown

Typst Universe processes your package README before displaying it, in ways that differ from standard Markdown and from what GitHub or other Git forges do. Here is what you need to know to make sure your README will be displayed as expected.

The most visible processing that is done is to remove top-level headings: a web page should only have a single <h1> tag for accessibility and SEO reasons, and Typst Universe already shows the name of the package in such a heading.

Also note that some Markdown extensions that are present on GitHub, like alert blocks or emoji shortcodes are not available on Typst Universe.

Theme-responsive images

You can include images that will work with both light and dark theme in your README using the following snippet:

<picture>
  <source media="(prefers-color-scheme: dark)" srcset="example-dark.png">
  <img alt="Example output" src="example-light.png">
</picture>

Note

The following is an unofficial copy of the file in Typst’s official repository as of 2026-01-26.

Licensing your package

Packages must be licensed under the terms of an OSI-approved license or a version of CC-BY, CC-BY-SA, or CC0. We recommend you do not license your package using a Creative Commons license unless it is a derivative work of a CC-BY-SA-licensed work or if it is not primarily code, but content or data. In most other cases, a free/open license specific to software is better suited for Typst packages. If different files in your package are under different licenses, it should be stated clearly (in your README for example) which license applies to which file.

In addition to specifying the license in the TOML manifest, a package must either contain a LICENSE file or link to one in its README.md.

Additional details for template packages: If you expect the package license’s provisions to apply to the contents of the template directory (used to scaffold a project) after being modified through normal use, especially if it still meets the threshold of originality, you must ensure that users of your template can use and distribute the modified contents without restriction. In such cases, we recommend licensing at least the template directory under a license that requires neither attribution nor distribution of the license text. Such licenses include MIT-0 and Zero-Clause BSD. You can use an SPDX AND expression to selectively apply different licenses to parts of your package. In this case, the README or package files must make clear under which license they fall. If you explain the license distinction in the README file, you must not exclude it from the package.

Copyrighted material

Sometimes you may want to distribute assets which are not under an open-source license, for example, the logo of a university. Typst Universe allows you to distribute those assets only if the copyright holder has a policy that clears distribution of the asset in the package.

If you are including such assets in your package, have your README clearly indicate which files are not covered by the license given in the manifest file and include or link to the relevant terms by the copyright holder.

Note

Among Tools that can be useful at the end of this page, typst-package-check is the only official one. Unofficial pre-built binaries for it are available at Typst dev builds. However, the PR robot will run it automatically when you submitting your package, so usually it’s unnecessary to use it locally.

Note

The following is an unofficial copy of the file in Typst’s official repository as of 2026-01-26.

Tips for package authors

Sparse checkout of the repository

Because the repository stores all versions of all packages that ever were published, its size only grows with time. However, most of the time, you will only work in a few specific directories (the ones for your own packages). Git allows for “sparse checkouts”, which reduce the time it takes to clone the repository and its size on your disk.

First, make sure you have forked the repository to your own GitHub account. Then, follow these steps to clone the repository:

git clone --depth 1 --no-checkout --filter="tree:0" git@github.com:{your-username}/packages
cd packages
git sparse-checkout init
git sparse-checkout set packages/preview/{your-package-name}
git remote add upstream git@github.com:typst/packages
git config remote.upstream.partialclonefilter tree:0
git checkout main

The packages directory you are in still corresponds to the whole repository. Do not delete or edit the README.md, LICENSE or any other file at the root. Instead, create the directory packages/preview/{your-package-name}/{version} and copy your files here. Note that packages/ is a directory in the packages repository: if you look at the full path, there should be two consecutive parts called packages.

Don’t use submodules

The Typst package repository requires the files to be actually copied to their respective directory, they should not be included as Git submodules.

When copying a package from another Git repository, you should not copy the .git folder, otherwise when creating a commit to publish your package, Git will replace the copied files with a submodule.

What to commit? What to exclude?

In some case, simply copying and pasting the contents of the repository in which you developed your package to a new directory in this repository is enough to publish a package. However, this naive approach may result in unnecessary files being included, making the size of this repository and of the final archives larger than they need to be.

There are two solutions to limit this problem: excluding files from the archive (using the exclude key in your package manifest), or simply not committing the files to this repository in the first place.

To know which strategy to apply to each file, we can split them in three groups:

1. Required files
Files that are necessary for the package to work. If any of these files are removed, the package would break for the end user. This includes the manifest file, main Typst file and its dependencies, and in case of a template package, any file in the template directory.

2. Documentation files
Files that are necessary for the package to be displayed correctly on Typst Universe. This includes the README, and any files that are linked from there (manuals, examples, illustrations, etc.). These files can easily be accessed by opening the package README.

3. Other files
This generally includes test files, build scripts, but also examples or manuals that are not linked in the README. These files would be almost impossible to access for the final user, unless they browse this GitHub repository or their local package cache.

The first two groups (required and documentation files) should be committed to this repository. And files that are not strictly necessary for the package to work (documentation files) should be excluded in typst.toml. They will still be available on typst universe to link to from the README.
The third group should simply not be committed to this repository. If you think some of the remaining files are important, they probably belong to the second group and should be linked in the README, so that they are easily discoverable. A good example showing how to link examples and a manual is CeTZ.

The only exceptions to this rule are the LICENSE file (that should always be available along with the source code, so it should not be excluded), and the README (which is generally a lightweight file, and can provide minimal documentation in case the user is offline or can’t access anything else than their local package cache for some other reason).

Also note that there is no need to exclude template thumbnails: they are automatically left out of the archive.

Tools that can be useful

The community created some tools that can help when developing your package:

• typst-package-check, to lint your package.
• tytanic, to test your packages.
• typship, to easily install your package locally or submit it to Typst Universe.

A more comprehensive list can be found in Package development — Best of Typst (TCDM) maintained by the community.

Note

The following is an unofficial copy of the file in Typst’s official repository as of 2026-01-26.

Typst Package Categories

Categories help users explore packages, make finding the right one easier, and provide package authors with a reference for best-practices in similar packages. In addition to categories, packages can also specify a list of disciplines describing their target audience.

Each package can declare itself a part of up to three categories.

There are two kinds of package categories: Functional categories that describe what a package does on a technical level and publication categories that describe for which kind of deliverable a package may be used.

Package authors are not required to pick a category from each of the two groups. Instead, they can omit one group completely if it is not applicable to their package, or use two categories for another group. Publication categories, for example, are of big relevance to template packages and less so to a general utility package that may apply to most publication kinds.

Functional Categories

• components: Building blocks for documents. This includes boxes, layout elements, marginals, icon packs, color palettes, and more.
• visualization: Packages producing compelling visual representations of data, information, and models.
• model: Tools for managing semantic information and references. Examples could be glossaries and bibliographic tools.
• layout: Primitives and helpers to achieve advanced layouts and set up a page with headers, margins, and multiple content flows.
• text: Packages that transform text and strings or are focused on fonts.
• languages: Tools for localization and internationalization as well as dealing with different scripts and languages in the same document.
• scripting: Packages/libraries focused on the programmatic aspect of Typst, useful for automating documents.
• integration: Integrations with third-party tools and formats. In particular, this includes packages that embed a third-party binary as a plugin.
• utility: Auxiliary packages/tools, for example for creating compatibility and authoring packages.
• fun: Unique uses of Typst that are not necessarily practical, but always entertaining.

Publication Categories

• book: Long-form fiction and non-fiction books with multiple chapters.
• report: A multipage informational or investigative document focused on a single topic. This category contains templates for tech reports, homework, proposals and more.
• paper: A scientific treatment on a research question. Usually published in a journal or conference proceedings.
• thesis: A final long-form deliverable concluding an academic degree.
• poster: A large-scale graphics-heavy presentation of a topic. A poster is intended to give its reader a first overview over a topic at a glance.
• flyer: Graphics-heavy, small leaflets intended for massive circulation and to inform or convince.
• presentation: Slides for a projected, oral presentation.
• cv: A résumé or curriculum vitæ presenting the author’s professional achievements in a compelling manner.
• office: Staples for the day-to-day in an office, such as a letter or an invoice.

Note

The following is an unofficial copy of the file in Typst’s official repository as of 2026-01-26.

Typst Package Disciplines

Disciplines define the target audience of a package, making it easy for users to discover domain-specific packages and templates. Not all packages are domain-specific, those can simply omit the disciplines key from their manifest. In addition to disciplines, packages can also specify a list of categories describing their functionality.

Disciplines are standardized for discoverability. If you want to submit a domain-specific package, but there isn’t a fitting discipline in the list below, please reach out to us!

The following disciplines are currently defined:

• agriculture
• anthropology
• archaeology
• architecture
• biology
• business
• chemistry
• communication
• computer-science
• design
• drawing
• economics
• education
• engineering
• fashion
• film
• geography
• geology
• history
• journalism
• law
• linguistics
• literature
• mathematics
• medicine
• music
• painting
• philosophy
• photography
• physics
• politics
• psychology
• sociology
• theater
• theology
• transportation

Licenses

This chapter contains legal files like LICENSE from the original repositories.

Typst: LICENSE

Note

The following is an unofficial copy of the file in Typst’s official repository as of 2026-01-26.

                          Apache License
                    Version 2.0, January 2004
                 http://www.apache.org/licenses/

TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION

1. Definitions.

   “License” shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document.

   “Licensor” shall mean the copyright owner or entity authorized by the copyright owner that is granting the License.

   “Legal Entity” shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, “control” means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity.

   “You” (or “Your”) shall mean an individual or Legal Entity exercising permissions granted by this License.

   “Source” form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files.

   “Object” form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types.

   “Work” shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below).

   “Derivative Works” shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof.

   “Contribution” shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner. For the purposes of this definition, “submitted” means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as “Not a Contribution.”

   “Contributor” shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by Licensor and subsequently incorporated within the Work.

2. Grant of Copyright License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form.

3. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed.

4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions:

   (a) You must give any other recipients of the Work or Derivative Works a copy of this License; and

   (b) You must cause any modified files to carry prominent notices stating that You changed the files; and

   (c) You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and

   (d) If the Work includes a “NOTICE” text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License.

   You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License.

5. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions.

6. Trademarks. This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file.

7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License.

8. Limitation of Liability. In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages.

9. Accepting Warranty or Additional Liability. While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity, or other liability obligations and/or rights consistent with this License. However, in accepting such obligations, You may act only on Your own behalf and on Your sole responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your accepting any such warranty or additional liability.

END OF TERMS AND CONDITIONS

Note

The following is an unofficial copy of the file in Typst’s official repository as of 2026-01-26.

Licenses for third party components used by this project can be found below.

================================================================================ The MIT License applies to:

• The default color set defined in crates/typst/src/visualize/color.rs which is adapted from the colors.css project (https://clrs.cc/)

• The RemoteReader defined in crates/typst-kit/src/download.rs which is closely modelled after the DownloadTracker from rustup (https://github.com/rust-lang/rustup/blob/master/src/cli/download_tracker.rs)

• The path diffing algorithm in crates/typst-syntax/src/path.rs which is modified from rustc’s path_relative_from function (https://github.com/rust-lang/rust/blob/e1d0de82cc40b666b88d4a6d2c9dcbc81d7ed27f/src/librustc_back/rpath.rs#L116-L158) Copyright 2012-2015 The Rust Project Developers.

• The SyntaxSet defined in crates/typst-syntax/src/set.rs which is based on the TokenSet from rust-analyzer (https://github.com/rust-lang/rust-analyzer/blob/master/crates/parser/src/token_set.rs)

The MIT License (MIT)

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR

IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

================================================================================ Translations defined in crates/typst-library/translations/ are adapted from

• Babel (https://ctan.org/pkg/babel) Copyright (C) 2012-2025 Javier Bezos and Johannes L. Braams. Copyright (C) 1989-2012 Johannes L. Braams and any individual authors listed elsewhere. All rights reserved. This file is part of the Babel system It may be distributed and/or modified under the conditions of the LaTeX Project Public License, either version 1.3 of this license or (at your option) any later version. The latest version of this license is in http://www.latex-project.org/lppl.txt and version 1.3 or later is part of all distributions of LaTeX version 2003/12/01 or later.

• Cleveref (https://ctan.org/pkg/cleveref)

  Copyright 2006–2018 Toby Cubitt This file may be distributed and/or modified under the conditions of the LaTeX Project Public License, either version 1.2 of this license or (at your option) any later version. The latest version of this license is in: http://www.latex-project.org/lppl.txt and version 1.2 or later is part of all distributions of LaTeX version 1999/12/01 or later.

================================================================================ Alpha multiplication and source-over blending in crates/typst-render/src/text.rs are ported from Skia code which can be found here: https://skia.googlesource.com/skia/+/refs/heads/main/include/core/SkColorPriv.h

Copyright (c) 2011 Google Inc. All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

• Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
• Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
• Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS

“AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

================================================================================ Scalar::powi implementation in crates/typst-utils/src/scalar.rs is ported from here: https://github.com/llvm/llvm-project/blob/0ee439b/compiler-rt/lib/builtins/powidf2.c

The LLVM Project is under the Apache License v2.0 with LLVM Exceptions:

                             Apache License
                       Version 2.0, January 2004
                    http://www.apache.org/licenses/

TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION

1. Definitions.

  "License" shall mean the terms and conditions for use, reproduction,
  and distribution as defined by Sections 1 through 9 of this document.

  "Licensor" shall mean the copyright owner or entity authorized by
  the copyright owner that is granting the License.

  "Legal Entity" shall mean the union of the acting entity and all
  other entities that control, are controlled by, or are under common
  control with that entity. For the purposes of this definition,
  "control" means (i) the power, direct or indirect, to cause the
  direction or management of such entity, whether by contract or
  otherwise, or (ii) ownership of fifty percent (50%) or more of the
  outstanding shares, or (iii) beneficial ownership of such entity.

  "You" (or "Your") shall mean an individual or Legal Entity
  exercising permissions granted by this License.

  "Source" form shall mean the preferred form for making modifications,
  including but not limited to software source code, documentation
  source, and configuration files.

  "Object" form shall mean any form resulting from mechanical
  transformation or translation of a Source form, including but
  not limited to compiled object code, generated documentation,
  and conversions to other media types.

  "Work" shall mean the work of authorship, whether in Source or
  Object form, made available under the License, as indicated by a
  copyright notice that is included in or attached to the work
  (an example is provided in the Appendix below).

  "Derivative Works" shall mean any work, whether in Source or Object
  form, that is based on (or derived from) the Work and for which the
  editorial revisions, annotations, elaborations, or other modifications
  represent, as a whole, an original work of authorship. For the purposes
  of this License, Derivative Works shall not include works that remain
  separable from, or merely link (or bind by name) to the interfaces of,
  the Work and Derivative Works thereof.

  "Contribution" shall mean any work of authorship, including
  the original version of the Work and any modifications or additions
  to that Work or Derivative Works thereof, that is intentionally
  submitted to Licensor for inclusion in the Work by the copyright owner
  or by an individual or Legal Entity authorized to submit on behalf of
  the copyright owner. For the purposes of this definition, "submitted"
  means any form of electronic, verbal, or written communication sent
  to the Licensor or its representatives, including but not limited to
  communication on electronic mailing lists, source code control systems,
  and issue tracking systems that are managed by, or on behalf of, the
  Licensor for the purpose of discussing and improving the Work, but
  excluding communication that is conspicuously marked or otherwise
  designated in writing by the copyright owner as "Not a Contribution."

  "Contributor" shall mean Licensor and any individual or Legal Entity
  on behalf of whom a Contribution has been received by Licensor and
  subsequently incorporated within the Work.

2. Grant of Copyright License. Subject to the terms and conditions of
  this License, each Contributor hereby grants to You a perpetual,
  worldwide, non-exclusive, no-charge, royalty-free, irrevocable
  copyright license to reproduce, prepare Derivative Works of,
  publicly display, publicly perform, sublicense, and distribute the
  Work and such Derivative Works in Source or Object form.

3. Grant of Patent License. Subject to the terms and conditions of
  this License, each Contributor hereby grants to You a perpetual,
  worldwide, non-exclusive, no-charge, royalty-free, irrevocable
  (except as stated in this section) patent license to make, have made,
  use, offer to sell, sell, import, and otherwise transfer the Work,
  where such license applies only to those patent claims licensable
  by such Contributor that are necessarily infringed by their
  Contribution(s) alone or by combination of their Contribution(s)
  with the Work to which such Contribution(s) was submitted. If You
  institute patent litigation against any entity (including a
  cross-claim or counterclaim in a lawsuit) alleging that the Work
  or a Contribution incorporated within the Work constitutes direct
  or contributory patent infringement, then any patent licenses
  granted to You under this License for that Work shall terminate
  as of the date such litigation is filed.

4. Redistribution. You may reproduce and distribute copies of the
  Work or Derivative Works thereof in any medium, with or without
  modifications, and in Source or Object form, provided that You
  meet the following conditions:

  (a) You must give any other recipients of the Work or
      Derivative Works a copy of this License; and

  (b) You must cause any modified files to carry prominent notices
      stating that You changed the files; and

  (c) You must retain, in the Source form of any Derivative Works
      that You distribute, all copyright, patent, trademark, and
      attribution notices from the Source form of the Work,
      excluding those notices that do not pertain to any part of
      the Derivative Works; and

  (d) If the Work includes a "NOTICE" text file as part of its
      distribution, then any Derivative Works that You distribute must
      include a readable copy of the attribution notices contained
      within such NOTICE file, excluding those notices that do not
      pertain to any part of the Derivative Works, in at least one
      of the following places: within a NOTICE text file distributed
      as part of the Derivative Works; within the Source form or
      documentation, if provided along with the Derivative Works; or,
      within a display generated by the Derivative Works, if and
      wherever such third-party notices normally appear. The contents
      of the NOTICE file are for informational purposes only and
      do not modify the License. You may add Your own attribution
      notices within Derivative Works that You distribute, alongside
      or as an addendum to the NOTICE text from the Work, provided
      that such additional attribution notices cannot be construed
      as modifying the License.

  You may add Your own copyright statement to Your modifications and
  may provide additional or different license terms and conditions
  for use, reproduction, or distribution of Your modifications, or
  for any such Derivative Works as a whole, provided Your use,
  reproduction, and distribution of the Work otherwise complies with
  the conditions stated in this License.

5. Submission of Contributions. Unless You explicitly state otherwise,
  any Contribution intentionally submitted for inclusion in the Work
  by You to the Licensor shall be under the terms and conditions of
  this License, without any additional terms or conditions.
  Notwithstanding the above, nothing herein shall supersede or modify
  the terms of any separate license agreement you may have executed
  with Licensor regarding such Contributions.

6. Trademarks. This License does not grant permission to use the trade
  names, trademarks, service marks, or product names of the Licensor,
  except as required for reasonable and customary use in describing the
  origin of the Work and reproducing the content of the NOTICE file.

7. Disclaimer of Warranty. Unless required by applicable law or
  agreed to in writing, Licensor provides the Work (and each
  Contributor provides its Contributions) on an "AS IS" BASIS,
  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
  implied, including, without limitation, any warranties or conditions
  of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
  PARTICULAR PURPOSE. You are solely responsible for determining the
  appropriateness of using or redistributing the Work and assume any
  risks associated with Your exercise of permissions under this License.

8. Limitation of Liability. In no event and under no legal theory,
  whether in tort (including negligence), contract, or otherwise,
  unless required by applicable law (such as deliberate and grossly
  negligent acts) or agreed to in writing, shall any Contributor be
  liable to You for damages, including any direct, indirect, special,
  incidental, or consequential damages of any character arising as a
  result of this License or out of the use or inability to use the
  Work (including but not limited to damages for loss of goodwill,
  work stoppage, computer failure or malfunction, or any and all
  other commercial damages or losses), even if such Contributor
  has been advised of the possibility of such damages.

9. Accepting Warranty or Additional Liability. While redistributing
  the Work or Derivative Works thereof, You may choose to offer,
  and charge a fee for, acceptance of support, warranty, indemnity,
  or other liability obligations and/or rights consistent with this
  License. However, in accepting such obligations, You may act only
  on Your own behalf and on Your sole responsibility, not on behalf
  of any other Contributor, and only if You agree to indemnify,
  defend, and hold each Contributor harmless for any liability
  incurred by, or claims asserted against, such Contributor by reason
  of your accepting any such warranty or additional liability.

END OF TERMS AND CONDITIONS

APPENDIX: How to apply the Apache License to your work.

  To apply the Apache License to your work, attach the following
  boilerplate notice, with the fields enclosed by brackets "[]"
  replaced with your own identifying information. (Don't include
  the brackets!)  The text should be enclosed in the appropriate
  comment syntax for the file format. We also recommend that a
  file or class name and description of purpose be included on the
  same "printed page" as the copyright notice for easier
  identification within third-party archives.

Copyright [yyyy] [name of copyright owner]

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

   http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

–– LLVM Exceptions to the Apache 2.0 License ––

As an exception, if, as a result of your compiling your source code, portions of this Software are embedded into an Object form of such source code, you may redistribute such embedded portions in such Object form without complying with the conditions of Sections 4(a), 4(b) and 4(d) of the License.

In addition, if you combine or link compiled forms of this Software with software that is licensed under the GPLv2 (“Combined Software”) and if a court of competent jurisdiction determines that the patent provision (Section 3), the indemnity provision (Section 9) or other Section of the License conflicts with the conditions of the GPLv2, you may retroactively and prospectively choose to deem waived or otherwise exclude such Section(s) of the License, but only in their entirety and only with respect to the Combined Software.

Software from third parties included in the LLVM Project:

The LLVM Project contains third party software which is under different license terms. All such code will be identified clearly using at least one of two mechanisms:

1. It will be in a separate directory tree with its own LICENSE.txt or LICENSE file at the top containing the specific license and restrictions which apply to that software, or
2. It will contain specific license and restriction terms at the top of every file.

Legacy LLVM License (https://llvm.org/docs/DeveloperPolicy.html#legacy):

University of Illinois/NCSA Open Source License

Copyright (c) 2003-2019 University of Illinois at Urbana-Champaign. All rights reserved.

Developed by:

LLVM Team

University of Illinois at Urbana-Champaign

http://llvm.org

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal with the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

* Redistributions of source code must retain the above copyright notice,
  this list of conditions and the following disclaimers.

* Redistributions in binary form must reproduce the above copyright notice,
  this list of conditions and the following disclaimers in the
  documentation and/or other materials provided with the distribution.

* Neither the names of the LLVM Team, University of Illinois at
  Urbana-Champaign, nor the names of its contributors may be used to
  endorse or promote products derived from this Software without specific
  prior written permission.

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR

IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE CONTRIBUTORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS WITH THE SOFTWARE.

Codex: LICENSE

Note

The following is an unofficial copy of the file in Typst’s official repository as of 2026-01-26.

                          Apache License
                    Version 2.0, January 2004
                 http://www.apache.org/licenses/

TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION

1. Definitions.

   “License” shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document.

   “Licensor” shall mean the copyright owner or entity authorized by the copyright owner that is granting the License.

   “Legal Entity” shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, “control” means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity.

   “You” (or “Your”) shall mean an individual or Legal Entity exercising permissions granted by this License.

   “Source” form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files.

   “Object” form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types.

   “Work” shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below).

   “Derivative Works” shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof.

   “Contribution” shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner. For the purposes of this definition, “submitted” means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as “Not a Contribution.”

   “Contributor” shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by Licensor and subsequently incorporated within the Work.

2. Grant of Copyright License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form.

3. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed.

4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions:

   (a) You must give any other recipients of the Work or Derivative Works a copy of this License; and

   (b) You must cause any modified files to carry prominent notices stating that You changed the files; and

   (c) You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and

   (d) If the Work includes a “NOTICE” text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License.

   You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License.

5. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions.

6. Trademarks. This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file.

7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License.

8. Limitation of Liability. In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages.

9. Accepting Warranty or Additional Liability. While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity, or other liability obligations and/or rights consistent with this License. However, in accepting such obligations, You may act only on Your own behalf and on Your sole responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your accepting any such warranty or additional liability.

END OF TERMS AND CONDITIONS

Hayagriva: LICENSE-MIT

Note

The following is an unofficial copy of the file in Typst’s official repository as of 2025-12-27.

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Hayagriva: LICENSE-APACHE

Note

The following is an unofficial copy of the file in Typst’s official repository as of 2025-12-27.

                          Apache License
                    Version 2.0, January 2004
                 http://www.apache.org/licenses/

TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION

1. Definitions.

   “License” shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document.

   “Licensor” shall mean the copyright owner or entity authorized by the copyright owner that is granting the License.

   “Legal Entity” shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, “control” means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity.

   “You” (or “Your”) shall mean an individual or Legal Entity exercising permissions granted by this License.

   “Source” form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files.

   “Object” form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types.

   “Work” shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below).

   “Derivative Works” shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof.

   “Contribution” shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner. For the purposes of this definition, “submitted” means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as “Not a Contribution.”

   “Contributor” shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by Licensor and subsequently incorporated within the Work.

2. Grant of Copyright License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form.

3. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed.

4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions:

   (a) You must give any other recipients of the Work or Derivative Works a copy of this License; and

   (b) You must cause any modified files to carry prominent notices stating that You changed the files; and

   (c) You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and

   (d) If the Work includes a “NOTICE” text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License.

   You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License.

5. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions.

6. Trademarks. This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file.

7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License.

8. Limitation of Liability. In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages.

9. Accepting Warranty or Additional Liability. While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity, or other liability obligations and/or rights consistent with this License. However, in accepting such obligations, You may act only on Your own behalf and on Your sole responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your accepting any such warranty or additional liability.

END OF TERMS AND CONDITIONS

APPENDIX: How to apply the Apache License to your work.

To apply the Apache License to your work, attach the following boilerplate notice, with the fields enclosed by brackets “[]” replaced with your own identifying information. (Don’t include the brackets!) The text should be enclosed in the appropriate comment syntax for the file format. We also recommend that a file or class name and description of purpose be included on the same “printed page” as the copyright notice for easier identification within third-party archives.

Copyright [2021] [Martin Haug, Laurenz Mädje, and Hayagriva Contributors]

Licensed under the Apache License, Version 2.0 (the “License”); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

Hayagriva: NOTICE

Note

The following is an unofficial copy of the file in Typst’s official repository as of 2025-12-27.

Licenses for third party components used by this project can be found below.

================================================================================ The Creative Commons BY-SA 3.0 DEED License applies to:

• The CSL styles found in tests/data/*
• The CSL styles and locales found in archive/

https://creativecommons.org/licenses/by-sa/3.0/

Packages: LICENSE

Note

The following is an unofficial copy of the file in Typst’s official repository as of 2026-01-26.

                          Apache License
                    Version 2.0, January 2004
                 http://www.apache.org/licenses/

TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION

1. Definitions.

   “License” shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document.

   “Licensor” shall mean the copyright owner or entity authorized by the copyright owner that is granting the License.

   “Legal Entity” shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, “control” means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity.

   “You” (or “Your”) shall mean an individual or Legal Entity exercising permissions granted by this License.

   “Source” form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files.

   “Object” form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types.

   “Work” shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below).

   “Derivative Works” shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof.

   “Contribution” shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner. For the purposes of this definition, “submitted” means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as “Not a Contribution.”

   “Contributor” shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by Licensor and subsequently incorporated within the Work.

2. Grant of Copyright License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form.

3. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed.

4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions:

   (a) You must give any other recipients of the Work or Derivative Works a copy of this License; and

   (b) You must cause any modified files to carry prominent notices stating that You changed the files; and

   (c) You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and

   (d) If the Work includes a “NOTICE” text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License.

   You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License.

5. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions.

6. Trademarks. This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file.

7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License.

8. Limitation of Liability. In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages.

9. Accepting Warranty or Additional Liability. While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity, or other liability obligations and/or rights consistent with this License. However, in accepting such obligations, You may act only on Your own behalf and on Your sole responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your accepting any such warranty or additional liability.

END OF TERMS AND CONDITIONS