This section documents all changes to the Typst language and compiler between Typst 0.14.2 and 0.15.0. If you are migrating an existing document to Typst 0.15, make sure to check out the Migration guide. It walks you through changes you may need to make to your existing documents to ensure compatibility with Typst 0.15.

Highlights

• Typst now supports variable fonts
• HTML export now supports equations out of the box via MathML
• With the new, experimental bundle export target, a single Typst project can output multiple files (e.g. a multi-page website)
• A single document can now contain multiple bibliographies
• Typst can now target multiple PDF standards at once
• The new within selector simplifies many introspection use cases
• The new divider element represents a thematic break that templates can style
• Spot colors enable use of custom pigments in offset printing
• With the new file path type, project-relative paths can be passed to packages
• The new, more general typst eval CLI subcommand supersedes typst query
• Layout convergence issues now result in detailed diagnostics
• Two long-standing list layout issues with marker alignment and centering were fixed
• Paragraph handling in HTML export is improved, preventing unexpected paragraphs from appearing
• This documentation now has a print version

Language

Syntax

Styling

Scripting

Library

Foundations

Model

Text

• Added support for variable fonts

  • The well-known variation axes ital, slnt, wght, wdth, and opsz are automatically set based on text weight, stretch, style, and size
  • Custom variations can be configured via the new variations parameter of the text function
  • When using a variable font with Typst, the suffixes “Variable”, “Var”, and “VF” should be omitted as Typst trims them to unify static and variable fonts into a single family (Minor breaking change)

• Font features

• Fixed that context text.font did not reflect the covers field
• Fixed uneven CJK-Latin spacing in justified paragraphs
• Fixed a bug where the lorem function would not produce the exact number of requested words
• Improved translations for Swedish , Portuguese , Czech , Latvian , Slovak , Polish , Vietnamese , Finnish , and Welsh
• Added font exception to avoid SimSun-ExtB being incorrectly merged with SimSun

• Updated New Computer Modern fonts to version 8.1.0

  • This update changes the default look of calligraphic letterforms in the math font; the previous style can be restored through show math.equation: set text(stylistic-set: 6)

• Updated Unicode components

  • In particular, this fixed an issue with linebreaking of guillemets

Math

Symbols

Layout

Visualize

• Added support for spot colors (also called separation colors)

• Tilings

• Gradients

• Fixed various bugs with rectangle strokes in combination with radii
• Fixed a potential deadlock with font fallback in SVGs

• Various improvements to SVG image handling (see the resvg 0.46 and 0.47 changelogs); in particular:

  • Added support for SVGs without top-level xmlns attribute
  • Added support for variable fonts in SVG using the font-variation-settings CSS property

• Various improvements to PDF image handling (see the commits between d0b540f and 3483462 on hayro); in particular:

  • Added support for JPEG2000 (JPXDecode) and JBIG2 (JBIG2Decode) images
  • Improved parsing robustness for non-compliant files
  • Added support for blend modes

Introspection

Data Loading

Export

Bundle

HTML

• Mathematical equations are now automatically exported to MathML (thanks to @mkorje)

  • MathML defines how to render an equation, but also preserves its semantics
  • If you’ve previously relied on show rules that use html.frame to render equations to SVG, try MathML output. Switching to it will improve the accessibility of your document (though rendering will be somewhat less consistent across browsers).

• The box and block elements’ purpose is now aligned with paged export (Breaking change)

  • box is used to bring block-level content inline
  • block ensures inline-level content becomes block-level
  • Depending on the contained content, this may be achieved by setting the CSS display property or by wrapping in an additional <span> or <div>.

• The rules of how paragraphs are grouped in HTML have been adjusted to fix cases where paragraphs would appear unexpectedly (Breaking change)

  • The list of HTML elements that can be grouped into paragraphs was tweaked (it now includes all phrasing content with the exception of elements that default to display: none)
  • This default can be controlled by wrapping an element in a box or block as appropriate
  • HTML elements that cannot be part of paragraphs (like a <div>) do not immediately force adjacent inline-level Typst content to be wrapped in a paragraph; rather, they are considered neutral for paragraph grouping
  • Paragraph creation is only forced by block-level Typst elements (as opposed to HTML elements). Built-in block-level elements like headings or images wrap the HTML elements they create in block elements to force adjacent inline content into paragraphs. Package authors should do the same to ensure paragraph creation is consistent between HTML and paged export.
• The target function can now be used without the html feature flag (the rest of HTML export remains feature-flagged)

• DOM structure and built-in show rules

• Serialization

• HTML elements

• Whitespace handling

PDF

SVG

PNG

Command Line Interface

Deprecations

Removals

• The path element, use curve instead (Breaking change)
• The pattern type, use tiling instead (Breaking change)
• The pdf.embed element, use pdf.attach instead (Breaking change)
• The scoped functions cbor.decode, csv.decode, json.decode, toml.decode, xml.decode, yaml.decode, and image.decode; directly pass bytes to the top-level functions instead (Breaking change)
• Various previously deprecated symbols, see the removals section in the dedicated changelog for a full listing (Breaking change)

Development

Migration guide

This section walks you through changes you may need to make to your existing documents to ensure compatibility with Typst 0.15.

Typst 0.15 removes definitions from the Typst standard library that were already deprecated in previous Typst versions. If you are still relying on those, also refer to the Typst 0.14 and Typst 0.13 migration guides.

Baselines

Typst now retains baseline information in more parts of the layout engine (most importantly for boxes, blocks, list items, and equations). This may lead to silent layout shifts. These are generally improvements, but if you’ve previously counter-acted bad-looking output through explicit adjustments, you may need to revisit those.

In particular, Typst will now set the baseline of a box to the baseline of its first line of content and use it to align the box with its surrounding text. This yields better-looking output out of the box.

// Typst 0.15+
Lorem #box(inset: 0.3em, stroke: 1pt)[ipsum] dolor.

// Typst 0.14 and below
Lorem #box(inset: 0.3em, stroke: 1pt)[ipsum] dolor.

File paths

If you are using Typst on Windows, you may have used backslashes in your file paths. This syntax is not supported anymore. Consistent use of forward slashes ensures your document compiles on all supported platforms.

// Typst 0.15+ ✅
#include "chapters/introduction.typ"

// Typst 0.14 and below ❌
#include "chapters\\introduction.typ"

Moreover, the Typst CLI does not support non-Unicode input paths anymore. Such paths are exceedingly rare today.

Math glyph stretching

In mathematical typesetting, glyphs frequently need to be stretched to the size of some part of an equation. This primarily applies to brackets, but also accents, arrows, and more. In Typst, this happens implicitly through matched delimiters or explicitly through the lr and stretch functions.

Typst 0.15 makes some adjustments to how ratios passed to these functions are resolved. Previously, a size of 200% passed to lr.size or stretch.size would be interpreted relative to a glyph size that was potentially already affected by display sizing. Now, ratios are always resolved relative to the base glyph size. In practice, this means that, to retain the same appearance, you may need to increase the target sizes you’ve configured for glyphs that are already larger out of the box in display style (e.g. integrals).

Math delimiters as functions

In Typst’s math mode, various symbols defined in General Symbols can be called like a function, either to be applied as an accent or to delimit body content. Typst 0.15 extends this handling to additional delimiters like chevron.l. This can change the output of existing calls, which would previously fall back to displaying the parentheses (which would rarely have produced desirable output in the case of delimiters).

// Typst 0.15+ ✅
$ chevron.l(x) $

// Typst 0.14 and below ⚠️
$ chevron.l(x) $

Math classes

The class function defines how part of an equation should be laid out (primarily the spacing around it). In Typst 0.14 and below, the class function applied recursively: If applied to a larger piece of content, all items in it would receive the class. In Typst 0.15, the class is only applied to the directly wrapped content. This is mostly a bug fix, but can lead to subtle layout changes.

Calligraphic letterforms in the default math font

With the update to New Computer Modern Math 8.1.0, the default calligraphic letterforms were changed. The previous letterforms can still be accessed by selecting stylistic set 6.

// Typst 0.15, default style.
$ R != cal(R) $

// Typst 0.15, with stylistic set 6.
// Reproduces the default style from Typst 0.14 and below.
#show math.equation: set text(stylistic-set: 6)
$ R != cal(R) $

Paragraphs, boxes, and blocks in HTML

Typst automatically collects inline-level content into paragraphs. In Typst 0.14 and below, the exact same rules were used to collect inline-level HTML elements (e.g. a <span>) into Typst paragraphs, which in turn result in <p> elements. This had the unfortunate effect that even use of the low-level typed HTML API could result in <p> elements appearing automatically. Consider the example below:

#html.div({
  html.span[Hello]
  html.div[World]
})

Where Typst 0.14 would insert an unexpected additional <p> element, Typst 0.15 yields the expected result:

<!-- Typst 0.14 and below ⚠️ -->
<div>
  <p><span>Hello</span></p>
  <div>World</div>
</div>

<!-- Typst 0.15+ ✅ -->
<div>
  <span>Hello</span>
  <div>World</div>
</div>

This change in output is achieved through a few new rules for how paragraphs are collected in HTML export. Previously, Typst would always categorize elements into either inline-level or block-level. It would then force inline-level elements into a paragraph whenever at least one block-level element was present in the same flow of content. In Typst 0.15, elements can instead be considered inline-level, block-level, or neutral:

• Text, Typst box elements and HTML phrasing content (elements that are allowed as children of <p> elements) are considered inline-level¹
• All other HTML elements are considered neutral
• Typst block elements are considered block-level

Neutral elements don’t force adjacent inline-level content into paragraphs. They can co-exist with inline-level content in a mixed flow. This ensures that usage of the typed HTML API does not result in extraneous paragraphs.

Meanwhile, Typst elements that are block-level out of the box (e.g. heading) now explicitly use a block in their default show rule to ensure that they still force adjacent inline-level elements into paragraphs. This ensures consistency in paragraph grouping across paged and HTML export. Package authors should also explicitly use blocks when creating HTML components that Typst should consider block-level.

To make this change possible, the way boxes and blocks behave in HTML export has been adjusted: Instead of unconditionally wrapping their contents in a <span> or <div>, they now do just what is necessary to ensure their contents are considered inline- or block-level by browsers. If they contain multiple children, they still create a wrapper element, but for just a single child, they instead configure the CSS display property. And if the single child already has the appropriate display property by default, it is fully omitted. Then, the effect of the box or block is limited to influencing Typst’s paragraph grouping.

HTML script and style elements

The typed HTML functions for the HTML script and style element previously accepted arbitrary body content and then only failed during HTML serialization if the content resulted in non-textual elements. In Typst 0.15, they instead only accept strings in the first place. Note that you can also use them with raw syntax by accessing the .text field.

// Typst 0.15+ ✅
#html.style("a { color: red }")
#html.style(
  ```css
  a { color: red }
  ```.text
)

// Typst 0.14 ❌
#html.style[
  a { color: red }
]

Classes in SVG export

Typst 0.14 and below would generate the class attributes typst-frame, typst-doc, typst-group, typst-shape, and typst-text on SVG elements in SVG export. These are no longer emitted. If you are using the typst-frame class to style html.frame elements in HTML export, you’ll need to adapt your style sheet.

Variable font family names

Typst aims to unify different fonts from the same family under a single family name. To that effect, it automatically trims common style suffixes like “Bold” or “Condensed” from font family names. Instead of selecting these through the name, they should be accessed through Typst’s built-in mechanisms (such as the weight and stretch parameters).

In Typst 0.15, the additional suffixes “Variable”, “Var”, and “VF” are trimmed to unify static and variable fonts into a single family. If you’ve previously used a font with any of these suffixes in its family name, you should now omit the suffix when specifying the font.

Upcoming raw language tag changes

In the next Typst version, we will make a change to how raw language tags are parsed. Should this upcoming change have an effect on your document, the compiler will already warn you today and suggest how to adjust your document to future-proof it against the change.

Numbering fallback for the number zero

Not all numbering systems can express the number zero. In Typst 0.14 and below, those would silently fall back to Arabic numerals for 0. This behavior is deprecated in Typst 0.15. Using zero with these systems will become a hard error in the future.

Tightened validation in some functions

The array.slice function, str constructor, and text.features parameter now perform stricter validation on their inputs. If you’ve previously passed invalid or nonsensical input, you will now receive an error.

Renamed citation styles

Typst 0.15 renames some citation styles to stay aligned with upstream CSL changes. If you are relying on any of these, the compiler will warn you and suggest the new name.

Renamed symbols

Typst 0.15 also renames a few symbols in General Symbols. If you are using any of these, the compiler will warn you and suggest the new name.

Contributors

Thanks to everyone who contributed to this release!