Community

[prime robin]

that makes sense to some degree, i wonder why it wouldn't remove theoutside contributor status from bluss for example since he's a member now

I'm also shown under direct access for tytanic but I'm not listed as an outside contributor

nvm

I thought it was bluss because of the similarity in the pfp, but it tuens out i was looking at ntjess

[prime robin]

no i didn't 🤨

[dense vale]

shiroa gh-pages sounds nice do we just translate the markdown in org to typst then serve it from there?

[prime robin]

That would be my guess, I never actually used shiora, perhaps we should add a setup-shiora repo for CI similar to setup-typst?

[dense vale]

nix

@daring nymph do you have an example of shiroa deployed on gh pages

i guess its in the repo itself?

https://github.com/Myriad-Dreamin/shiroa/tree/main/github-pages

https://github.com/Myriad-Dreamin/shiroa/blob/main/.github/workflows/gh_pages.yml

nix

@prime robin nix?

[prime robin]

I'm not following let me read that first

[dense vale]

just building a static bundle then uploading to gh pages

      cargo run --release --bin shiroa -- build --font-path assets/fonts --path-to-root /shiroa/ -w . github-pages/docs --mode static-html

[prime robin]

Seems simple enough

We'd have to install shiora obviously, but after that it's the same

Not sure what you mean with nix though

[dense vale]

u not use nix?

build shiroa with nix using buildRustPackage and have a derivation to build the static bundle

[prime robin]

i never used nix in CI

[dense vale]

then call nix using detsys action

[dense vale]

but its perfect!!

[prime robin]

😆

[dense vale]

https://github.com/DeterminateSystems/determinate-nix-action

the beauty of this is that you get to have one, reproducible environment for both CI and development

it's quite surprising you never did use it

[prime robin]

I only "recently" started using nix

[dense vale]

oh

makes sense

[prime robin]

and when stuff in CI works i have no reason to switch

[dense vale]

makes sense

[prime robin]

and the reason i wanted to create a simple setup-shiora action was to make it avaialbe for non-nix users too

[dense vale]

fair

[prime robin]

we can still use nix down the line

I never wrote gh-actions myself though

[dense vale]

shiroa is pretty self-bootstrapped with it getting typst from typst-ts right? its just vendoring shiroa and making some options available

[prime robin]

(I have also not used that before)

But i figured it was about time

[dense vale]

huh

it's not using typst.ts but typst compiler directly? interesting

still doesn't require getting typst compiler which is nice ig

[prime robin]

Might be a recent thing because of HTML export

[dense vale]

right

wait no

new name for myriad's compiler library: reflexo-typst

idk im confused

still the typst compiler is bundled thats all what matters

and all the setup has to do is get shiroa and make its cli options available as yaml

[prime robin]

OK I'll check out shiora first and see if i can get it setup in tytanic CI to understand what i need to provide

[keen gorge]

Hi! I notice that the README in this repo writes “You're probably looking for typst.community/typst-docs”.
https://github.com/jcbhmr/typst-docs
Is that related to us?

[prime robin]

Yes, jacob is a member on the org

[keen gorge]

So did the project continue? https://typst.community/typst-docs is 404 now.

[prime robin]

hm

[keen gorge]

I can't find any clue in the org either…

[dense vale]

no it didn't proceed

[prime robin]

setup-typst has its own package caching, if we extracted that we could re-use it for other actions more easily

Ah but then the cache action would need typst to create the cache

[daring nymph]

you can setup shiroa by the installation script. the remaining things are installing fonts and call the shiroa build command. the gh_pages.yml of tinymist or typstyle could be examples.

[prime robin]

I've got something half working for tytanic on https://github.com/typst-community/tytanic/tree/tinger/mprpuqlkmttl and I'll use that to reverse engineer the rest from the examples on the tinymist and other repos

[ornate condor]

tingerrr

[org] Discussion #19 marked answered: Ecosystem Team Pre-Nominations

@sitandr has noted before that they're not very active at the moment, so I'd say we skip the pre-nomination for them for now. With that said, I'll discuss the length and conditions of the actual nomination and voting process on the forge, and we'll continue from there.

[prime robin]

During next week we should start the nominations proper, with a reasonable time window and threshold for nomination.

[heady grove]

Hey everyone, I just noticed I've been actually mentioned in that Pre-Nomination thing and should have had either agree or disagree to nomination.

So, just in case, can I still agree, or is it closed now? Or it doesn't really matter?

Sorry for being late. :(

[prime robin]

You're late but you can just self nominate later on

The thing is that if we have to wait 5 days for your vote on an RFC, then maybe the ecosystem team isn't the right fit?

[heady grove]

I guess you are right. Yep.

[prime robin]

Ok, what do you guys think we should do for the nominations, I'll write down my thoughts. These are suggestions not hard rules by any means:

• Similar time frame to the admin nomination, i.e. around 4 weeks.
  • This includes both nomination and voting. There should be no separate timeframe for either phase.
• Allow non-self-nomination, imposter syndrome affects many, let's not deprive the team of excellent members this way.
  • Similar to the pre-nominations someone can simply turn down a nomination anytime until the vote finishes. Votes are not transferred.
• How do we actually handle derive whether someone is added from the votes they receive?
  • Define a threshold of maximum members and order all users by their received votes, take the first N users.
  • Define a threshold of votes required to be added.
    • How high should the threshold be? It could be a fixed number or a percentage of the highest vote.
  • Depending on the number of non-pre-nominees we could delay that decision, but this could be seen as disingenuous, if it ends up disqualifying a popular nominee.

The end goal is to have a team of people who can represent not just the north-western community, but the eastern and southern communities too. Perhaps so we should designate some form of minimum number of representatives for certain regions? But maybe that's not necessary, what are your thoughts?

I also think that we should, where possible, keep the team size relatively small if we stay with one team. However, we could just go with splitting the team by responsibilities later if we realize that managing votes with too many members becomes too hard. This would mean sub teams, either as previous proposed or in a different manner.

Maybe I'm also overthinking this and it's not that deep, but with the community growing I would like to keep this as transparent as possible.

[keen gorge]

The end goal is to have a team of people who can represent not just the north-western community, but the eastern and southern communities too. Perhaps so we should designate some form of minimum number of representatives for certain regions? But maybe that's not necessary, what are your thoughts?

I agree, but I think it isn't a main matter at present.
If we find that a certain topic requires consideration of a specific language/script, we can temporarily @ and call on native speakers.
But a committee like the United Nations General Assembly is not necessary or feasible for the time being.

I quickly scan existing RCF ideas #4, and find the following topics might need special consideration on internationalization.

• People names: Not all languages have the concept of family name and given name. See https://www.w3.org/International/questions/qa-personal-names.en
• Doc Comment: Not all languages separate words by spaces.

At present, RFC ideas are mainly about software design rather than typography. If there is typography in the future, https://www.w3.org/International/typography/gap-analysis/language-matrix.html would help.

[prime robin]

Good points, regarding doc comments I would say that that shouldnt be much of a problem, the newer doc comment syntax as it was proposed in the linked PR was almost entirely regular typst, with the only special syntax being -> at the start of the last line

[flat bane]

#discussions message

sans and mono elements for adjusting text styles the way emph and strong do.

[fresh frigate]

does raw not work for mono?

[prime robin]

It's not just mono

[fresh frigate]

Personally, I think raw, emph, and strong are semantic. sans and mono are style. I don't think they should be treated the same way

what would a sans element do if the font is already sans? how does the sans element choose its font? how does it handle #sans[some #sans[text] here]?

[flat bane]

I partially agree. You could see sans as a different form of emph, where the point is not that it's sans but that it is emphasized differently. The way I "proposed" it (or rather, brought the need up in a relevant place) is not really analogous to the elements I mentioned, the usage I expect would look similar though.

[crisp summit]

If we go one step back I think the problem was - can the template configure a serif font and a sans font once. Then the template applies those serif and sans meta styles in various places. Let's say for example show heading: sans.

there's nothing in that use case that says it has to be a sans element. If there are other ways to do it

[fresh frigate]

I would indeed like a way to set font families. CSS has serif, sans-serif, monospace, cursive, fantasy, system-ui, ui-serif, ui-sans-serif, ui-monospace, ui-rounded, emoji, math, fangsong. I think the ui versions could be replaced for a display version in typst, and math could be split into math-serif and math-sans-serif

[flat bane]

There's nothing evil about non semantic elements. It's just that my equating sans with emph was misleading in that regard.

[fresh frigate]

Ideally, I would like to be able to use them both as #serif[some text] and as #set text(font: serif), and I would like them to have pre-set fallbacks if they weren't defined by the user

[crisp summit]

I haven't thought/said anything about evil either 🙈 I don't know but I think an element is a good way to handle it. What's another example of a non semantic element?

[daring nymph]

to imitate that we did in color, font.serif might be better.

#import font: * // imports serif, monospace, etc.
#serif // Libertinus Serif
#type(serif) // font
#set text(font: serif)

[fresh frigate]

Unfortunately, typst only has a handful of built-in fonts. My choice of defaults would be something like:

• serif -> "New Computer Modern"
• sans-serif -> No built-in sans font :/
• monospace -> "DejaVu Sans Mono"
• cursive -> No built-in
• fantasy -> No built-in
• display-serif -> serif
• display-sans-serif -> san-serif
• display-monospace -> monospace
• emoji -> I don't know what typst does for emoji fonts, I never use them
• math-serif -> "New Computer Modern Math"
• math-sans-serif -> No built-in
• math -> either math-serif or math-sans-serif depending on the text around it
• fangsong -> No experience here either

Maybe templates could also add arbitrary font families, like uncial?

[prime robin]

I'm sure @tame widget would be delighted to have something like this, he's been requesting loading fonts into well typed objects for a while now.

[prime robin]

Perhaps sans a should be builtin?

It seems to me a fairly common thing to use for headings and other non-paragraph text

One might wonder how many of those ought to be builtin, I don't think many of these hold their weight (like cursive or fantasy).

I can't comment on the necessity of the math fonts, that's @sullen pivot area of expertise.

[daring nymph]

There was a font object PR that we would like to merge, but that was closed because laurmaedje is not satisfied with too many unsolved design problems about the font type.

[prime robin]

I see

Fonts are fairly messy from what I understand seems hard to get right.

[tame widget]

some called my name ?

[fresh frigate]

I would for sure like a built-in sans font. Honestly, I think the whole New Computer Modern`family should be built-in, except maybe for uncial. That includes serif, sans-serif, their respective math styles, and monospace

[daring nymph]

The main problem is that font is not element but you may love to have set rules over fonts, like #show text.where(font: math): set font(baseline: -0.1em).

[tame widget]

ah ... ok ... if it cannot be filled by NCM family, it might be sufficient to use the TeX Gyre ones

[prime robin]

I don't think this necessarily needs a font element, just a text selector that can distinguish where the text element is used no?

[fresh frigate]

can you not set text(baseline: ...) or something here?

[tame widget]

there are even TeX Gyre Math variants – https://ctan.org/tex-archive/fonts/tex-gyre-math

[daring nymph]

@prime robin probably not. The origin problem is that I find the baselines of text and raw fonts are not matched, and I would like to adjust baselines by fonts (english text, chinese text, raw, math, emoji, and so on).

[fresh frigate]

does #show text.where(font: "DejaVu Sans Mono"): set text(baseline: -0.1em) not work?

[tame widget]

that would imply that you know the current font names set by the user for the purpose, in a templete somewhat useless ... having the actual names used by the engine makes sense

[daring nymph]

In the concrete case, chinese text's baseline are always higher and it looked ugly. The solution without changing typst are either editing fonts (the hacky way) or using the specific ones used by ctex.

[daring nymph]

?r

#show text.where(font: "DejaVu Sans Mono"): set text(baseline: -0.1em)

test
`123`

test
#text(baseline: -0.1em)[`123`]

[crisp summit]

How do we extend this to make them configurable? Because we can't reconfigure which red and blue to use, so I don't see the direct connection to colors 🙂

[fresh frigate]

but adjusting baseline like that only makes sense for specific fonts

not for general font families

[daring nymph]

Not all the same. font.serif only imitates the color presets or color map presets are put under the color scope I think.

[fresh frigate]

This looks like what you wanted, no? I believe in the previous example both "123" and the kanji are using "libertinus serif" as their font, so you could not use a font selector for that

[tame widget]

step away for this specific baseline example and notice the various capabilities it would enable

[daring nymph]

no the screenshot shows that the show-set rule doesn't take any effect.

?r

#show text.where(font: "DejaVu Sans Mono"): set text(baseline: -100em)

test
`123`

test
#text(baseline: -1em)[`123`]

[fresh frigate]

that's true, I misread the example

?r

test
#text(baseline: -1em, font: "DejaVu Sans Mono")[123]

#show text.where(font: "DejaVu Sans Mono"): set text(baseline: -1em)

test
#text(font: "DejaVu Sans Mono")[123]

[daring nymph]

I just find that I made mistake and wrote show text: set text which is not well defined yet, but it is actual hard to adjust baselines by fonts from my limited knowledge.

[prime robin]

ah yes, that makes sense

[fresh frigate]

Do you have any examples where it would be useful to select by font-family, instead of by specific fonts or by semantic elements?

[tame widget]

one particular thing that comes to mind would be:

if(used-font == fonts.serif) 
{
 ... do/set something
}
else if(used-font == fonts.sans-serif) 
{
 ... do/set something
}
else if(used-font == fonts.monospaced) 
{
 ... do/set something
}

[tame widget]

i like the enum of those types

but if those fonts object exist, would also like to be able to:

#set fonts.serif("<family>" | font-struct)

to make them being used by typst

with font-struct being am object that describes the composition of the family (files, styles, weights, variants, etc)

the most flexible way would be that it could also take a function that take proper font parameters and returns the right family or font-file

[prime robin]

I think we're long in #1184433451554840636 territory

The original question was (to my understanding) whether there should be some form of standardized elements (whether that be elembic now and built-in later is not as important) which tempates should agree on and be able to configure uniformly.

Some of which could be builtin

[tame widget]

sorry for me dashing far ahead of the OP

[prime robin]

no worries, I'm just worried it'll get lost here when people expect to see this in #1184433451554840636, since not every font-affine person may be in here to see this

[tame widget]

but i can only second that this standardization would help

[prime robin]

I believe so too, this is one of the things that's also fairly easy to implement simply by publishing a package under the community org.

Ill add this to the RFC ideas

[tame widget]

one issue i see is the distinction requirement for CJK ... i dont think that it should be generalized as fangsong

correct me if i am wrong but generally that definition has been split into:

• chinese-traditional (cjk-tc)
• chinese-simplified (cjk-sc)
• korean (cjk-kr)
• japanese (cjk-jp)

if i am not mistaken that is also the distinction that both Adobe Fonts and Google Fonts uses.

[tame widget]

hmm ... but that is an unicode problem which can be solved by fallbacks ... so fangsong may actually make sense.

[solid umbra]

i guess this goes to show elements are often hard to design in a semantically consistent way

at least templates have it easier if you use elements to simply design specific parts of a template

but something that could be interesting would indeed be able to "label" fonts

in principle i dont see why this should be restricted to e.g. serif / sans / mono / ..., since each template is gonna handle it differently so they might have their own classes

in my template (no elembic) i ts just a dictionary

so in principle i think one fonts element per template is appropriate

its fields are the fonts used by the template

for other fonts, just use typst's built-in stuff

maybe not element but custom type etc

[tame widget]

hmm ... that could mean also branch out to the actual layout-objects produced from markup mode ?

[solid umbra]

pardon?

[tame widget]

eg like fonts.header or fonts.code or fonts.blockquote ?

[solid umbra]

at least the way i do it is something like

oh no

im not discussing per-element fonts in principle

it could be used for that through show-set, but im thinking more generically

[tame widget]

which is a good thing

[solid umbra]

if you think of fonts as just a dictionary, you can just do text(font: fonts.serif)[stuff]

of course, your template could provide a shorthand for that

[tame widget]

but someone might cook up something like:

#show text.where(fonts.code): set text(fonts.monospaced)
#show text.where(fonts.header): set text(fonts.serif)

(may not be valid typst)

but at least the header part could be rewritten to:

#show heading: set text(fonts.serif)

but the semantics of the rewritten code is not equal to the above ...

• the original code means: use for any occurrence of header font the serif font
• the rewritten: use for heading the serif font

if table.header need to be matched as well, the rewritten code fails to do so.

[solid umbra]

i think that goes to show that using a "header font" is a bad idea

for elements use show-set

[tame widget]

depends on the use-case

[solid umbra]

named fonts make more sense when a style mandates it

for example, your style might mandate Arial for sans and Times New Roman for serif

and say , use sans here, serif there

so you might just want to change the specific sans font, without changing where sans fonts are used

with that said, its true that using a sans element would allow for a similar effect

[tame widget]

depending on how much abstraction you need to put into it.

but basically you are right

but does this not lead to the question if template authors should provide a semi-standardized init/setup/config method ?

[solid umbra]

this is more or less what we've been thinking about here, yeah

in parallel to the examples discussion at least

[tame widget]

so we are on the same page

[solid umbra]

at least some sort of guidelines on how to write templates using custom types / elements

[tame widget]

so along the lines of:

#import "some/modules/or/template/path": mt
#mt.setup(...config...)

[crisp summit]

if I understand correctly, such setup can only be used for setting state (?) and isn't that the wrong direction for the future

[solid umbra]

i think they just forgot #show:

nobody is gonna do that cuz you cant apply set rules like that

with that said, thats basically how any template works today

but with elements / custom types you'd be able to use set rules instead

as seen here https://pgbiel.github.io/elembic/examples/simple-thesis.html

[tame widget]

depending on the mode(s) you use.

in my use-case its:

• ~2% — rules
• ~30% — markup
• rest — procedural/functions

that is due to my workflow setup of pandoc -> lua-filters -> typst.

[oblique star]

I'm starting to write proper docs with shiroa for utpm
I'm gonna describe :

• how to use every command and their interaction between them,
• how to contribute and how it works under the hood
  Do I forget something?

[prime robin]

Depends on the complexity of utpm, for tytanic I separated the book into three parts:

• Quickstart for the bare minimum required to install and use tytanic.
• Guides in-depth but non-technical tutorials for specific use cases (how to write tests, how to use test sets, how to use tytanic in CI, etc.)
• Reference in-depth technical documentation like the test library API reference, configuration schema or test set DSL grammar

with a single intro chapter before all of them that explains what tytanic is useful for and how to navigate the book

for reference: https://typst-community.github.io/tytanic/

I would probably go with the same structure if i had written utpm

[oblique star]

thx! I'll go on this

would it be possible to upload it too on typst-community? I'll host it too on my website but I prefer using officials resources

I had hard time to write this message lmao, I was focus on la casa del papel

[prime robin]

You can just use gh pages

[oblique star]

yes gh pages, not the website itself 😭 😭

[prime robin]

Yeah I mean you already have the repo on the org so this naturally follows

It automatically puts it there

[oblique star]

first time using it, i'll check how to use it

[prime robin]

You can steal my workflow and adjust it to shiora but I am currently also rewriting it to use shiora so maybe we shouldn't duplicate work

[oblique star]

Duplicate work?

We could use the same template but I don't see anything else duplicated

[prime robin]

I mean there is not shiora gh action yet and I plant to do the work for it

[oblique star]

Aaaaaaaah

[prime robin]

With tytanic to test it

[oblique star]

Could we create an action then?

[prime robin]

Because shiora just compiles itself in CI for example

[prime robin]

That's the plan but I opened an issue on setup-typst to extract the package caching first

[oblique star]

Put me in when we can make the action

[prime robin]

Bump on this as the font discussion kinda derailed in between that

[prime robin]

I would like to start the nominations on Monday, it would be great if we could come to a consensus about the process until then.
I mentioned the current team for now, but everyone else can also chime in. Please refer to the message I replied to above.

cc: @dense vale @daring nymph @flat bane @tough crown @heady grove @hybrid moat (can we kick the old one lol, i never know which one it is)

[flat bane]

I'm on vacation until Tuesday so a bit slower to respond, and writing shorter messages

• four weeks sounds good
• "turn down a nomination until the vote finishes" practically speaking a person can decline even after that. The sooner the better for the process of course
• what the results mean is the tough one. The sign off on RFCs is 2/3, so we don't need an odd number to avoid stalemate. I lean towards a vote threshold, but am not sure what it should look like.

[prime robin]

Yeah, the second part is just weirdly phrase on my part I guess. For the third part, I'm also unsure how to do that, that seems like the hardest part, perhaps I'll look at what jj did for their governance stuff.

[prime robin]

As for Jujutsu: It appears that the initial two maintainers decided in private who was added which is also an option, though less open as I'd like.

the link leads tot he nomination thread

[prime robin]

Heads up, only mildly related though: I moved the guidelines repo to package-api-guidelines removed the outdated style guidelines and added a note about RFCs being used to change parts of this. I'll finish the setup-shiroa action tomorrow, at which point the doc is ready to be rewritten to be hosted with shiroa using github pages.

The shiroa action could then also be used for a book containing the RFCs if we decide to go with typst for them instead of markdown.

[oblique star]

perfect! thx!

[oblique star]

I'll check later, but I'm always in

[tame widget]

if the signoff is 2/3, maybe the threshold should be 3 cast votes (i see 6 nominees, so that should be 50%)

[prime robin]

Man, doing stuff on windows is truly like you're fighting ghosts, somehow in setup-typst they dont' need to adjust he output path of tool-cache.extractZip, but for typst-shiroa I need to, but only on windows

So many initial commits

[daring nymph]

is there improvement point of shiroa-cli?

[prime robin]

No it works just fine in CI once installed

[ornate condor]

tingerrr

[typst-community/setup-shiroa] Now open sourced!

[prime robin]

Man windows really is so bad

how do i remove a directory when it exists and ignore it when it doesn't without learning powershell

[ornate condor]

tingerrr

[typst-community/setup-shiroa] New release published: v1.0.0

[prime robin]

Ok the action works in tytanic, but shiroa has some issues itself, it seems its missing the html support module in the 0.2.3 version of the package, that's fixed on main but isn't yet released

@daring nymph I assume you're bumping the package before you release 0.3.1?

[daring nymph]

havenot release yet. html support is only available on main branch

[tacit nymph]

somehow missed the existence of setup-typst completely, does it cache the typst installation? cause I did write my own workflow at some point that runs on every push and compiles a typst file and pushes back the PDF but it does wget to the typst binary everytime

[prime robin]

It does yes

[tacit nymph]

name: Build thesis with Typst

on: push

jobs:
  build:
    name: Install Libertinus fonts & compile document
    runs-on: ubuntu-latest
    permissions:
      contents: write
    steps:
      - uses: actions/checkout@v4
      - name: Install Libertinus and code fonts
        run: |
          wget https://github.com/alerque/libertinus/releases/download/v7.040/Libertinus-7.040.zip
          wget -O Inconsolata.zip https://github.com/googlefonts/Inconsolata/releases/download/v3.000/fonts_ttf.zip
          unzip -d inconsolata/ Inconsolata.zip
          unzip -d libertinus/ Libertinus-7.040.zip
          mv libertinus /usr/share/fonts
          mv inconsolata /usr/share/fonts
          fc-cache -fv
      - name: Install Typst
        run: |
          wget https://github.com/typst/typst/releases/download/v0.13.1/typst-x86_64-unknown-linux-musl.tar.xz
          mkdir typst
          tar xf typst-x86_64-unknown-linux-musl.tar.xz --directory=typst
      - name: Compile document
        run: |
          cd typst/typst-x86_64-unknown-linux-musl
          ./typst c ../../thesis.typ ../../thesis.pdf --font-path="../../template/"
      - name: Push back to repository
        uses: stefanzweifel/git-auto-commit-action@v4
        with:
          commit_message: ${{ github.event.head_commit.message }}
          file_pattern: '*.pdf'

[prime robin]

using @github/tool-cache

[tacit nymph]

this is what i had

ah nice

[prime robin]

It also had a fontist example

for installing fonts

[tacit nymph]

yea i used wget on those too lmao

tbf it still only took at most 30 seconds so it was still nice to always have the most recent version of my thesis there just in case

so does it push back automatically? i can see the section about storing it in workflow artifacts but where does it go if we just use the basic usage example

[prime robin]

It was already in the package but not exported, was that intentional?

[prime robin]

nowhere

[tacit nymph]

ah so by default it just checks if it compiles

yea makes sense for CI

[prime robin]

if you want to add files back you'd have to add a new commit inside CI

github pages does this with its orphan branch

[tacit nymph]

i suppose I could just reuse this bit

      - name: Push back to repository
        uses: stefanzweifel/git-auto-commit-action@v4
        with:
          commit_message: ${{ github.event.head_commit.message }}
          file_pattern: '*.pdf'

[prime robin]

yeah

[daring nymph]

It was not ready. I will export it in v0.3.0

[prime robin]

0.3.1 you mean?

hence my question regarding another bump before that

[daring nymph]

the package is v0.2.3

[prime robin]

ah ok

confusing

[daring nymph]

I thought I can align the version between the cli and the package, but I didn't do that. If I did, I have to publish the package whenever I release a patch version of cli. I don't like the experience of publishing packages..

I really miss a typst publish command.

[prime robin]

Yes, perhaps typship can make this easier, but fi the release is empty I also wouldn't release it

It's similarly hard to sync tytanic or tinymist to typst

[daring nymph]

And that means "I didn't forget to release typst package v0.3.0".

[daring nymph]

I tried typship and it isn't an one-shot solution.

[prime robin]

Yeah of course, without the infrastructure on Typst's side it can't be

Tbh, I still just manually copy the files when I do an update

I found that the package managing tools don't save me enough work to warrant installing them

[daring nymph]

I also noted typst-package-template have some magic CI. I could give a try :).

[prime robin]

For a second i looked at the github action and thought i mispelled shiroa

my heart dropped

[oblique star]

Did you make a new discussion / issue for the nomination?

[oblique star]

I fought for about 10 mins with my terminal because I misspelled shiroa

I understand your panic

And I'm back, I was out for a week

[prime robin]

Not yet

There are still unanswered questions

[ornate condor]

tingerrr

[typst-community/setup-tytanic] Now open sourced!

tingerrr

[typst-community/setup-tytanic] New release published: v1.0.0

[flat bane]

I think gh discussion comments automatically have one upvote by oneself. Assuming we don't count that: I feel like 3 is a bit little; we have 12 pre-nominations who personally confirmed their status (https://github.com/orgs/typst-community/discussions/19). We don't need to set a threshold to make it exclusive, but it also feels a bit silly to set the threshold so low that being nominated is practically a guarantee to also get enough votes.

Also I just realized that the original post (link for easier reference: #1194684809906237500 message) didn't specify how people voted I think. If it's discussion upvotes, that means everybody can vote for each candidate. Other options could be giving each person n votes, or each person assigning 1 to n points to their preferred candidates. All of these require more organizational overhead of course...

[prime robin]

@flat bane the tytanic action should make the package template CI easier since we don't need ot distinguish between source na dbinary isntall for pre-releases I think

[flat bane]

Yeah just seen it, will make a PR after my vacation (unless you're quicker :P)

(Although I think the need to distinguish was fixed through https://github.com/taiki-e/install-action/pull/868)

[prime robin]

(I'm faster)

Interestingly I have a merge button despite not being collaborator, I don't think that should be a thing just because I'm org admin

Imagine opening a few PRs some on your repos and some on others and you accidentally merge on one that isn't yours

[flat bane]

Yeah being an org admin would do that..

It's often so annoying when you try to setup permissions or something and can't see yourself if what you did worked, because you're not affected by the settings... (goes for github, moodle as a teacher, Google workspaces, ...)

[prime robin]

discord at least has a view as role feature for this

[flat bane]

Moodle too, but it's incomplete. Like, I can check what students can see but not how the submission workflow looks since I can't actually submit. I guess that makes sense, but it's still unfortunate and makes the job harder...

Anyway #off-topic 😛

[prime robin]

How do we feel about a nursery team for unmaintained packages/tools that were transfered to typst-community? Valkyrie is on very low maintenance at the moment an I'm only really fixing egregious bugs when theyre reported. A team would make access rights easier for people to fix a thing or push a release every once in a while.

[prime robin]

@elfin sparrow would you consider valkyrie to be unmaintained at this moment?

@oblique star same question but for utpm, you mentioned you're working on it again though, so I'm unsure.

[oblique star]

I'm working on it yeah

[oblique star]

Could be very interesting, just to remove bugs

[prime robin]

So I can consider it maintained?

[oblique star]

I'm planing a 0.2 release soon

[prime robin]

Ok, good to know

[oblique star]

yes!

After september I can't say, I'll focus my master's degree first

But I'll always be there to fix bugs and be there for rfc

Not for creating features

[prime robin]

It's just for now so that i know what repos may require nursery attention and which can be added to the org repo governance table

[oblique star]

No problem!

I don't mind people helping me but it's not urgent at all, AI helps me a lot when I can't handle the work

[oblique star]

If you need any opinion, please do not hesitate to contact me, I will be there

[prime robin]

first PR i don't let review and it has an error

good job tinger

[oblique star]

krkrkr I feel that

[prime robin]

I mentioned the wrong thumus too

[oblique star]

Yeah I got doppelganger

On what repo/discuss?

founded

[elfin sparrow]

yup, and having looked at it on the newest pre-release it looks like its broken in the next typst version too

[prime robin]

Ah

I'll take a look next week then

[elfin sparrow]

Thanks

[prime robin]

To come back to this, I was thinking keeping it simple and using a the discussion votes, I don't think somebody voting for all candidates is a problem, neither in practice nor in theory.

On the administrator nominations I received 12 upvotes, So I think we can expect around ~10 per person to seriously consider?

I still wonder if we should put a cap on the amount of users in the team. I can totally see all 12 people getting enough votes.

12 People is quite a large team to have for final decisions which are meant to arbitrate.

So far my main concern is the team becoming too large, not too small.

[oblique star]

Working!

utpm -o json pkg get cetz | jq .fields.message -r | jq
{
  "name": "cetz",
  "version": "0.4.1",
  "entrypoint": "src/lib.typ",
  "authors": [
    "Johannes Wolf <https://github.com/johannes-wolf>",
    "fenjalien <https://github.com/fenjalien>"
  ],
  "license": "LGPL-3.0-or-later",
  "description": "Drawing with Typst made easy, providing an API inspired by TikZ and Processing. Includes modules for plotting, charts and tree layout.",
  "homepage": "https://cetz-package.github.io/",
  "repository": "https://github.com/cetz-package/cetz",
  "keywords": [
    "draw",
    "canvas",
    "tree"
  ],
  "categories": [
    "visualization"
  ],
  "disciplines": null,
  "compiler": "0.13.1",
  "exclude": [
    "/gallery/*",
    "manual.pdf",
    "manual.typ"
  ],
  "updatedAt": 1753175823
}

A bit complicated to parse but using tracing I can't find anything else

[flat bane]

So with a limit, basically the question is whether to have

• up to 12 (need 8 for sign off)
• up to 10 (need 7 for sign off)
• up to 9 (need 6 for sign off)
• up to 7 (need 5 for sign off)
  I'd prefer some other voices chiming in in this regard though, since I feel it's pretty impactful.

Do you know how large the Rust teams are tinger?

[oblique star]

That's a good idea, I know I will not be useful everywhere

Felling the same silly

[prime robin]

The differ wildly, the compiler team has a whopping 60 members, while the library team has 6

Language and dev team also have around 5/6

It seems the compiler team is the outlier

https://www.rust-lang.org/governance

I suppose the compiler team is this large because it specifically manages compiler internals and optimizations, RFCs never target these areas, but features of the language mostly

[elfin sparrow]

When we launching the crypto decentralised autonomous organisation >:) (before anyone takes me seriously: no)

[tight schooner]

(note that for RFC/FCP decisions, as far as I know, the compiler team has a subteam https://www.rust-lang.org/governance/teams/compiler#team-compiler-fcp which is responsible for signing off and has currently 14 members. See e.g. https://github.com/rust-lang/rfcs/pull/3791#issuecomment-2764604164.
Maybe the chapter "Final comment period (FCP) reviewer" in https://github.com/rust-lang/rfcs/blob/master/text/3599-compiler-team-reorganisation.md can add relevant context, e.g. "[...] To function effectively, it is recommended that there be 4 - 8 FCP reviewers at any time, so that there is sufficient diversity of perspective. This is not a strict upper bound [...]")

[prime robin]

I see

So that seems like a good bound to have for now perhaps, as a lower bound that is

Though more than 8-10 still seems fairly large

[prime robin]

I think we should go with those bounds for the initial team and then go with ranked voting:

• votes = upvotes - downvotes
• order candidates by votes
• filter out candidates who reject nomination
• take the highest 9 ( 9 * 2/3 = 6)

To throw some concrete numbers into the room

Means that RFCs require 6 out of 9 yes votes to be merged

[fresh frigate]

How do you handle abstentions?

[prime robin]

In the RFC voting process? That's a good question I don't think it was explicitly written down yet.

The rust RFC process that we took inspiration from doesn't seem to handle this at all, I assume that doesn't really happen much in their teams.

I would say that counts the same as a no.

[flat bane]

For the FCP sign off we need 2/3 members. If we have them, whether the other 1/3 would have voted against our was absent shouldn't matter.

For the member voting I'd say it's similar: there's no need to specifically differentiate why someone got more or fewer votes.

[fresh frigate]

I was thinking RFC/FCP. Just thinking about what the 2/3 would mean realistically. That might incentivize people to vote yes on RFCs they don't fully understand, just to not block something the team seems to want

[prime robin]

Maybe, but I don't think that would realistically a problem, if people have concerns they should voice them and vote no

[fresh frigate]

I mean, suppose it is an RFC one understands little about. Not in favor, not against. One would rather let other people decide. Should one abstain (vote no) without any concerns, or vote yes without actually being able to analyze the RFC?

[flat bane]

I see it similarly (to tinger). The intent is that the 2/3 are a threshold for cases where consensus can absolutely not be reached, but usually almost all people on the team should already agree before going for the FCP.

Maybe we could add a note to the process emphasizing that people not positively in favor of an RFC based on a thorough understanding of it should not try to "make it move along" by voting yes.

[flat bane]

Definitely abstain. If not 2/3 of the team understand it, it's simply too early.

[prime robin]

I think the RFC has failed if a team member has problems understanding it

And should absolutely not be merged, since the chance of non team members understanding it would be lower still

[fresh frigate]

I was thinking more of "can't foresee the consequences/comprehend the nuances" rather than "can't understand what the RFC itself is". For a toy example, an RFC related to CJK only, and a reviewer has zero experience with CJK

[prime robin]

good point

I'd say this is one of those points where a dedicated team would be good

But on the other hand I don't think we will have region specific RFCs at first

and if some pop up this can be revisited

[fresh frigate]

The region specific example is just that, an example. It could be a math proposal and a member who only writes fiction and knows no math, or any other "niche". I believe the idea of the team is to have diversity of POV, and sometimes the POV is "I don't know"

[prime robin]

Well truth be told I was mostly thinking of RFCs bein targeted at thing like tooling, packages and the like, i.e. being mostly about the programming and ecosystem part of Typst

There are definitely cases where these overlap

but i think the bulk is "programming related", but perhaps we should revisit the idea of sub teams, though those were also programming specific so far

Most of the nominees and expected candidates are all tech savvy

[fresh frigate]

I guess "deal with the problem when and if it arises" is a pretty good option

[prime robin]

Can't forsee everything

But this is kind of what i was getting at with sub teams albeit less broad

I'll make sure to add this on the process document that some RFCs may be rejected or postponed due to lack of expertise on the team

and that such a rejection or postponement coudl result in restructuring of the team

[oblique star]

you'll have hard a time with me then krkrkr

but that would give you a "noob" perspective

[prime robin]

The team is for decisions, everyone can give their perspective on the review process

[oblique star]

An equilibrate team is obligatory in theses process

[prime robin]

Here's a draft for the ecosystem team open nomination post, I've taken the liberty of copying parts of it from the administrator self nomination post, it was too large for discord, so I had to put it into a markdown file.

[prime robin]

@fresh frigate I've fixed up the RFC process to include hopefully address your concerns, you can view the diff here.

(I hope you guys don't get pinged on GitHub everytime I push a commit with your username in it)

[fresh frigate]

I don't mind, but I was

[prime robin]

Ah damn

Clemens must be going insane then

[prime robin]

I've outlined the idea on org#27 as a draft. I'd say that any project which is transfered as unmaintained should automatically be part of the nusery where each team member gets access to triage issues and PRs, merge PRs and create releases, we'd then notify the triage members of typst/packages that the team members of that team should be allowed to open release PRs on the package repo.

[dense vale]

@prime robin

If a new maintainer is found, then the nursery team may transfer the repository to them, or invite the maintainer to the organization and add them as a maintainer.
transfer out of the org might be a little tricky

[prime robin]

Is it? I suppose some features will be lost

[dense vale]

not in that sense, primary concern is transfers are permanent

it is part responsibility when picking up unmaintained projects to also ensure they don't end up in wrong hands or someone who will simply maintain it for few days then forget

maybe add a condition of original author/previous maintainer approval?

[prime robin]

Can do, but some people are just MIA too

[dense vale]

i understand, but it wouldn't be a good look when it was placed under the org's care

[prime robin]

Understandable I was also not thinking that this would be a common occurrence

If it was done one would first have to be active on the project or so anyways

It's not like we'd transfer it willy nilly because someone comes along and says "gimme gimme"

[dense vale]

that's what i initially assumed based on the draft

i mean if you'll add a set of requirements sure

[prime robin]

Will do

[fresh frigate]

So, if I want to make a package following the current best practices and community standards, where should I start?

[prime robin]

While not fully up to date some of them are on the package-api-guidelines repo, despite being a little older I still think much of them apply.

In addition to that I would use the typst-package-template

Which comes with a few other things like unit test and release workflows

I'd use typstyle for formatting

And tidy v3 syntax for documentation, I'd personally use v4, but tinymist doesn't support this.

Unfortunately, not all of this can be found at a single place yet

[oblique star]

I'm reducing issues, I'm happy

I'll publish the 0.2.0 when I'll be done with everything EXCEPT the documentation

[flat bane]

classic programmer move^^

[oblique star]

I hate documenting

[oblique star]

I guess I'll use AI for that, and then I'll correct everything it says

[flat bane]

it comes in phases for me. whenever I release something I try to convince myself "if I want this to be useful for other, it has to be documented. any feature I haven't documented might as well not exist, because people won't be able to use it" and then I only release once I have documented.

basically, I try to dangle the release as the carrot in front of me 😛

(and since I do my Typst package documentations in the form of PDF manuals, it feels a bit better since I can use Typst for it. hopefully this will carry over to shiroa, I want to do online docs soon(TM) too)

[daring nymph]

in other word, you only document the things that are stable and useful for people. If you don't document something, only smart hackers will come and talk with you with the undocumented features.

in the form of PDF manuals
I recent have some idea of "continuously building documentation using PDF, github releases and actions". Say I have commit sequence HEAD, HEAD~1, HEAD~2, and so on. I will have a nightly release containing index.pdf.
the index.pdf contains the indice pointing to HEAD, HEAD~1, HEAD~2, .... the HEAD.pdf is tagged with v0.0.0-${HEAD} and contains links to index.pdf, HEAD~1, and recent released tags. And people can walk through with documentation at any time by the link chains.

This is powered by having typst as a convenient PDF generation tool I think and I feel it really cool.

[ornate condor]

Thumuss

[typst-community/utpm] New release published: 0.2.0

[oblique star]

I've posted the release, I'll take a break for a while (not months I promised)

I didn't want to publish this in 3 months so I prefere doing that now since the code is documented and there is a little part of documentation made

[oblique star]

And I've published it to https://crates.io/crates/utpm

[tacit nymph]

(what a beautiful preview image, i sure wonder how it was made)

[prime robin]

What a beautiful preview image I hope it doesn't have any hidden anti aliasing issues

[tacit nymph]

shhhh

(those were at least fixed on our side recently)

[ornate condor]

bluss

[typst-community/rowmantic] New release published: v0.4.0

[ornate condor]

github-actions[bot]

[typst-community/utpm] New release published: v0.2.2

github-actions[bot]

[typst-community/utpm] New release published: latest

[oblique star]

It could spam a little bit more, sorry for that, I hate workflows

[ornate condor]

github-actions[bot]

[typst-community/utpm] New release published: v0.2.1

github-actions[bot]

[typst-community/utpm] New release published: latest

[prime robin]

You aight?

I tend to test release workflows on a dummy repo

[oblique star]

When I check the next semversion, it works only for one target and then nothing works

I've just remove the check and now everything is push to latest while I'm checking why this doesn't work

Last spam with latest

[ornate condor]

github-actions[bot]

[typst-community/utpm] New release published: latest

[prime robin]

Pinging current members to look at this and tell me if that makes sense to you.

cc: @flat bane @daring nymph @heady grove @hybrid moat @tough crown

[prime robin]

See also this, adapted from the administrator nominations.

[daring nymph]

It makes sense to me.

[tame widget]

hello, can i use utpm to install packages to local without a workspace ?

[prime robin]

A workspace?

[tame widget]

Usage: utpm workspace [OPTIONS] <COMMAND>

Commands:
  link     Link the current project to the local package directory [aliases: l]
  install  Install all dependencies from the `typst.toml` manifest [aliases: i]
  add      Add dependencies to the manifest and then install them [aliases: a]
  delete   Delete dependencies from the manifest [aliases: d]
  init     Create a new `typst.toml` manifest for a project [aliases: n]
  clone    Clone a package from the typst universe or a local directory [aliases: d]
  bump     Bump all version of your package into an other
  sync     Synchronise all your dependencies into their last version
  help     Print this message or the help of the given subcommand(s)

but i see no utpm pkg install command

[heady grove]

Seems pretty reasonable to me.

[dense vale]

@prime robin sorry been busy lately, i'll take a look at #26 soon

[prime robin]

@neat crow @lilac knot @solid umbra you guys are currently listed as maintainers of the harbinger package, would you consider this maintained or should we put it in the nursery?

[prime robin]

no worries

[dense vale]

we can remove this now?

oop CONTRIBUTING.md slipped my mind

[prime robin]

@dense vale is there any particular reason we use links to the teams and people on GH instead of just using @foo? I messed up copying the link to the nursery team and this wouldn't really have happened if we didn't manually link the teams and users up.

[dense vale]

i dont think i knew they could be mentioned at the time

[prime robin]

well, users are also linked up manually

found that one a little odd

[dense vale]

i thought you couldn't mention people with their @ on github you needed to link?

except in issues/prs

[prime robin]

Although I'm unsure if this causes a notification

Nope, that works on markdown files too

afaik

I can open a PR and fix the link while I"m at it

[dense vale]

i recall adding attributions awhile back i read it wasn't supported

huh it is supported

wait no it isn't?

[prime robin]

fr?

[dense vale]

i dont think it is supported neither [@someone] or @someone work

same with team

i guess it makes sense they wouldn't want markdown prefixed with @ to automatically resolve to github links

[prime robin]

I could've sworn i did that before, maybe I'm misremembering

[dense vale]

i don't know maybe there's special github-specific syntax for it

[prime robin]

huh

How annoying

[tough crown]

This seems reasonable!

Will there be just a list or should the nominees write something about themselves?

[oblique star]

Nope, you need to have a typst.toml somewhere, it adds to your typst.toml and download the package you want to install

[oblique star]

To install directly to your local directory, you need utpm ws link, but the typst.toml is required to
I hope that was your question

TLDR: add adds a dependency but link copy your package into your local package dir

I have separated into two distinct categories to help people know when you need a typst.toml (except clone, idk why I put it here)

[prime robin]

Any nomination should come with some info about the nominee, I'll write the pre-nominations on behalf of the current team when opening the votes

[neat crow]

ok so honestly i have no idea what happened to harbinger - i think we were waiting on some update for it to work but then we kinda all forgot about it and now the code doesnt really work at all :) (it wasnt even published lmao). im happy to rewrite it when i have the time, but rn its just broken code ;)

[prime robin]

Ah ok

It's up to you, I just wanted to know if it was maintained for the purposes of the new team.

I'll leave it in your hands then

[tame widget]

adding another layer of indirection is counter-intuitive to my use-case:
1 - i have all managed in a justfile.
2 - i have no real workspace so to say
3 - i want to use utpm to install remote package locally (ie. $USER/.local/share/typst/packages) to re-package them into rpm/deb/pkg for (/usr/local/share or /usr/share or /opt)/typst/packages (canonical distro folders)
4 - why repackage ? because then users can use them without the need of direct internet access.
5 - the typst cli will pick up the custom package path via a globally set env variable TYPST_PACKAGE_PATH.

maybe now "utpm pkg install <resource> -prefix </path/to/packages>" makes sense to implement?

[random laurel]

a small question: just now prefers a lower-case justfile (created by just --init). will the community package template change to that from Justfile?

[flat bane]

if it's really an official stance, I guess that's sensible

[prime robin]

I just got used to upper casing it

In line with Makefile, Jenkinsfile, Doxyfile, Dockerfile

Odd choice, but I was never a fan of this kind of file naming anyway

[crisp summit]

we don't sort our directory listings using posix locale sort order anymore

[tacit nymph]

sorts you

[crisp summit]

(where J is before a-z)

[prime robin]

I'm thinking I'll post the nomination post today, any objections?

[prime robin]

I realize we have not yet thought about tie breaking on the team votes

So let's assume we have a team size of 5 with 8 nominations:

1. 10 votes: A, B
2. 9 votes: C
3. 8 votes: D
4. 7 votes: E, F, G
5. 6 votes: H
   Then E - G are tied for 5th team member, while H would be eliminated. How should we best resolve that tie there.

[flat bane]

a runoff?

[prime robin]

Yeah I think that works, the runoff could be done as a one vote poll

[keen gorge]

I'd like to raise some objections, if I may?
We might have spent too much time on theoretical rules.

• My opinion
  Voting isn't everything.
  We are not lifeless logic machines solving pure mathematical optimization problems.
  We are human, and human can change their minds through mutual communication and learning futher info.
  Furthermore, the effect of a decision is also influenced by the people who participate in the voting.
  If there is no general consensus, and a certain option only wins by a narrow margin in the voting, then it is likely to go bankrupt in the future.

• Opinions from other communities

  • Wikipedia:Voting: Polling is not a substitute for discussion. Polling is only meant to facilitate discussion.
  • Python Enhancement Proposal 10 – Voting Guidelines: While opinions are (sometimes) useful, but they are never binding. Opinions that are accompanied by rationales are always valued higher than bare scores.

• Mathematical truths about electoral systems
  a. Gibbard's theorem (Wikipedia)

For any deterministic process of collective decision, at least one of the following three properties must hold:

• The process is dictatorial, i.e. there is a single voter whose vote chooses the outcome.
• The process limits the possible outcomes to two options only.
• The process is not straightforward; the optimal ballot for a voter "requires strategic voting", i.e. it depends on their beliefs about other voters' ballots.
  b. Arrow's impossibility theorem (Wikipedia) or a 2.5-page PDF. The PDF is simpler, but it’s scanned and not very (visually) clear.
  If there are at least three candidates, then the following six axioms are inconsistent: 1. Total ordering. 2. Determined. 3. (Consensus) If all the voters prefer A to B, then the output also prefers A to B . 4. Impartial. 5. Independence of a third alternative. 6. (No dictators) If a single voter prefers X to Y, but all other voters disagree, then the system should override the wishes of that single voter and rank Y higher than X .

Disclaimer: The only part of the above that is generated by LLM is the phrase lifeless logic machines. I used LLM to search for words starting with L-L-M.

[flat bane]

I sympathize, but I'm not sure that I agree the points you mention make a system including voting a bad thing outright (but also disclaimer: I'm writing this before reading your sources, only based on what's in the post itself).

To maybe support the fact that I'm coming at this with an open mind, here's another source that broadly supports your points: https://communitywiki.org/wiki/DoOcracy (I found this recently while reading this – it's unrelated but I'll use this opportunity to share it with you anyways. I would have shared it here, but I found the "libertarian Burning Man tech bro" touch a bit cringe so originally refrained). Basically, the do-ocracy concept can be summed up as: the legitimation for someone to do things in a community comes from that person actually doing the thing.

Voting isn't everything. [...] We are human, and human can change their minds through mutual communication and learning futher info. [...] If there is no general consensus, and a certain option only wins by a narrow margin in the voting, then it is likely to go bankrupt in the future.

I agree. Note that "narrow margin" already means 2/3 agree, but that's still a lot of people to disagree. I personally think that an RFC accepted with serious disagreements will be the exception (if not nonexistent). Ideally, the RFC process focuses on the discussion part (that you agree we want to have) and the final vote becomes a formality because we have consensus. Setting a threshold (if we don't scrap the whole thing altogether) is necessary though, and keeping in mind that it's meant as a formality and not the mark to clear for pushing an RFC through, I think 2/3 is good.

Note that RFCs would be about things we recommend the community to do. People can ignore the recommendation, and I think that's good because it means the people who vote can't even meaningfully try to use this to dictate to others.

Gibbard's theorem

If I recall it correctly, the dictatorialness is imo somewhat academic: you need to know all votes to be able to, after the fact ,determine who was the one casting the dictatorial vote in a certain election. It doesn't mean one person has more power than the others.

Also, the votes we do (in the RFC process, not now for the ecosystem team) are yes/no, so according to the theorem we can avoid both other downsides. This then also defuses Arrow's.

[flat bane]

Last part: alternatives/consequences: should we avoid voting? Next stop in the Do-ocracy wiki walk was https://tldp.org/HOWTO/User-Group-HOWTO-7.html#ss7.4

Governing your LUG [Linux User Group] democratically is absolutely vital -- if and only if you believe it is. I intend that remark somewhat less cynically than it probably sounds, as I shall explain.

if elections and formal structure help attract key participants, use them. If those deter participants, lose them. If door-prizes and garage sales bring people in, do door-prizes and garage sales. Participation, as much as software, is the lifeblood of your LUG.

I thought (due to lack of voices to the contrary until now) that we are basically in the "help attract key participants" camp. Also, iiuc the impetus for the RFC process and properly establishing it came from the need for a discussion and decision venue regarding an agreed-upon docstring syntax, so it was grassroots (although I have not myself observed this, so I may be mistaken).

Personally, I find it valuable to have some structure because I want to avoid ending up in a Rust-like situation, where instituting structure and process was delayed so long that it caused harm. I also feel that we are very long away from that stage of community, but I don't think the structure established now will harm in the long run.

[prime robin]

So are we discussing the RFC votes or the nomination votes, because I thought we're discussing the latter

Where a tie can actually occur

I'm fine with a runoff using a single choice poll

I think that's sufficiently uncomplicated

[flat bane]

idk, the emphasis on discussion made it sound to me that it's about RFCs

like, questioning the fundamentals why we're planning to vote on the team anyway.

[prime robin]

I assume the emojis mean approval? I'm not sure what to make of it

I think we can go ahead with the nominations then I'll open them this evening when I'm home

[oblique star]

Yes krkrkr

[ornate condor]

tingerrr

[org] New discussion #29: Call for Nominations: Ecosystem Team

👋 Hey everyone,

With the ecosystem around community maintained tools, packages, plugins, and templates continuously growing, we're looking to consolidate efforts and shape the ecosystem at an early age. We want to ensure a coherent experience for people using community maintained tools and packages. For this reason, we've created the [rfcs] repository, a place at which we want to propose standards that community tools should uphold/support. We want RFCs to go through an open process where ...

[fresh frigate]

I feel weird asking, but did you mistag yourself?

[prime robin]

I did

deadass

💀

putting the posts up was fairly repetitive

[fresh frigate]

Thumus too

and the link to tinymist

[prime robin]

I must've done the same mistake on the original post too because i copied them over

[oblique star]

Didn't even notice krkrkr

[prime robin]

Ok those should be fixed, thank you!

[oblique star]

It makes sense yes, I'll consider the request!

Consider = finding time to impl it with the current challenges

[oblique star]

Btw I just saw that you didn't put a link for shiroa, is it normal?

[prime robin]

I saw that when i fixed the other ones and did that too

[oblique star]

Ah yes, I needed to recharge the page,

[tame widget]

i was just looking at utpm the first time, if it could be useful for my use-cases.
having that install variant would simplify my justfile code significantly
and make the ecosystem much easier to maintain.

[oblique star]

If you could make an issue based on what you need, I'll glady add that!

I'm not sure to follow everywhere, having your request posed can help

[tame widget]

done - https://github.com/typst-community/utpm/issues/73

[flat bane]

@oblique star sorry for bombarding utpm with issues 😛 I thought it would be easier to track many separate issues than one containing multiple issues

[flat bane]

I got to be honest though, I would like utpm a lot more if it was less opinionated about what a Typst project looks like. Like, dependencies specified in typst.toml are purely a utpm concept, and I feel too many features that could otherwise work (like #73 – installing packages locally) depend on it. Are you very committed to this concept and the associated CLI structure?

[tame widget]

me thinks that we can make utpm a really useful tool, by makeing the actual use-cases are understood

[prime robin]

A lot of people just want to do pkgs install --namespace local [email protected]:foo/bar

by far the mos timportant use case i would say

[oblique star]

Dw!!! I prefer having feedback than anything else

[oblique star]

It's just clone and install mixed, I'll do it when my power is back (the city is cut caused by weather issues)

[prime robin]

Yes I'm just saying hardly any user cares about the clone part being separate

If they did they'd just clone it themselves and then install it

Which defaults the point of the tool

[oblique star]

Yes and I can remove that, I've just been thinking that is interesting like cargo add dependencies from GitHub
I'm not committed to anything for now, just adding ideas I had while I didn't have any feedback
If you prefer another structure, tell me! I'm just a noob trying to make something tbh 😭

[prime robin]

Without typst support to actually download any dependencies putting them there won't help a user all that much

Git dependencies that is

The extra step of installing them is what's annoying to most

[oblique star]

By editing it to be only a check on the system is better you think?

Like "@local/package"

[prime robin]

I think prime use cases are:

• a full installation from a link
• automatic upgrade of imports
• fluff around local package management
• convenient publishing of one's own package

[oblique star]

Noted! Thx!

And do you think the separation between workspace and global is a problem?

I've read all the issues, thx for that, I'll address that ASAP!

[prime robin]

I don't know

Not sure what a workspace is from utpms perspective

[oblique star]

Workspace is just having a typst.toml in the current dir (overridable by env vars btw)

I need to specify all env variables that are used too damn

[prime robin]

Ah

I just consider that a project

[oblique star]

A rename could be interesting

[oblique star]

First of all, I'll make that

[oblique star]

btw automatic upgrade of imports is already done by bump

[flat bane]

it just so happens that I spent today yesterday (depending on the time zone) writing down some thoughts on what working with packages looks like – from my perspective at least (such a coincidence that it's the same day I finally looked more closely at utpm 👀)
Disclaimer, it's a wall of text, but I hope it shows some potential use cases and requirements for package managers
https://blog.sillyfreak.space/2025/08/15/typst-package-lifecycle/

[flat bane]

naming is the hardest thing about programming 😛 but I agree, some of the names are a bit confusing. workspace -> project seems like an easy one.

[prime robin]

Most of this matches my workflow too, but there are certainly things I haven't considered.

Like the integration test from the import

[flat bane]

@oblique star I'll probably spend some time today contributing 😛 I see you were working on the CI; do you think it makes sense to align that with tytanic's? Seems like tinger's workflows (or: ripgrep's workflows) are working well

(I'd have to adapt it a bit to restore the pre-release capabilities)

[flat bane]

or rather, do you really want to build binaries on every commit on a dev branch (what the pre-release workflow does currently)? That seems a bit energy intensive... nightly builds like tinymist might be an option: https://github.com/Myriad-Dreamin/tinymist/blob/main/.github/workflows/release-nightly.yml#L3-L6

[oblique star]

You can! I was trying to align with fd but I hate openssl
Thx!

Pre-release isn't obligatory, it was a test too

And I'm working on dev-install, it will be a big PR, I'm going to unbloat it

[flat bane]

a propos dev-*: the branches that are lying around but were already merged; are they still relevant? If not: deleting them from the main repo imo makes it easier to see what is actually going on at the moment.

[oblique star]

Nope we can delete them!

I can't delete them on my phone 🥲

[flat bane]

it's not urgent 😅

[oblique star]

Yes but while we discussed it, I was thinking I can remove them krkrkr

[oblique star]

Merged! Thank you 🫶

And I also deleted all branches not being relevant

[flat bane]

🙂

[flat bane]

I see you're touching a lot there, so I'll try to stay out of your way. Do you think fixing the bump issue (preserving comments and formatting in typst.toml) is possible without too many conflicts?

[oblique star]

There will be 0 conflicts on it, I'm removing git2 and specific keys on [tool.utpm] like dependencies and namespace since it's not really used. utpm ws link [namespace] seems a better idea
I'm removing also with that delete (dependencies are gone), add (same here) and bulk_delete (because you can do that with just a for loop in bash, why bother using this command)

And install is being rework like the way @tame widget and @prime robin have pointed

git2 is such a mess and I don't need to embed everything directly in embed since it's used particuliary in local context (on your pc)

octocrab will be removed too in favored of making simple requests. Only using a single feature on a crate isn't worth

I'll transform Strings to be EcoStrings to have a better reading comprehension while using typst-kit crate (using into everywhere and some transformation is a nightmare)

That's the plan before I release 0.3

If anyone has an objection or anything to add, I'm always open to ear you, since I'm not on the "terrain" I don't know exact use cases that could be problematic or I didn't consider it enough

[flat bane]

what you mention sounds good. Thanks for your work! I hope it doesn't feel too bad removing a lot of features that were already implemented 😔

then I'll try to get into the codebase and implement the toml handling change 🙂

[oblique star]

I don't mind! I'm learning rust by programming utpm, don't removing unused commands just because I've made them doesn't seems to be a good idea, I just want to make a tool useful for everyone now! And thanks for your time and contribution! 🫶

[flat bane]

btw, I'll likely do the symlink bug first. you use Windows, right? I'll have to ask you to test that I didn't break anything there 😛

[oblique star]

No I'm on arch 😭 😭

I could test on an other machine tuesday, since I'm not home

I didn't have that bug before, I didn't mention it but I'm suprise by this bug

When refactoring things I could have broken it

[flat bane]

ah oops, I thought I saw something that made me think you might be on Windows 😛 I'll see if I can test it somewhere 🙂

[oblique star]

What did make you think I was on windows? 😭

[fresh frigate]

A test on windows in github CI would be good in this case, right?

[oblique star]

I think I've patch the issue, but it won't be ready until I finish debloated it (errors are everywhere for now)

[oblique star]

Unit testing is primordial, if someone as the patience to do it, I'll be more than happy!

[flat bane]

I think something about a Windows package manager supported by utpm, made me think "ah, I guess the initiative on that came from Thumus using Windows" 😛

[flat bane]

definitely, but I don't quite want to start by writing CI test cases for platform specific filesystem behavior 😂

[oblique star]

Aaaaaaaaaah!! It's logical but I putting on windows was simple since there is a scoop bucket!

[prime robin]

Can you remind me again when I'm not inebriated

[oblique star]

Sure 😭

First time reading that word, thanks google

[prime robin]

Lmao

"Under the influence" is what you could translate it as

[elfin sparrow]

I mean that's how I do most of my programming :L

[flat bane]

there have been times when I thought "I should have coded this sober" 😂

[elfin sparrow]

Lol

[prime robin]

No worries, that's why I didn't code :)

[oblique star]

@flat bane Got warnings when cargo install the last commits you pushed :

warning: hiding a lifetime that's elided elsewhere is confusing
  --> src/commands/list.rs:46:17
   |
46 |     fn children(&self) -> Cow<[Namespace]> {
   |                 ^^^^^     ---------------- the same lifetime is hidden here
   |                 |
   |                 the lifetime is elided here
   |
   = help: the same lifetime is referred to in inconsistent ways, making the signature confusing
   = note: `#[warn(mismatched_lifetime_syntaxes)]` on by default
help: use `'_` for type paths
   |
46 |     fn children(&self) -> Cow<'_, [Namespace]> {
   |                               +++

warning: hiding a lifetime that's elided elsewhere is confusing
  --> src/commands/list.rs:80:17
   |
80 |     fn children(&self) -> Cow<[Package]> {
   |                 ^^^^^     -------------- the same lifetime is hidden here
   |                 |
   |                 the lifetime is elided here
   |
   = help: the same lifetime is referred to in inconsistent ways, making the signature confusing
help: use `'_` for type paths
   |
80 |     fn children(&self) -> Cow<'_, [Package]> {
   |                               +++

warning: hiding a lifetime that's elided elsewhere is confusing
   --> src/commands/list.rs:114:17
    |
114 |     fn children(&self) -> Cow<[Self::Child]> {
    |                 ^^^^^     ------------------ the same lifetime is hidden here
    |                 |
    |                 the lifetime is elided here
    |
    = help: the same lifetime is referred to in inconsistent ways, making the signature confusing
help: use `'_` for type paths
    |
114 |     fn children(&self) -> Cow<'_, [Self::Child]> {
    |                               +++

[flat bane]

ah, I read about those; these warnings are pretty new, my local toolchain is too old... I'll update and fix it quickly!

[oblique star]

Dw!! It was just more a stress for my part than anything 😭

Idk how but the error from TOML is perfect 👌

2025-08-15T21:36:35.586488Z ERROR utpm: TOML deserialization error: TOML parse error at line 5, column 5
  |
5 |     // Comments
  |     ^
invalid key

Is that from serde?

[flat bane]

since these warning are not in the PR's code I'll fix them in a separate PR 🙂

[flat bane]

toml_edit doesn't use serde, so no. but the error must be directly from toml_edit

[oblique star]

Btw I saw you didn't fix the ident issue, do I merge it? It seems complicated

󰣇  ❯ cat typst.toml                                                                                                                                                                                23:39 
[package]
name = "test"
version = "1.3.0"
entrypoint = "main.typ"

[tool.utpm]
    test = 1
󰣇 ❯ utpm ws bump 1.3.0                                                                                                                                                                            23:39 
2025-08-15T21:40:02.070413Z  INFO run: utpm::commands::bump: New version: 1.3.0 version="1.3.0" files="typst.toml"
󰣇 ❯ cat typst.toml                                                                                                                                                                                23:40 
[package]
name = "test"
version = "1.3.0"
entrypoint = "main.typ"

[tool.utpm]
test = 1
󰣇 ~/Test/utpmtest ❯

[oblique star]

No problem!

[flat bane]

it worked for me... I'll look at it

[oblique star]

Mb I was on the wrong branch..........

I just git clone without checking if it was the right branch

Like being inebriated, being tired isn't the best

I'll stop today, thank you very much for your contributions!!

[flat bane]

indeed; was a fun and productive day! gn8

[flat bane]

hmm you can't create threads within forges :\

I'm not sure if I'll do more UTPM work today, but I would have loved to not monopolize the forge either way 😛 if I end up working on it, I'll communicate on https://discord.com/channels/1054443721975922748/1266702763539304461, that's more specific than here

[prime robin]

That would be appreciated

[keen gorge]

Its-Just-Nans is working on making the website generator of https://typst-jp.github.io (Japanese translation of https://typst.app/docs, Apache-2.0 licensed) distributable (e.g., for multilingual/nightly docs).

He/she already has a proof of concept at https://github.com/Its-Just-Nans/typst.github.io.
Is it possible to create a new repo under this org?

Quoting from https://github.com/typst-jp/typst-jp.github.io/issues/233#issuecomment-3193719059:

I agree that having a repo under typst-community organisation would be great, and for example with a domains like docs.typst.community but for now typst.community looks 404

Previous discussions: https://github.com/orgs/typst-community/discussions/5

[prime robin]

Yes, we could possibly set that up, I can invite them later today

[oblique star]

I think using docs could be a problem since we already wanted to use this subdomain for the tools made by the community

[prime robin]

@keen gorge I have invited them to the organization, they can transfer their current or create a new repo as is

[prime robin]

also, this looks really good

[harsh hearth]

Hi

You mean you want to use docs.typst.community for tools?

Why about each tools having a subdomain?

Something like
utpm.typst.community
And
tytanic.typst.community
And
docs.typst.community for i18n docs
?

Or all the tools in one subdomain

tools.typst.community

[prime robin]

I think we could place the all docs under docs.typst.community and use paths to distinguish the docs we host there, but this obviously requires more work

I'm not actually sure if it works on github pages without having a slew of repos that sort of link to each other without any inter repo syncing

The domain is so long haha

[ornate condor]

quachpas

[typst-community/glossarium] New release published: v0.5.9

[mellow tendon]

This is all still in flux, but it's not set in stone that there even will be multiple namespaces in the public registry. I'm not a huge fan of them as they make migrating ownership unnecessarily breaking and distributing the namespace names is even harder than distributing the package names. The way I currently imagine it would just be a single @universe namespace that supersedes @preview (potentially with changes) while @preview remains for compatibility. Other namespaces would then remain available for private use and potentially private registries.

(If you want to respond, best do it in the #1176122103355953162 forge where I've copied my message to keep things on track.)

[ornate condor]

github-actions[bot]

[typst-community/utpm] New release published: v0.2.0

[oblique star]

Fixing https://github.com/typst-community/utpm/issues/85

[prime robin]

So regarding the maintenance status, is this still up to date? Is it just David now? I haven't heard from either of you two, @solid umbra @lilac knot. Whether or not it will actually be maintaned is up to whoever takes over, you can also archive it, but if you guys don't want to maintain it then I can archive it too.

Keep in mind that other shadow box packages have popped up in the meantime anyway.

[lilac knot]

👋 I think archiving might be the way to go, esp. given the community interest around arbitrary svg filters on typst content (https://github.com/typst/typst/issues/6772 summarizes many of these requests)

I've been using the shadow box code internally for several projects without too many issues so tentatively I think it's "feature complete" enough to stand in until more official typst support

[solid umbra]

Yeah i don't think there will be much more work on that, we wanted to publish it but it didn't really go forward as we were discussing the design a bit still

Could still be published as is if one wants

[prime robin]

I guess that's up to David then, if he doesn't want to publish we'll just archive it.

[neat crow]

filter would be nice tbh :) you can archive it ngl! @prime robin

[ornate condor]

quachpas

[typst-community/typst-algorithmic] New release published: v1.0.4

quachpas

[typst-community/typst-algorithmic] New release published: v1.0.5

[flat bane]

heads up, I will probably want to soon transfer prequery and typst-preprocess to the community. They belong together, and the latter is a native installable tool like tytanic and utpm; feels more "right" to me to distribute it from the community name than as a personal tool; also because it's something where various preprocessors could be added.

I'm currently working on mocking various parts of the preprocessor for testing, and hope I'll be confident enough to make a release then 🙂

[oblique star]

I feel like it could be a good idea to allow execution of plugins like cargo does.
As I'll develop more and more utpm, it would have a big proportion of already impl properties and I feel like it could be a good idea to allow execution of such tools you mentioned by utpm

utpm prequery ... etc

It would unify the team while having a relatable tool for the community, and leave a big part of liberty for those tools

What do you think about that?

[prime robin]

I think those tools serve quite different purposes and I don't fully see how they relate, with cargo being a build system and package manager the usage fo things like cargo-nextest as cargo nextest makes sense

but prequery is used for prepare compiling documents whereas utpm is used to install and manage projects

[flat bane]

I also think it makes more sense to keep these separated, at least for the time being. cargo does provide commands like test too, so it's not completely unthinkable, but the added complexity doesn't feel worth it. Maybe after we get more of a feeling how users would like to use these tools we can revisit, but right now it seems premature.

What I would find interesting is some kind of typst-kit-ext crate, so that our toolscan more easily share functionality that is too opinionated to go into typst-kit. That would also align the various command line tools more, but in a less intrusive way.

[ornate condor]

SillyFreak

[org] New discussion #30: Transfer Request for prequery & prequery-preprocess to typst-community

Project Name

prequery & prequery-preprocess

Initial Author(s)

Clemens Koza (SillyFreak)

Repository URL

https://github.com/SillyFreak/prequery & https://github.com/SillyFreak/prequery-preprocess

Status

Maintained

Description

a package and CLI tool for preprocessing metadata embedded in Typst documents.

I'll keep maintaining it (at least in the same intensity as before), but 1) would prefer to distribute the CLI within the community framework and 2) hope that peo...

[flat bane]

in addition to that thread, I simply initiate the transfer on my side, right?

[prime robin]

Essentially

What I would find interesting is some kind of typst-kit-ext crate, so that our toolscan more easily share functionality that is too opinionated to go into typst-kit. That would also align the various command line tools more, but in a less intrusive way.

I initially wrote typst-project for some of these things and there are definitely still things in there that have not ben upstreamed because they don't fit into typst-kit, but that's mostly jsut the porjec tlookup which is fairly simple

What I would like to do in a similar vein is do this for tests and I hope i can get myriad on board for this when i have the base laid out (last tyime i couldn't even review the initial test support before it was added to tinymist)

[ornate condor]

typst-community

[typst-community/prequery] New collaborator added: SillyFreak

typst-community

[typst-community/prequery-preprocess] New collaborator added: SillyFreak

[prime robin]

What would you put in these extensions?

[flat bane]

not sure from the top of my head, I think I have now and then thought "hey, that would be nice" but can't think of any right now.

[prime robin]

I also added config reading to typst-project to deserialize the config section in the manifest

it would be nice if we added support for that with toml_edit, right now it just uses toml and only reads

I thionk those two are definitely thing most tools would want to have, project discovery and config section reading from the manifest

[flat bane]

hmm... should I be able to push to branches on these repos, or do I have to go through PRs from personal forks?

You work directly on branches on tytanic, right?

[prime robin]

You may not have full access by default

Let me take a look

I believe thumus ran into the same issue

Added you as repo admin for both repos, it seems that, by default your access degrades to write access only when transferring

[flat bane]

I just saw that it's the OAuth app that needs to be authorized 😛 so no idea if I could have pushed before... in any case I approve that I'm an admin of the repo again 😛

[prime robin]

I'm sure you could've pushed before 😆

turns out you can use git without a GUI

[flat bane]

yeah I could have 😅 but I have a workflow that works (except for that) sooo... 😛

[prime robin]

I thought i had to approve something at first but the email just sent me to the org policy page and showed it as approved

so that should've worked from the get go too

[oblique star]

you don't use git with a GUI, do you?

[prime robin]

no, not really, most I tried are kinda bad

[flat bane]

interesting. I had to first request it, so that's why it didn't work initially, but I thought that the request was shown as pending first, and not immediately approved.... anyway..

[solid umbra]

obligatory honorary mention for gg https://github.com/gulbanana/gg

😎

[flat bane]

Starting a Shiroa docs page for prequery: https://typst-community.github.io/prequery/

(just noticed that the error messages are actually not human readable, gotta fix that before advertising it publicly :P)

[prime robin]

As of <t:1757317380> the standings on the ecosystem team vote are as follows, I'll do a final count tomorrow but it looks like we need a to arbitrate

[ornate condor]

bluss

[typst-community/rowmantic] New release published: v0.5.0

[ornate condor]

tingerrr

[org] Discussion #29 marked answered: Call for Nominations: Ecosystem Team

Thank you for everyone how participated, the vote is now finished, and we'll announce the standings and decision soon.

[daring nymph]

1. I'm ready to publish new release for shiroa, while there are still 6 small todos. new shiroa rewrites the two builtin themes to pure typst and gives more opportunities to fully or partially customize themes in future. The one important design is that templates allows slot arguments:

show: set-slot("meta-title", html.elem("title", [#title - #site-title]))

although shiroa is good to use for myself, I wonder the lack features for people using shiroa.

2. I need to publish 3 packages for new release for shiroa. To automate it, I would like to finish typship publish on CI

3. I would like to make some progress to stabilize tinymist package docs --json. My direction is to utilize the lsif format. https://github.com/Myriad-Dreamin/tinymist/pull/2032. I'm interested because if I further develop a typst template that reads lsif json and generate a HTML/PDF docs. The template can also be used by clice (a C++ language server).

[ornate condor]

github-actions[bot]

[typst-community/prequery-preprocess] New release published: v0.2.0

[prime robin]

The nomination standings are out, they were last verified at <t:1757440560>.

For those in the green and yellow list: please reply to this with whether you accept or reject your nomination. If you reject your nomination others will fill shift from the bottom up.

Nominated for 1st-8th spot

Those in green are nominated for sure:

• @daring nymph
• @solid umbra
• @silk crypt
• @tough crown
• @smoky juniper
• @dreamy pond
• @flat bane

Congratulations for being nominated, I will extend an invite to each one of you after you accept your nomination.

Tied for 9th spot

Those in yellow are tied for the 9th spot:

• @dreamy kite
• @silver aspen

Do you accept the nomination or concede to break the tie? If both of you accept we will simply hold a short vote for the 9th spot.

Out for now

Those in red have been pushed out by the maximum number of spots we wanted to allocate for the team:

• @oblique star
• @keen gorge
• @tropic field
• @hollow gyro

Thank you participating, if a spot opens up due to people rejecting their nominations you may be asked to join in their stead.

[flat bane]

Accept 🙂

[daring nymph]

@prime robin I would like to use typst to write rfcs and convert them by typlite. Is it okay to PR with the original typst document?

[prime robin]

I think we can adjust the template to be typst itself

Perfectly fine with me

keeping them simple to convert them to markdown would be good

[daring nymph]

I may not including template, and write a single-file document first. Some resuable code could be extracted later.

[prime robin]

yes, sounds good

[smoky juniper]

Accepted.

[flat bane]

(typo: exmaple => example :P)

[daring nymph]

oh

I listed all of the issues in the drafted RFC. Some of them are discussed and not resolved, and some are new and found during support docstrings in tinymist. https://github.com/typst-community/rfcs/pull/6

[prime robin]

you accidentally started the docstring RFC off of my wip commit for a tests

you gotta rebase off of that

[flat bane]

also the file name should be 0006-...

[daring nymph]

I finish main part and undrafted rfc#6.

[prime robin]

Writing longer reviews on GitHub is hell on earth

A have a bunch of dead comments that are constantly loading and I fear they are gone If i reload the page

[prime robin]

I've left my review, thanks for taking the time to write up the design!

[tough crown]

accepted! Thank you for organizing the nominations @prime robin

[solid umbra]

accepted too 👍

[ornate condor]

github-actions[bot]

[typst-community/prequery-preprocess] New release published: v0.3.0

[flat bane]

almost off-topic, but working on the typst-community repos is super useful to have real-world examples of using PR-based development processes for my software dev classes 😀

[prime robin]

reminder:

• @silk crypt @dreamy pond
• @dreamy kite @silver aspen

[silk crypt]

accepted! sorry for the delay

[dreamy pond]

accepted, thanks

[dreamy kite]

I will accept, my return to Typst is unfortunately taking longer than I had anticipated though.

[prime robin]

That means that all of the green list have accepted (and have been invited) and we're waiting for @silver aspen to either accept to reject the nomination to continue.

Thank you all.

[silver aspen]

Accept; many thanks!

[prime robin]

OK so we either extend the team to 10 or hold a second vote then.

[keen gorge]

I think the two options are more or less the same; it just requires a decision.
I suggest doing it on the forum. That's the fastest way I guess.

[prime robin]

Considering that we have 8 people on the team who have been voted by the community we may just vote within the team to keep the overhead low

[flat bane]

From a principled standpoint, it doesn't feel great to change the number spontaneously now. The election was announced to fill nine seats. Practically speaking, I have no problem with adding a 10th seat since the number of seats was fairly arbitrary from the beginning.
That would mean that a 2/3 majority consists of 7 instead of 6 people.

[prime robin]

A short vote with all options then as before

[ornate condor]

tingerrr

[typst-community/typst-docs-web] New collaborator added: 3w36zj6

[prime robin]

Regarding the tie breaker vote I'll add the following options:

• add fenjalien
• add overflowcat
• extend team size and add both
• shrink team size and add none

I think we can keep the time frame shorter this time, a week should be enough. I'll write something up this evening or tomorrow and announce it like before on discussions and forum.

[elfin sparrow]

Looking forward to the Typst community schism of 2026 when the "who is the 7th" movement picks up speed

[flat bane]

there is an Emo Philips reference to be made here somewhere...

[ornate condor]

tingerrr

[org] New discussion #32: Ecosystem team nominations 9th spot tie-breaker

Hey everyone,

the recent poll for the ecosystem nominations was successful, we've found 8 members for the ecosystem team which all accepted the nomination and have since been added to the team. Here are the standings (verified at 2025-09-09 19:56:00):

Names in green are those that accepted their nomination and were added to the team right away, names in red are those that were not added to the team, and names in yellow are th...

[ornate condor]

quachpas

[typst-community/typst-algorithmic] New release published: v1.0.6

quachpas

[typst-community/typst-algorithmic] New release published: v1.0.6

[keen gorge]

Hi! Could an admain take a look at these two issues in typst-docs-web?

• #9: Is it acceptable to use the icon for typst-community as the default favicon.png for typst-docs-web?
• #7: Could the repo YDX-2147483647/typst-dev-builds be moved to typst-community/dev-builds?

[dense vale]

let me see if i can pull up the figma for #9

its very old

for #7 feel free

nope cant find it 😭

let me just get it from github 😂

i got it, @keen gorge i'll add it to the org github.

https://github.com/typst-community/org/tree/main/design

[prime robin]

Oh my bad I read this and forgot to reply

Regarding #9, this repo is intended as a sort of frame work for others to host their own translation right?

If so we should probably only do that if we have some control over the repo to ensure the the typst community organization isn't misrepresented

On the other hand this would only protect against accidental misrepresentation, bad faith actors would just pull the icon and do it deliberately

[dense vale]

i thought about this and contemplated other options, it's the best one

it's just the typst t with community written vertically to the right its okay to have it as default for all, but honestly nothing is probably best since someone might miss/forget to change it when it is undesirable to them. happens a lot in e.g react

[ornate condor]

typst-community

[typst-community/dev-builds] New collaborator added: YDX-2147483647

[keen gorge]

Thank you for uploading the icon!
3w36zj6 agrees with tinger, so let's wait for better ideas.

Quoting 3w36zj6:

I strongly agree with that opinion. Let's put the default icon setting on hold for now.
We still welcome suggestions from anyone who has ideas for an attractive original icon.

[prime robin]

@keen gorge Is it correct that 3w36zj6 is the primary maintainer of typst-docs-web?

[ornate condor]

github-actions[bot]

[typst-community/dev-builds] New release published: hayagriva-main.2025-09-26.799cfdc

github-actions[bot]

[typst-community/dev-builds] New release published: hayagriva-v0.9.1

github-actions[bot]

[typst-community/dev-builds] New release published: package-check-v0.3.2

github-actions[bot]

[typst-community/dev-builds] New release published: docs-v0.13.1

[ornate condor]

github-actions[bot]

[typst-community/dev-builds] New release published: docs-main.2025-09-19.586b049

github-actions[bot]

[typst-community/dev-builds] New release published: typst-main.2025-09-19.586b049

github-actions[bot]

[typst-community/dev-builds] New release published: docs-v0.13.0

[prime robin]

I assume these run for basically every commit

[ornate condor]

github-actions[bot]

[typst-community/dev-builds] New release published: docs-v0.12.0

[keen gorge]

✓ 3w36zj6 is the one who started this version of typst-docs-web, and still reviews every changes in the project.
(There was a version developed by the Chinese community, but it stopped a long time ago due to disputes over the license. 3w36zj6's version is a full rewrite.)

I'm sorry for triggering so many GitHub messages. The workflows are triggered manually and all tests have been completed, so it's likely that such situations won't occur again in the future.

[prime robin]

Surely they could be triggered automatically using a cron job

[keen gorge]

Yes, but let's wait for a while and determine whether it's needed based on the download counts.
I don't understand how GitHub sorts releases. It seems to be in reverse alphabetical order? At present, it put all docs builds after all hayagriva builds, making it very difficult to locate the latest build. (although some docs builds happened after hayagriva.)
Another issue is that GitHub might limit the total file size of releases (I haven't check the docs yet). If we publish too many artifacts, then we'll have to remove old releases. It'll lead additional complexity and breaking changes.

[prime robin]

I figured it would sort by date?

[keen gorge]

The date when the release was published, or the date when drafted, or the committer date of the commit that the releases is tagged to, or the author date? All of them contradict with the order on GitHub's webpage.

Oh, gh release ls sorts by the publish date.

[prime robin]

But that doesn't seem to match the web page order

[daring nymph]

1. finished todos, the documentation is being improved to get to a new release.
2. finished, #1415517813111521410
3. finished definition LSIF protocol for typst, https://github.com/Myriad-Dreamin/tinymist/pull/2032

I start to develop a typst template that reads lsif json and generate a HTML/PDF docs. The template can also be used by clice (a C++ language server). https://github.com/Myriad-Dreamin/tinymist/pull/2144

👀

Also, with lsif, we will be able to have some enhanced html raw block typst package. You could render hover reaction and definition links with lsif in typst.

Some plan with lsif supports:

1. provide a low-level tinymist-index package on typst universe to run language query in typst scripting.
2. provide a raw block package that "shows" raw block and add hover reactions and definition links
3. provide a mid-level LSP docs template, that use tinymist-index to render markdown, pdf, and html files. This is built with tinymist-index to make tests.
4. I can run lsif on typst/packages and make lsif index snapshots. We can watch changes of snapshots to examine whether tinymist can analyze typst/packages correctly. The lsif index can be hosted, to provide a docs.typ (like docs.rs).
5. people can restart a mid-level template or customize the docs template a bit to get their favorite appearance for their doc sites. (@tough crown)

[prime robin]

The tie breaker for the 9th slot is finished and 9th member will be @silver aspen, congratz! Unfortunately this means that @dreamy kite is out for now. Thank you to those who participated and thank you to those who put their trust into these community members. We'll soon decide on the RFC process document, at which point RFCs can be voted on.

[tough crown]

thanks for the notification @daring nymph

We can collaborate on the template thing since I have had similar plans for a long time.

Tidy separates parsing (i.e. creating an index) and showing doc collections. The latter is currently done in Tidy withtidy.show-module(). It should be easy to allow reading and inputting an lsif index, thus offloading the parsing to an external tool like tinymist.

About templates: this notion already exists in Tidy and a user can create their own template/"doc style". However, I think it would be much nicer and incredibly more powerful to use types that can be customized through show rules. A user then does not need to write a template from scratch or copy+modify one, but instead can use the show/set infrastructure to address individual parts of the appearance.

I already wrote up a draft that uses elembic some time ago but there is still work to be done.

[prime robin]

@prime iris How was the typst-install deployment supposed to work? It redirects to the repo with a js action and the path in the example is 404 (likely due to changes in the DNS records for the domain since the last deployment)

It seems the custom domain was removed from the pages deployment which was likely due to when we were discussing moving project docs

@dense vale do you remember the details?

@inner kiln https://typst-community.github.io/typst-install/install.sh works at the moment I'll re-eactive the custom domain for now though

OK I'm still unsure how this was supposed to work because I would have to point this at typst.community/typst-install/ which is not just a domain.

[prime robin]

For context, we have a CNAME record that currently points typst.community at typst-community.github.io such that any paths are resolved relative to that, so typst.community/typst-install/install.sh should resolve to typst-community.github.io/typst-install/install.sh which is a GH pages deployment that is definitely not 404

The docs seem to suggest that we still need to set the custom domain for this in the deployment which recommends but doesn't require a www subdomain for redirects

Ok the docs don't use the CNAME entry but explicit A entries, not sure why it's configured that way on our side.

[inner kiln]

Thank you

[prime robin]

I've set up GitHub Pages before for an old account and from the looks it had DNS proxying disabled in Cloudflare, HTTPS was not enforced on GitHub's side and it was pointed right at the Apex domain with a simple CNAME pointing back at GitHub's pages domain.

When i disabled the proxying I got the correct IPs on the A record lookup, but the SSL certificate for typst.community did not work anymore and I'm wondering if this is fundamentally incompatible or if I'm just a noob at this (probably the latter).

Let's hope Rashid knows more, he's set this up before.

[dense vale]

yes

i'll make it install.typst-community.org

it's bit finicky otherwise being typst-community.org/typst-install/

i think i know why it broke

[prime robin]

Why?

[dense vale]

for some reason it requires a repo with exactly "typst-community.org" name to work

[prime robin]

but wouldn't that only be for the root path pages deployment?

[dense vale]

no

somehow it works for all repos

idk thats why its very confusing

[prime robin]

Ok but GH pages for projects would otherwise work if we just point them at pages.typst.community?

[dense vale]

wait is the domain typst-community.org

or typst.community

my brain

oh its typst.community

😭

[prime robin]

😭

community TLD is so long though aaah

[dense vale]

i was getting improper dns whatever from github trying to put install.typst-community.org

for the past 10 min ;c

[dense vale]

life

https://install.typst.community/

https://install.typst.community/install.sh

is weird

[prime robin]

But how come it worked before

on the apex domain

[dense vale]

oh

is he just redirecting on index.html? 😭

[dense vale]

for which repos

[prime robin]

@inner kiln noted that it used to work but does no longer and the typst-install repo has curl https://typst.cpommunity/typst-install/installer.sh | sh as an example

[dense vale]

yes it did

because we had a repo typst.community

with CNAME in it

[prime robin]

a separate repo?

[dense vale]

yes

if i recall correctly

[prime robin]

deleted i presume?

[dense vale]

i think i was trying to figure out a way

after we were discussing the website

for something idrm

tytanic.typst.community is this too long?

[prime robin]

I don't know if we should use a different sub domain for each page

instead of just redirecting pages from a real webserver with a path like /docs/{project}

(the old debate)

[dense vale]

oh thats why

right

btw typst.zone is available if u think it can work as an alternative

but then it'll be a bit more confusing

[prime robin]

what does .com stand for again?

[dense vale]

i like how someone bought out typst.xyz and then is trying to resell aftermarket for 1.1k

[prime robin]

LOL

[dense vale]

commercial

[prime robin]

ah

[dense vale]

i kid u not

[prime robin]

sounds too official anyway

[dense vale]

theres a reason why typst uses typst.app it wasn't available at the time anyways

how about typst.to?

@prime robin

[prime robin]

do other communities use .community

surely

[dense vale]

erm

.org

https://rocq-community.org/

[prime robin]

mhm

[dense vale]

no to typst.to?

[prime robin]

idk 😭

[dense vale]

it could just redirect to typst.community

[prime robin]

it's nice and short

but I generally associate to with piracy sites

there's also https://nix-community.org/

[dense vale]

ill give u good news

very good news

u will be very happy

[prime robin]

lmao

you already have it?

😂

[dense vale]

welp we waiting few days

[inner kiln]

I feel just typst.community/install.sh will be fine

[dense vale]

cant

[inner kiln]

Sob

[dense vale]

well

i can if

[inner kiln]

Why

[dense vale]

install.sh wasn't its own repo

[inner kiln]

Oh well yeah different repos right?

[dense vale]

i mean we can move install.sh/ps to the www repo and

put typst.community there

[elfin sparrow]

Would a submodule work?

[inner kiln]

Yeah why wouldnt it? And then the gh action just moves the files to be served

[dense vale]

it would make it

typst.community/typst-install/install.sh

[elfin sparrow]

😭🤌🤌

[dense vale]

if it was a subtree not submodule

submodule i doubt it would work in first place idk if it clones recursively

typst-install isn't maintained anyways and doesnt' require any maintainenance

i never use install scripts because they are impure just use nix

https://github.com/gytis-ivaskevicius/high-quality-nix-content/raw/master/emoji/nix-chad.gif

[prime robin]

Since we were at it again with the usual where-to-host-the-pages discussion I think we should seriously think about consolidating somethings in the www repo to get a nice landing page which is easier to navigate for things like project governance and such

github orgs are hard to navigate even when you're in them

(Un)fortunately I am not a web developer so getting something like this off the ground would not be my strong suite.

[inner kiln]

web dev moment 🤑

[flat bane]

I had to setup a basic home page for our association recently (since I couldn't stand having to use Wordpress any longer 😛). I did so using Astro, which I find really easy to setup and use. I adapted that code for my blog with Typst integration, in case we want that (now or later).

I'm just definitely not a web designer; I'd prefer if someone else chooses or creates a theme.

[prime robin]

Is that integration the one by overflowcat?

[flat bane]

(also, what I did for our website is to create a staging and production repo and site (links go to the sites since the repos are private) so that you can see how the site is deployed by Pages before the real deployment. I'm not sure if there's a better way that aligns more with the PR workflow; I don't think you can deploy PRs to a staging domain, but maybe we could have an Action that force pushes PRs onto the staging repo's main branch, triggering deployment there.)

[prime robin]

I'm not sure either if you can deploy like that and with more than one PR pushing then to a staging branch also won't help much I feel

But I think it doesn't have to be pages anyway, any deployment workflow could be used with some repo secrets that allow pushing to a staging server

And if that staging server has a small selection screen to chose in flight PRs it wouldnt overwrite other PRs on every commit

[flat bane]

from what I can quickly tell from my git history, this is basically the change, astro-wise: https://github.com/SillyFreak/blog/commit/5fecf6f971d73f1c4cb0078e6b3d259f453d7f9e#diff-e0f0c5adbe0b9ca5d0b57caf5cea33a8d88899fd02a43df1e9862b185f8a1e5f

[prime robin]

But idk how hard that would be to set up

Seems fairly simple to add, nice

[flat bane]

at the very least, it means we need an actual server. I think right now there's nothing that is not simply on Github, right? 😛

[prime robin]

Yes, but I don't think that would be a big problem, I could rent one at Hetzner or so

[flat bane]

If that's no problem for you, sure. The CI side shouldn't be too hard; basically every PR would just need to be FTP'd over to a path matching the PR's branch name, or something like that.

How much does a Hetzner server cost? Because if I envision that correctly, a shared hoster on which we can deploy static sites should also be sufficient.

[prime robin]

Depends on the server type

There are super cheap managed web hosting servers for 2+/mo and managed general purpose servers for 40+/mo

[flat bane]

ah, 2€/mo is really affordable. Just for staging a small landing page that will probably be sufficient.

[prime robin]

Yeah, comes fully setup and such too, database and all

I wonder how much control you get over the setup though. Especially regarding CI access and whatever.

[flat bane]

I see "Encrypted FTP", that should be enough to let CI deploy from GH actions (the production site I linked above is actually deployed via FTP and not Pages, because our hoster wouldn't let us point the apex domain to Github in their DNS settings)

[prime robin]

Well I suppose we should look into what the exact structure of the website should be sometime then

I imagine we could easily add redirects from a docs path to gh pages and have things like the installer on a very easy subdomain or path

[flat bane]

So what I envisioned was that all the productive content would be using GH Pages; that has the advantage that the sites would load faster for users not close to Germany. But using <meta http-equiv> I think any redirects we want should still work. In that vision, the Hetzner host would only be used for previewing changes, and we could even wait with setting that up when we see it's actually necessary.

But other than that—yes, the overall structure of the site needs to be established. Depending on what we want, GH Pages may turn out to no support that anyway.

[prime robin]

Does that meta tag work like a redirect without the need for a non-static hosting solution?

[flat bane]

That's my understanding (which is probably incomplete). It instructs the browser, who probably got the HTML page with a 200 OK status code, to treat the response as if it was some other status code, and (usually) reload.

Not clean imo since it confuses different layers of networking/application, but should work.

[prime robin]

I suppose

But then redirects to projects would need to be added to the www repo and can't be dynamic

[flat bane]

Yeah. it really depends on the desired structure. I think for typst.community/install.sh this would be fine; it's a special case that should be super short and doesn't mean other repos need the same redirect. If docs are hosted at e.g. tytanic.typst.community no redirect is needed; just a DNS entry and a regular link from the landing page to the docs page.

If the desired structure is docs.typst.community/tytanic (makes a lot of sense imo) then I would also prefer this not to work via redirects. Using a hosting service would probably also make it easier to host docs for different versions of the same tools/packages.

[prime robin]

Yeah but I'm thinking tytanic.typst.community has the annoyance of requiring explicit handling of tytanic for example, this means that every project that decides to hos tpages on the community org would have to ask for an DNS entry. Whereas typst.community/docs/tytanic could use a simple dynamic server that redirects to a project gh pages

Should've read the whole message

But yeah that's what i was thinking, a pages or docs subdomain with a server that simply redirects for now

[oblique star]

*.typst.community => reverse proxy?

[prime robin]

I don't know what the implications of this would be

[tame widget]

nginx and caddy come to mind ... if you also want php support, frankenphp would be an option.

[tame widget]

actually no ... you can enter a CNAME of *.typst.community with target typst.community, the webserver can do the rest

in my dayjob, i have this since decades on apache, nginx and more recently caddy and frankenphp

[tame widget]

https://www.world4you.com/hosting

[prime robin]

if im not entirely wrong cloudflare suggests not to do that

damn I'm getting better with this keyboard

I read someting about potential subdomain takeover with rules like *.<APEX DOMIAN> yadda yadda

But if that's fine to do on your own domain we can do that

how does the web server know which sub domain it is, does the web request also carry this and not just the path?

[rough pulsar]

yeah, the browser passes the Host header that is set to tytanic.typst.community or something

[tame widget]

the http request carries a "Host: <fqdn>" header

[prime robin]

cool

[tame widget]

W4Y for example has unlimited subdomains

[prime robin]

If we were to keep hosting on GH pages but want to serve the docs from a subdomain or a path in typst.community we'd likely run into problems with relative paths right? Unless we just plainly redirect (which kinda misses the point) the projects woudl haev to tell the pages that they're hosted on another domain or even path right

say a project hosts an mdbook at and it's supposed to work on pages.typst.community/project it would have to configure mdbook to use this for relative links i assume

[tame widget]

i have done such path magic in the past with nginx but i only consider it as a workaround as it might not work in all cases

[tame widget]

yes ... i use jbake but it has the same/similar option to do that

[dense vale]

@prime robin we can host the server on cloudflare workers

it has a generous free tier

i doubt you'll need more for traffic

and its served globally, serverless memes

Free 100,000 per day No charge for duration 10 milliseconds of CPU time per invocation

but if the server is only for redirects cloudflare already offers that for free dont need to host anything

[prime robin]

Interesting

[dense vale]

100,000 requests*

[tame widget]

hmm ... the average website has 20-40 requests per page not considering caching ... you can do the rest of the math yourself

[dense vale]

@prime robin it’s done

I managed to get typst.co

[dense vale]

@prime robin now that the domain is short cant we just do

tytanic.typst.co

typst.co/project/tytanic

[prime robin]

since either works the same with a minimal web server it's really just about aesthetics, I personally prefer using subdomains for specific things that may have many paths (think a git subdomain for a a git forge an server), so I'd go with setting up the latter eventually or pages.typst.co/<project>

[dense vale]

spare the dns resolution time and just host it on one domain alongside a basic landing page we can add later

if there won't be much hosted on typst.co anyways

[ornate condor]

github-actions[bot]

[typst-community/dev-builds] New release published: docs-v0.14.0-rc.1

[ornate condor]

github-actions[bot]

[typst-community/dev-builds] New release published: package-check-v0.4.0

[ornate condor]

tingerrr

[typst-community/tytanic] New release published: v0.3.0-rc.1

[prime robin]

Now that's rich

this happens when publishing:

but not when building

presumably because it's using the project directory for the publish, but then it would have to add ../../, not ../

or not actually

what

[prime robin]

https://github.com/rust-lang/cargo/issues/13309

Damn

[ornate condor]

tingerrr

[typst-community/tytanic] New release published: v0.3.0-rc.1

[prime robin]

Sure hope this works cuz I'm going to sleep

[prime robin]

@dreamy pond did you receive the invite to the ecosystem team?

It doesn't show the invite anymore but you're not in the team either.

[dreamy pond]

Sorry, I didn't notice the email before. I just found it, but it expired. Can you send me another one? Thanks!

[prime robin]

Yeah will do

[prime robin]

I did btw

Just figured I'd say that otherwise it'll expire again @dreamy pond

[dreamy pond]

thanks!

[ornate condor]

github-actions[bot]

[typst-community/dev-builds] New release published: docs-v0.14.0-rc.2

[ornate condor]

tingerrr

[typst-community/tytanic] New release published: v0.3.0-rc.2

[prime robin]

I'm thinking we should perhaps ask for a dedicated channel or category of sorts, the criss-cross discussion and the GitHub notices and sometimes push up previous messages to the point that they get missed by those that care about them. What do you guys think should we ask for and how much of it is attainable as a sort of sub-server of the official typst server?

Personally, I think a forum channel similar to #1175885362065834105 where we could have typst-community channels would be cool, perhaps with creation limited permissions to typst-community admins and typst moderators. One channel I think we definitely need is one where we can discuss RFCs and related things int he ecosystem team without derailing general typst-community stuff. I'd like to use this to discuss the RFC process document and later on for the vote on myriad's RFC for doc syntax.

If we all agree on what we should ask for I would put that forward as a request to the moderation team of the server and if they feel like we should moderate such a place ourselves we can still make a semi-internal server for it.

I actually thought about making a server at first, but I think it's important to show that we're trying to stay close to the official project.

[flat bane]

I agree, since #1194684809906237500 is inside #1175885362065834105 you can't even start a thread in here... one option would be to lift #1194684809906237500 to the same level as #1175885362065834105, inside the "Contributors" category.

(I'm speaking just as a member; I have mod permissions here but focus on the forum. I leave the Discord modding to others—except for banning the occasional spammer)

[keen gorge]

Could any admin help me enable GitHub Pages for typst-community/dev-builds and set it as the website for the repo? Thanks in advance!
I'm making an auto-generated catalog to circumvent that mystery of GitHub, but I don't have permission to deploy it.

(it needed to be configured to build using GitHub Actions (gh-pages.yaml, not any branch)

[flat bane]

Prequery has a working Pages setup: https://github.com/typst-community/prequery/blob/main/.github/workflows/gh-pages.yml

I think it worked pretty muhc out of the box...

[keen gorge]

I don't think I have necessary permissions… The following is my view in repo settings.
(The enablement parameter for configure-pages requires “a Personal Access Token with the repo scope or Pages write permission”, which I don't have either.)

[prime robin]

I've set the source to GitHub Actions

I didn't think you need speecial permissions for this

Not sure if this can be adjusted

You only had write perms

[keen gorge]

Thank you! It's online now. https://typst-community.github.io/dev-builds/

[prime robin]

You should be able to see it now

[steep orbit]

After seeing the awesome site like https://diagrams.janosh.dev/, I had the idea to have a site where anyone (protected through a social login) can share their Typst snippets, along with the used packages, some tags, and a short description. The site would be searchable and include the working Typst version for the shared snippet.

I currently do a lot with cetz and zap and thought that what I did, others probably did too. I have not found a site that collects all such snippets/ only pages like above trough a PR and only for scientific projects.
While my Typst skills are not great, I would say my dev skills are fairly okayish for web and backend development. Far from perfect, but ok. So I wanted to suggest the idea to see if something like this would be wanted and accepted in the typst community.
TL;DR It would be a site where users can share their snippets publicly to share with others - basically something like the bot-corner, but for finished snippets that are properly tagged, searchable, and copyable (and not limited by the 2000-character limit).

It would not involve git and would be managed through a backend, so it is as easy as possible and doable all in web, that would also be open source and have a database dump available so no information is gatekept.

Would this be something you guys are interested in? (Nothing built, just an idea at the moment)

-# Btw. I do think git is an important skill, but the need to do a PR for such sites, I think, higher the bar of adding shorter snippets.

[prime robin]

We have at the very least typst-examples-book

As a starting point for snippets

I think it's still hosted on sitandr's personal account

Ans yes I think continuing this or improving on it is a great idea

[steep orbit]

I've seen something like this and think it is awesome!, but that's a static HTML site (more or less). So there is no way to add content without adding it to the repo. That's what would be the difference (which definitly also has it's downsites)

[prime robin]

Yes, I'm just saying that there are plenty of snippets you could carry over from there

[steep orbit]

Ah, yeah! Thanks <3

[keen gorge]

The FAQ list on the Chinese Community's website is similar to what you've described, but works differently: The entire process starts from bottom to top organically.
Many people (especially newcomers) don't even visit the website actively, but ask and share things in our chat group. If something is repeatedly mentioned and proved reusable, then someone will say “why isn't this in the FAQ?” Now perhaps another person just have time so he/she record it and submit a PR, or maybe only take a quick note in GitHub Discussions and left for the third person to complete the job in the future.
If we have a lot of money, we can pay those who submit snippets, and things will soon be on the right track and well-organized; but we don't…

[dire robin]

Related to the conversation, see https://discord.com/channels/1054443721975922748/1430509617783377991

[steep orbit]

@dire robin Because I also saw you mentioned that this might be also inspiration for an UI I would want you to ask if you maybe want to help building an UI for above, so we maybe can combine this. As my skill definitely are not in the UI/UX and the backend is more or less drafted
I also fully understand if not

[dire robin]

You understood correctly, I'm open to your proposal.

[ornate condor]

github-actions[bot]

[typst-community/dev-builds] New release published: docs-v0.14.0

[prime robin]

👀

[dire robin]

Is this what the docs bot uses on this server? I see someone use that occasionally, but not sure if it's reliable

[keen gorge]

What docs bot?
docs.json and docs-assets.zip are built from the official repo, but released unofficially. You can see the build script in .github/workflows/docs.yaml.
Further explanation is available in the README.

[dire robin]

?tag decimal

[random agate]

That tag is not defined.

[dire robin]

?tag arguments

[random agate]

https://typst.app/docs/reference/foundations/arguments/

[dire robin]

Looks like it was that, I thought it came from different docs

Or #discussions message, but I thought someone was already using it

[ornate condor]

tingerrr

[typst-community/tytanic] New release published: v0.3.0

[prime robin]

I've added a latest that points to the latest non-pre-release and a v0.3, v0.2, v0.1 branch respectively that points to the latest minor version each.

For those that prefer that in CI and such

[inner kiln]

Would a dedicated page for the typst install repo be any good or useful?
I kinda made one (out of boredom bc the link didnt work at that time 😔)

[keen gorge]

It looks like that the tags are set manually.
#bot-corner message