typst / typst/typst

Customizing source line break behavior

Open
#710 18 comments 20 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

feature request syntax
Dominant language
Rust
Stars
56.1k
Forks
1.7k
Avg merge
3d 10h
Merged PRs (30d)
22

Description

I don't know if this is possible and if there is demand but:

Current line breaking behavior

source compiled
\n [ ]
\ linebreak()
>1 times \n parbreak()

Want to be able to customize it to

source compiled
\n linebreak()
> 1 times \n parbreak()
\\n continue line

or maybe even

source compiled
\n [ ]
\n\n linebreak()
>2 times \n parbreak()
\ linebreak()

Bonus if this behavior can be changed depending on the context (e.g. in a paragraph vs table cell) and if rules for trimming line breaks in certain contexts can be defined.

Doing this in Typst code right now is almost impossible, mostly because

  • show rules like #show regex("\\s"): white_char => ... never capture line breaks in the source
  • \n gets compiled to [ ] (making it indistinguishable from many other things that generate [ ])
  • the content tree is currently not well traverseable and mutable.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing how source line breaks are converted into [ ], linebreak(), and parbreak(), then inspect the show-rule and content-tree limitations described in the issue. Done means defining customizable mappings for line breaks, including context-sensitive behavior and optional trimming rules, with coverage for the requested paragraph and table-cell examples.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
compilers
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.