#Community

1 messages · Page 3 of 1

dense vale
#

it makes sense to a certain extent to have a separate organization dedicated to certain general fields, such as in this case chemistry but of course if that community had a much bigger following

#

i'm unaffiliated with this of course

prime robin
#

So am I

#

I can't speak for chemists

#

@elfin sparrow can, but he's MIA

#

radio silence since a while

dense vale
#

mm

#

let me see if i can get in touch with the op

#

only a linkedin sigh

prime robin
#

We could at the very least get them on here and have them join the community org too

#

oof

dense vale
#

i guess i'll reply on the discussion

#

i thought i'd pin their discussion for exposure, but i'll unwind that given it was a one-man effort? i thought it'd be more

prime robin
#

who made this team again xdd

image.png
dense vale
#

two-man*

dense vale
#

everything has a log

Screenshot_2025-03-10_at_00.53.37.png
prime robin
#

right

#

i remember talking about it but i don't remember what it was for

dense vale
#

huh i swear i could remember putting some people under it as per our discussions

#

i guess i just put everyone under ecosystem team

#

i replied to the discussion extending an invite to discuss it here more, we'll see

ornate condorBOT
#
killercup
[glossarium] New discussion #116: Using term lists

For a document I'm currently writing, a bunch of glossary entries are multi lines. I now even wanted to include code snippets show examples of formats. The default output had some issues with indenting the blocks correctly, so I was looking into alternatives.

Using the built-in term lists seems to work just fine! I have a quite simplified rendering function like this now:

#print-glossary(
  entry-list,
  // the custom function...
ornate condorBOT
#
gerob311
[glossarium] Discussion #71 marked answered: A way to query glossary references separately to web links

I think I don't know Typst well enough yet to know how to do what you have suggested. However, I now realise this is a problem that isn't just concerned with this library. For example, I want to make sure that the style I've applied to my web links doesn't get applied to the glossary references.

I've managed to put together a bit of a hacky approach though.

	show link: it => {
		if type(it.dest) == "string" {
			text(it, fill: blue)
		} else {
			it
		}
	}

	show ref: it...
whole crest
prime robin
#

cc @dense vale

dense vale
dense vale
# whole crest Hey, I just read this message https://github.com/orgs/typst-community/discussion...

If you're open to it, it'd be awesome to have typsium as a team under typst-community and take you under typst-community's umbrella till the community grows to where it'd make sense to have a separate organization

of course this is solely for the purpose of having a central org where people can collaborate, rather than multiple communities when typst is still young.

mostly for exposure, and perhaps to a certain extent, coordination.

#

of course if you feel otherwise would be best, i'll happily pin your discussion to help somewhat in terms of exposure

whole crest
#

I scrolled up a bit and saw some other questions, so I'll try to answer in order of appearance. It's not so much a one person project in the sense that I'm the only one contributing, "it's just some guy" may be a bit reductive. The idea of the chemistry community is my idea yes, but right now we have all the contributors of existing popular chemistry packages onboard:
https://typst.app/universe/package/alchemist/
https://typst.app/universe/package/whalogen/
https://typst.app/universe/package/chem-par/
https://typst.app/universe/package/atomic/
https://typst.app/universe/package/typsium/
As well as some contributors I managed to pick up here and there.
As of yet the communication has mostly been me directly emailing with each individual person. The idea to do this initially started by the Typsium package creator messaging me since he wanted to reimplement what whalogen was already doing, but slightly different. So I started reaching out to original maintainers, starting to work out more specific product requirements and finding common ground on what interoperability between packages should look like and what the current typst ecosystem is lacking. So what may appear to be just the posts of "just one guy" is the summary of multiple discussions.

#

I think weird is a bit judgy, but I'm assuming by weird you mean useless. I'd agree that it's useless, but at the same time, there's been many different approaches to solving the same kinds of problems so far, and bringing all of these people under the same roof and starting to work on things that are not just a formula renderer (there's three formula renderers as of now, it's like the chemistry equivalent of a units package lmao).

whole crest
sullen pivot
whole crest
#

I'd say anything that is the opposite of fragmented is not further splintering. by creating typsium I didn't splinter it, but grouped the already splintered chemistry stuff into one bigger splinter

prime robin
#

While I don't want to reduce the chemistry community here I don't think that it is large enough that it necessarily requires an extra organization

sullen pivot
#

I just don't think the typst community is large enough to have separate communities for each field

whole crest
whole crest
#

to share a bit what we're working on, we're making a new package for smiles support (smiles is basically short codes that describe the structure of a molecule), the alchemist core dev is currently working on writing a wasm based parser and the rendering will be based on alchemist, which is already being hosted by typsium

prime robin
#

I think some compelling points is bundling of resources, be it administration, shared code of conduct, possible sponsorship or organization plans on github

#

I also think consolidation is easier early on than later on if you do change your mind

#

Even if we don't consolidate the organizations it'd be great to have chemistry team on typst-community

whole crest
#

we're working on adding meaning to the symbols, i.e. databases of elements and molecules, along with their values and descriptions. this is an important thing to get right, since we're planning on making all our packages support this data model, including retrofitting existing packages.
then use these variables all over the place in different packages for different visualisations, displaying quantities, safety information, etc. It's important we have control over the full pipeline so that we can do stuff like this:
#reaction[#a + #b -> #c]
and do the same with a different package:
#reaction-smiles[#a + #b -> #c]

#

if you want I can go more in depth to what we have planned, but maybe not as important

prime robin
#

I'm not a chemist but I'm sure this is important

whole crest
#

the reason I reached out to the typst community is because I think right now it's quite active and we're talking a lot, everything is going good, everyone is happy. But it's a small team (maybe 5-6 peeps), but in my experience once we achieved our main goals, development will slow down, so if in some point in the future it doesn't make sense to host the packages in a separate community the typst community can just transfer the projects and host them. For now though I don't think it makes sense to do that yet, we're not interested in code of conduct and adminstration stuff. In my personal experience, having a bigger unrelated thingy attached to the main thing you're trying to do introduces too much bloat. We're a concentrated effort to achieve a specific set of goals. If other people with other opinions start having a say it's going to add friction. If someone on the forum or on the discord is talking about something chemistry related people can just share the typsium link and it's the central point of contact for chemistry stuff, instead of sharing a link to a team inside a different organisation. The reason I decided to call it typsium organisation, even though I wasn't affiliated with the original typsium package is because it has pretty amazing SEO. Also having a bunch of packages on typst universe all have a similar naming is pretty neat. idk, I just don't see a need, and it's not like there's a negative side to this kind of fragmentation.

dense vale
#

note i've modified the title to be more clear

whole crest
#

I do think that the typst community is pretty great though!

dense vale
#

good luck on your endeavors, awesome projects from what i'm hearing. @elfin sparrow would definitely be interested

whole crest
#

Hey, anyone who's interested and knows a little bit about chemistry would be great to have onboard

prime robin
#

he seems very busy atm I've seen some activity on his GH, but he's not responding anywhere atm

dense vale
#

feel free to use this thread as a place for discussion, it's not explicitly set for typst-community anyhow. general community discussions

whole crest
whole crest
prime robin
#

yeah

whole crest
#

it's pretty neat, we're working on adding more unit testing to the existing packages. My compliments to the chef 😙 👌

prime robin
#

ty ❤️

whole crest
#

one aspect that's going to be important soon for us is units. We want to make a units package for chemistry, but it should handle ONLY the chemistry related calculations and forward the displaying to an existing units package. The main use case is that you can use your existing variables and chemistry units and it will automatically convert moles to grams/mililitres, concentrations of solutions, different hydrations of molecules, etc...

#

I've been reaching out to different existing unit package maintainers and see if there's maybe a unified way of providing users options in which one they want to choose and would like some input from here as well

#

so of course we can just require users to setup the methods themselves like this:
#import typsium-units: mole
#let mole = mole.with(display: x=> unify.qty(.....))

#

but could be confusing/lead to bugs for inexperienced users

#

but having multiple unit rendering packages as dependencies would be even worse

#

maybe have one dependency as default and allow people to override(?) we would need to bubble up all the original package's parameters so users can customize it though

#

idk, it's tricky... and ideally I'd like it to be as short as possible so people can inline it and don't need to nest our method inside a unit method

prime robin
#

I think a call back that uses whatever the user provides gives the greatest freedom

#

I generally opt for this in API design

daring turret
#

I am interested in the hard-line wrapping feature for typstfmt. I like how it formats in general, but I really value hard line wrapping.

sullen pivot
dusky peak
dusky peak
daring turret
dusky peak
#

hard line wrap is when an line break is inserted, it does that

#

That's exactly why I still use it.

#

Change the max line length if it's too big

dusky peak
ornate condorBOT
ornate condorBOT
dense vale
#

typst.js seems to be behind and unmaintained i haven't talked nor seen @prime iris in awhile

not sure what's the best forward here, could just archive it and point people towards @daring nymph's typst.ts.

previous discussions on why typst.js could serve a future with the existence of typst.ts had some nice ideas, but typst.ts ended up implementing them sooner or later anyhow so there really isn't any reason for typst.js to exists any longer.

#

hmm jacob is active on github tho 🤷‍♂️

prime robin
#

if he's the author it's up to him if he wants to maintain it

dense vale
#

no resp on this issue

Screenshot_2025-04-30_at_21.52.24.png
prime robin
#

ah i see

dense vale
#

@daring nymph does typst.ts offer a npm-based distribution of typst? or is it only api

👨‍💻 Includes the Typst CLI so you can npx typst

one feature people use typst.js for is this

#

fyi jacob recommended we have a npm org account which we do

Screenshot_2025-04-30_at_21.56.42.png
daring nymph
#

I'm sick and lying in my bed so I cannot give long answer soon. since the existence of the napi binding, it is promising to wrap an CLI with that instead of relying on a bundled typst-cli inside. It could also have same flags as the typst-cli.

dense vale
#

i recall recommending the same thing to jacob, that'd be a lot better yeah

prime robin
#

Ditto from me, get well soon!

dense vale
#

if @prime iris still is out of contact for ~2 weeks (i think this is reasonable), we'll go ahead and archive in favor of typst.ts

and migrate the typst npm package to that

daring nymph
#

I think some typst-cli wrapper (like typst.js) are also pretty good. In short we could have something like to pick a old typst binary quickly:

npx typst +v0.11.0 compile ...

the idea raised in my mind when I was making the vite-plugin-typst. we could have a napi interface easy to make js scripts as well as a thin wrapper to build some projects that can only be built with the old typst compilers.

dense vale
#

that's a great idea, but since your relying on a package manager anyhow i think it'd be simpler to just publish typst-matching versions of this

#

e.g

daring nymph
#

yeah, I cannot think a good solution to install them reliably, especially when GitHub is not accessible in my country.

dense vale
#

ngl that's still just insane to me

#

we'll sort it out when your all better must focus all efforts into resting!

ornate condorBOT
#
quachpas
[org] New discussion #14: Transfer Request for typst-algorithmic to typst-community

Project Name

typst-algorithmic

Initial Author(s)

Jade

Repository URL

https://github.com/lf-/typst-algorithmic

Status

Unmaintained

Description

Description: This is a package inspired by the LaTeX algorithmicx package for Typst. It's useful for writing pseudocode and typesetting it all nicely.

I have Jade's permission (I don't think I can tag her here @If-). I am creating this topic to track the migration to the typst-communit...

dense vale
#

@errant pulsar happy to add lf- to the org they’ll be able to transfer it then

#

I sent an invitation to them

errant pulsar
#

Thank you for managing this @dense vale !

ornate condorBOT
ornate condorBOT
dense vale
#

I sent an email to jacob just in case something happened to his discord

dense vale
#

i haven't gotten any response back from Jacob, it's almost(by tomorrow)/already is two weeks.

not exactly sure what's the best course of action here

#

@errant pulsar i noticed lf- joined the org, but the repo hasn't been transferred yet. Have you decided otherwise?

dense vale
prime robin
#

🤔

dense vale
# prime robin 🤔

i meant if we were to migrate it over to typst.ts repo and deprecate/archive typst.js

#

typst.ts seems to have a cli implementation which will work fine for "npx typst".

primary issue is as a library api, currently it's done through invoking the typst cli bundled with typst.js. Not through a programmatic api e.g napi. I'd rather just use whatever typst.ts currently offers for library use, rather than implement a simpler subset of it.

prime robin
#

Mmh

dense vale
#

@daring nymph what do you think is the best course of action here

errant pulsar
daring nymph
# dense vale typst.ts seems to have a cli implementation which will work fine for "npx typst"...

The cli is used for compiling typst.ts specific artifacts. I could suggest implement cli compatible with typst-cli:

  • node backend:typst-ts-node-compiler, which bundles native typst library.
  • web backend: typst-ts-web-compiler, which bundles typst library compiled in wasm.
  • cli backend: not sure how typst.js did it, we could also bundle typst-cli or install it from network.
    I see esbuild recently provide both wasm/napi packages. Thatt is very similar to our situation. People who preferred native performance could use node backend. People who are on unpopular platforms, like riscv64 and loongarch64 can only use wasm backend or cli backend (node backend is not pre-built in that platforms).
ornate condorBOT
ornate condorBOT
dense vale
#

@errant pulsar i've kept lf- as a maintainer and added you as a maintainer

dense vale
errant pulsar
#

nice, thank you @dense vale

dense vale
#

under tools/

ornate condorBOT
oblique star
#

Okay some time have passed and I want to transfer utpm to typst-community

#

first thing first, is the organisation okay to get utpm?

#

and then, how it works?

#

like my contribution to it, how do I pass it, etc

prime robin
#

there's an issue or discussion templat eon the org itself

#

where you can fill out why and what and such

oblique star
#

Okay thank you 🫶

ornate condorBOT
oblique star
#

(I've put Looking for volunteers / Unmaintained because I don't know what to put here)

prime robin
#

Well are you still maintaining it?

#

And or do you plan to after it's transferred?

oblique star
#

Right now, no
After it's transferred, yes

#

But it would be minor compare to what I've done in the past

dense vale
#

@oblique star feel free to transfer at any time

#

@prime robin do we start putting disclaimers on unmaintained packages?

#

least invasive option is in the description

prime robin
#

Unmaimted would mean lack of such a disclaimer or an explicit no maintainer label?

#

Latter seems sensible to me.

#

Oh I didn't see the second screenshot

ornate condorBOT
prime robin
#

I think "unmaintained" would still be better because the "???" sort of implies that they just lost track of who's doing that lol

oblique star
#

Done!

dense vale
oblique star
ornate condorBOT
#
VincentTam
[org] New discussion #16: Add a new SE site for typst

TeX has its own SE site, so why not for typst?

From discussions on typst's Discord server, I know there's a typst Discourse, where questions come in the form of forum posts with replies.
That's a great way for the question asker to interact with the answerer.

However, when multiple answerers come and they post at the same time, then the discussion might be a bit mixed up.
In addition, for other readers, the final answer itself is more important than the discussion in the middle. The ...

dense vale
dense vale
oblique star
#

Yeah! I have a branch for the publish command but everything else isn't done yet!
But it will require a lot of documentation on my side to explain everything I've done so far 💔

dense vale
oblique star
#

Surely! If you can make something with it, go ahead! Thanks!

dense vale
#

what are you trying to document exactly

#

a CHANGELOG or?

#

the actual tool?

oblique star
#

the tool

#

like the publish command is a MESS

#

nothing is tested, nothing has a little bit of text to explain what is it

#

nada

dense vale
#

doesn't look like it's implemented?

#

ah separate PR

oblique star
#

on the branch "dev-publish"

#

yeah

#

It's a mess I'm sorry 💀

dense vale
#

i thought you were eliminating the need for typst-project btw?

#

honestly for crates.io distribution why not vendor? if you still need it

oblique star
oblique star
dense vale
#

it just means including the project as a submodule or in the git tree

#

i don't mean cargo vendor, that sucks

dense vale
#

the manifest?

oblique star
oblique star
dense vale
#

not sure why its separate?

#

i guess it makes sense for generally working with typst.toml files

oblique star
#

Because tinger has done that package and I've used it, that's it

#

But yeah, idk if I can just copy the code and paste it in directly

#

Otherwise we need to reimpl it yeah, it's generally a good idea to check the manifest, but I HOPE someday typst-universe will have a package with manifest verification 🙏

dense vale
#

still wise to check prior to doing any publish work

#

guessing publish is just opening a PR in typst/packages?

oblique star
#

the last part is buggy, GitHub tokens are broken I guess?

dense vale
#

shouldn't be, odd

oblique star
#

can be my fault, totally learning here

dense vale
#

depends on how your authing ig

#

tho typst has a package manager internally would make sense for them to implement publish

oblique star
#

true!!!!

dense vale
#

ig utpm exists for filling that void

oblique star
#

When utpm will be debug entirely and clean, I want to create a PR to typst and add :
Publish and all about local packages (delete add ...)

#

Can only be a plus to typst

#

They have more or less suggested that could be a good idea

dense vale
#

it's a great idea, but does introduce a dep on a github client like octocrab

oblique star
#

nope that's the quack

#

I think it would be more interesting to work on a registry too

dense vale
#

a lot of work 😂

#

but eventually necessary

oblique star
#

True 😭🙏

dense vale
#

currently unscalable

#

esp the sources being in-tree

oblique star
#

I don't really know how it would work but yes 😔

dense vale
#

anyhow don't feel blocked by the documentation for V4

#

only matters when u do the actual release

oblique star
#

I'll try in June, for now I'm focused on my license and my master

dense vale
#

stale large prs aren't ideal

dense vale
#

do tell when you need any help getting things moving

oblique star
#

thank you!!

#

I'll tell dw

prime robin
#

Is it about the extra validation like for keywords and categories?

dense vale
dense vale
#

How big is the crate

prime robin
#

It's not that large I think and since rust links mostly statically it's not even all included

dense vale
prime robin
#

Eh I doubt that's very large either, it's not macro heavy or anything

#

Rust is not that slow when code is mostly free of heavy trait and type shenanigans

#

I think we could move them once there's a crate with registry transport types too

dense vale
#

@prime robin he can just yank the file out and take is_ident. I don't see any other reference to the files in the crate

prime robin
#

Essentially

oblique star
oblique star
crisp summit
#

I'm looking at packaging two small things (greenwood-tree for poems and rowtable for a table function that takes rows at a time). Names are not final, rowtable could use a better name.
Eventually I think it would be best if the packages have shared ownership. Maybe typst community or other separate collaborator that wants to share ownership would be cool

#

so I'm looking at your work (guidelines and template) to know what to do, it's all nice

#

for shared ownership - uh anyone interested first of all, and/or do you think going with the repos into typst-community immediately is the best way to go (source link where the packages are currently going to be staged from experiments to packages..)

prime robin
#

You could join the org and create them there, whether someone wants to join could be done after

prime robin
crisp summit
#

I read 'em. Just read and see what you think and maybe take home some of it 🙂

#

tinger be like: don't have hopelessly long argument names. That's when preserve-initial-spaces got a haircut (linebreaks? I'm confused)

prime robin
#

Lmao

#

If it's rarely adjusted it's probably fine

crisp summit
#

yeah

dense vale
#

@crisp summit, sent an invite. Feel free to create them in typst-community if that's what you decide on.

ornate condorBOT
crisp summit
#

thank you!

oblique star
#

Okay so:

  • I've merge dev into main
  • the publish command is now deactived because of this
  • i've create a lot of issues to let devs knows what isn't working / features I want to add
GitHub
Debug and finish `publish` command · Issue #46 · typst-community/...

It's been a while since #29 and #9 have been opened. I'll put something to warn the user about an unfinished command but that's it for now. It needs: Comments unit-tests debug creating ...

prime robin
#

I'm wondering if i should transfer tytanic to typst-community to increase the bus factor

#

I've also recently had a bit of motivational low point and would appreciate contributions

#

it being on community would probably increase visibility

#

But then the link to the repo changes again and I don't know how long github actually redirects things, or for which types of requests it does, i.e. does CI need to be updated for every consumer even for older links at some point?

solid umbra
#

but not 100% sure

prime robin
#

🤔

#

looks like it doesn't redirect github pages links

#

somewhat unsurprisingly i guess?

ornate condorBOT
prime robin
crisp summit
#

tytanic seems super useful. I haven't gotten into it, but it runs in CI anyway for unit tests. Will look at ref tests later

prime robin
#

mess of a code base atm, but it gets the job done

flat bane
#

I'm in general too busy to contribute meaningfully to either, but I have my own native Rust Typst tool to publish at some point (a preprocessor for prequery, aka shell escape) so I can imagine making minor contributions to both utpm and tytanic at some point to get a feel for that kind of project. So I welcome both recent transfers in that regard - at least socially it feels like decreasing the barrier for contribution!

dense vale
#

u could, when releasing a new major version, deprecate the old version and that will warn the users?

prime robin
#

ok that's good to know

prime robin
#

Regarding the Tytanic transfer:

I've noticed that the license of the project is ambiguous/conflicting the docker image label and repo file indicate MIT, but the cargo manifest specifies Apache 2.0, I've opened an issue and would appreciate if all contributors consent to licensing under MIT OR Apache-2.0, Iv'e chosen that as it is reasonably permissive and keeps expectations regarding previous contributions fairly stable I think.

I'd like that resolved before I do the transfer, thankfully there's only about 5 other contributors so far.

cc: @flat bane @solid umbra @dusky apex

dense vale
#

i wonder if this can be done automatically

prime robin
#

could proably be done dyunamically with a simple server

#

would be cool

dense vale
#

let me look it up

prime robin
#

right you can point gh pages at a custom domain

#

i did that once but can't remember how exactly

#

i thionk it's just a DNS entry

dense vale
#

is this all what's needed or?

#

huh would it work with a query or would it require subdomains per project as in
typst.community/tytanic or tytanic.typst.community

#

which would you prefer @prime robin ?

prime robin
#

idk honestly

#

probably the path version

#

maybe that conflcits with future plans for the domain

dense vale
#

docs.typst.community/tytanic could also work

#

but eh too long

#

tytanic.typst.community is safest

prime robin
#

the community tld is kinda long in itself

dense vale
#

yeah

#

@prime robin do you want a unified documentation standard, or we leave it up to each project?

prime robin
#

well for now i just got my own mdbook but I'm not opposed to unifying them with a proper doc framework in the future

dense vale
#

it makes sense for typst libraries, but others i'm not sure

#

@daring nymph's shiroa is nice

#

primarily being able to search like this

Screenshot_2025-06-01_at_17.12.21.png
flat bane
#

I have the concern that standardizing too early will lock us in. I haven't looked at shiroa in detail, but since it predates official experimental HTML support I assume it employs some hacks? And mdbook is not Typst integrated (unless you've done something there, tinger?) So I wouldn't standardize just yet.

#

URL-wise I have a slight preference for docs.typst.community/package, but whatever is technically feasible works for me.

dense vale
flat bane
flat bane
dense vale
#

fair point

flat bane
# dense vale oh right tidy is in typst

to be clear I'm not saying that Tidy-the-package is what should drive the docs. But if whatever system we use should support

/// = Panics
/// In *extraordinary* circumstances

instead of

/// # Panics
/// In **extraordinary** circumstances

then some sort of HTML export of Typst markup is required.

dense vale
dense vale
#

docs.typst.community/package it's already too long so making it a subdomain might not be an ideal experience

flat bane
#

I see. pointing typst.community directly at GH with separate repo paths will lock us out from showing a page at the root of the domain, I assume. One option could be to push all built sites into the same org pages repo with some action, though that sounds a bit non-standard...

dense vale
#

i mean until there is a viable typst documentation generator that uses HTML export i don't see how we can go further here.

#

For now for tytanic, the mdbook can be published under /tytanic since that's the most probable path i think we'd take in the future if we end up managing to unify documentation.

daring nymph
#

there is an internal doc command which generate docs in md. this is only used for me debugging generation of lsp docs

dense vale
#

@flat bane i just tried the html export, isn't it good enough to use now? I noted somethings aren't supported, but generally the Typst you'd see in comments wouldn't use most of these yet to be supported elements

flat bane
dense vale
flat bane
#

So ideally I would want to be able to migrate my PDF manuals to HTML, and those also have content besides the doc comments that may be, generally speaking, more complex. Maybe it's still sufficient, idk.

But apart from HTML export, we need some kind of doc platform. If Shiroa is simply great that could be something we could standardize towards. I just can't confirm for myself whether it can do everything. If it can't, letting people decide between mdBook, Shiroa, etc. could be a short-term solution.

prime robin
#

I mean so far shiora is basically mdbook but typst right

#

So it has a specific layout and no generic features specifically for reference documentation

flat bane
#

ah, I didn't even realize that. Maybe a sign that I should stop talking about software I haven't tried yet 😛

prime robin
#

That's how I remember the announcement and showcases, I too have not used it

daring nymph
daring turret
crisp summit
#

does anyone have a go-to way of installing fonts in github actions? Let's say specific ones like atkinson hyperlegible next and EB Garamond

prime robin
#

I've looked far and wide and there are some unmaintained tools that allow downloading from google fonts but nothing well maintained from what i can tell

#

I've basically went with installing them in the docker containers using whatever package manger is available

#

or just straight up including them in the repo

crisp summit
#

aha I see

dense vale
#

i would personally just setup a nix flake in my project and then that'll give me the font anyhow alongside the typst compiler plus any other tool necessary using a nix action

#

but nix in itself is a convulted path not worth learning simply to get an external font in CI

crisp summit
#

those two options, fontpm and so on sound promising

dense vale
#

have like a (just|make)file step to do that or a simply shell script if u dont use a taskrunner

#

better than constraining it to the gh action

#

committing to repo with the font license is simplest option

crisp summit
#

there's some point to that, treating it as a dev dependency for both developers and GH actions

dense vale
#

if it's a package, the way typst package manager works, it won't be in the final bundle anyhow so it's fine to just have it as part of the repo itself

crisp summit
#

I thought I'd use it for manual, readme and examples mainly

dense vale
#

individual weights are like 48-52 kb each

#

eb garmound is <1mb variable, each weight ~500 kb

crisp summit
#

hm right, so it's quite small. variable doesn't work for typst though

crisp summit
dense vale
#

kb

#

😂

#

so yeah committing it in source is fine

daring nymph
#

@crisp summit

crisp summit
#

nice, ok, will try

daring nymph
#

it can be easy to customize package rendering.

  1. I give a package-doc.json
  2. load package-doc typst function from some place.
  3. generate a file which feed json data to package-doc and compile it using html export

I think tinymist docs could be:

# export docs to html
tinymist docs @preview/touying:0.6.0
# export docs to html, using the `package-doc` function from @local/custom-rendering:0.1.0
tinymist docs @preview/touying:0.6.0 --loader @local/custom-rendering:0.1.0
# export docs to json
tinymist docs @preview/touying:0.6.0 --format json
#

@dense vale @crisp summit

oblique star
#

#discussions message

Could this be interesting?
We already discussed a bit about a package registry, could this be added with it?

ornate condorBOT
ornate condorBOT
prime robin
#

I contacted Steven and he sent his consent for the re-licensing, so I'll go ahead with the transfer I think.

sullen pivot
#

The new one is called Atkinson Hyperlegible Next

daring nymph
#

I was told that all fonts on fontsource are woff and variable fonts. This is known to not usable for typst unfortunately.

crisp summit
#

file sizes for atkinson hyperlegible next are very small, so it was an easy choice to include in the git repo

sullen pivot
#

Hopefully someone will contribute variable font support eventually. Though it's not a trivial feature design wise

ornate condorBOT
prime robin
#

I would appreciate if you could give me whatever the highest role for the repo is @dense vale

#

it would probably be nice if we had one more administrator

#

bus factor and all

daring nymph
dense vale
dense vale
prime robin
#

We could vote for a person to be added as administrator?

#

idk

prime robin
dense vale
#

hmm, how do you decide the voter criteria?

#

not all people of the organization are part of the discord

#

maintainers i guess majority are here

prime robin
dense vale
#

except one inactive,

#

or two?

#

jacob and james

prime robin
#

create a discussion and ping the org? People can nominate and then vote i suppose, not sure if votes can be restricted to the org, or if that is a good criteria.

dense vale
#

nixpkgs recently did something to nominate new committers might be useful

flat bane
#

imo making tinger an admin would be a no-brainer 😛 but we can make it a bit more formal too 🙂

dense vale
#

recently, it's already a year...

dense vale
dense vale
prime robin
#

as long as you don't fall victinm to the bus factor it's no hurry indeed

prime robin
#

jj also recently drafted governance and did a poll for this but everyone was able to vote

dense vale
#

nix is bit messy, a flat out github issue where anyone can post anything

#

others nominate a person/+vouch?

#

plus they relied on existing contributions/reviews to the repository

dense vale
prime robin
#

yeah, maybe we don't need to do it quite as formal

dense vale
#

all what you want is the approval of people who have some sort of defined "stake" in the organization

prime robin
#

Yeah I think that's the most important part

dense vale
#

i'll exclude those inactive

prime robin
#

jj also worked well before this, they mainly did this beacuse of an effort towards leaving google ownership

#

before that it was informal and just active people as maintainers

dense vale
#

okay, here's my suggestion,

a simple makeshift solution:

make a new discussion board "Administration Nomination" post, have people self-nominate with reasons why. I'll actively try to reach out to maintainers of different projects to have them participate, they could reply to the nomination thread for questions to each nominee, but voting will be reliant on the reaction system simply vote thumbs up.

prime robin
#

Yeah that sounds good

dense vale
#

i will not exclude others from voting, but the weight of their votes will not be the same as maintainers

#

we look for majority in maintainers? or all active?

prime robin
#

I don't think you can inspect the votes on a discussion can you?

dense vale
#

thats why i relied on reaction system

prime robin
#

And I don't think we need to have them weighted

dense vale
#

i think i can see them all using the API

prime robin
#

ah damn i think the docker packages have not been trasnfered

#

that sucks

dense vale
#

the frontend doesn't show all, but the API probably does

dense vale
prime robin
#

We just count them as is

#

I don't think they should count any less or more

dense vale
#

hmm

#

but if it was 1 maintainer 10 non?

prime robin
#

it's typst community after all

#

I double we'll get that kind of skew

#

and if that may mean more participation

#

win-win?

dense vale
#

how many people should be organization administrators?

prime robin
#

Should we view them as the same power as an owner?

#

if yes then probably an odd number i.e. 3

#

1 owner + 2 admins

#

if not, then just having an additional person that can do stuff is probably fine

#

I think for now the latter is fine

dense vale
#

there's only two possible roles here an owner or a member

prime robin
#

ah ok

dense vale
#

one more owner is fine, as it is best practice

#

but anymore i'm not sure

dense vale
prime robin
#

Ok then, sounds good

dense vale
#

okay so the discussion thread should be for the nomination of one more person with the ownership role in the organization

prime robin
#

We need a date by which the votes are counted

#

How does 1 week sound?

#

good, shorter, longer?

dense vale
#

informal* discord poll for the date?

#

it's summer after all, many are on vacation. I'm afraid 1 week might be too short, but that could be a false worry which is why i suggested a discord poll

#

in one week increments? up to a month? 1 week, 2 weeks, 3 weeks, 4 weeks?

#

how's this? @prime robin i put it for 3 days

prime robin
#

That'll work i think

#

@flat bane could you pin that?

flat bane
dense vale
# dense vale
poll_question_text

How long should a nomination thread for the addition of one GitHub owner of the Typst Community organization on GitHub discussions run for. Note: "Owner" has full control over the organization.

victor_answer_votes

3

total_votes

7

prime robin
#

Good start it's tied

#

I'm willing to change my vote to 4 weeks

dense vale
#

that's fine, i haven't voted fyi

wintry cosmos
#

I certainly don't mind if it's open for too long, I mostly have 2w as a minimum

oblique star
#

It's not something simple, giving power to someone on every repository of typst-community
I prefer that we give a little more time (4 weeks)

flat bane
#

I pinned the message and then forgot to vote 😛 I don't feel super strongly either way, but I think there's no harm in making it four weeks. It's not annoyingly long, and it is quite a bit of rights.

wintry cosmos
#

so there's a consensus. Do we have the candidate list settled? Anyone want to appoint themselves?

prime robin
#

I think that happens on the discussion thread as top level answers

#

We open a thread with what it means and what the requirements are (has to at least be active in the community yadda yadda) and people can both nominate themselves and others, whether someone who doesn't self nominate actually takes the spot is up to them

daring nymph
# dense vale

the main point might be ensuring that most typst users concerning about it can see the announcement. so we should also determine a good place. like I think one or two weeks should be enough if it is placed in the official announcement thread, but one year may be not enough if we place it in #off-topic.

prime robin
#

I think a post on the forum paired with the discussion is pretty visible

dense vale
prime robin
#

Then they're late

dense vale
#

mmm

#

thinking about the other option, a list of candidates it doesn’t solve it either I guess

#

there isn’t any solution except trying to attain visibility as myriad mentioned

prime robin
#

4 weeks is plenty of time for nomination and vote I think

#

At least for those active in the community

dense vale
#

no requirements? anyone can be a nominee?

prime robin
#

No if say they have to at least be active community members

#

Active on the forum or discord or active maintainers of projects

dense vale
#

how do you define "active"?

#

do you want them to list what they have done for the typst project?

prime robin
#

I wouldn't put a particular number on it

#

As long as it's regular

dense vale
#

as a mean of persuasion?

prime robin
#

Someone just saying "hey, yeah, I'd like admin rights on here" is not enough

dense vale
dense vale
dense vale
#

how should we proceed from here? I have no problem opening the discussion thread at any time, do we open the typst forum thread prior?

#

and how long should we give the typst forum prior to creating the discussion thread? do we just open the nomination thread right after?
i guess its fine to open both at the same time since the nomination thread is 4 weeks long

prime robin
#

With the forum being a thing I wonder if the discussion thread even makes sense on its own, perhaps a forum thread is good enough on its own?

dense vale
#

i'm not sure if the maintainer of setup-typst is on the forums for one

prime robin
#

OK so we use the forum thread to basically repeat the talking points and link back

#

And create them at the same time I'd say

dense vale
#

yeah sure, but can you resolve https://forum.typst.app/ ?

Typst Forum
Typst Forum

The Forum is the place to ask questions, get answers, and show off the cool stuff you are doing with Typst.

#

i'm not sure why i can't

#

i haven't been able to for awhile oddly

#

is there an outage or?

prime robin
#

Uh

#

Loads for me

#

What's your region?

dense vale
#

huh it loads when using a proxy

#

i hope it's not an isp issue

#

oh looks like a browser issue, loads in safari

prime robin
#

OK so I'd say the requirements for nomination should be that nominee has non-trivial and regular activity in the community

  • not just one timers or every x months
  • not just asking questions for example, but also answering, maintaining, translation, yadda yadda
dense vale
#

General category on the forums?

prime robin
#

A nominee should obliviously be impartial and not have any obvious crash outs anywhere.

prime robin
#

I think it's also obvious that a nominee should follow the CoC of both the community and typst's discord

dense vale
#

Q&A format on github discussions? Or simply a "General" discussion?

#

only difference is getting to select and therefore highlight an answer at the end

prime robin
#

I guess the answer is nice for marking the chosen nominee

dense vale
#

yeah

#

should we clarify responsibilities?

prime robin
#

Yes absolutely

dense vale
#

Call for Nominations: Second Administrator

👋 Hey everyone,

The Typst Community organization has been around for two years now (since 2023!), working to support and grow Typst-related projects. Since the community’s grown a lot, we think it’s a good time to add another organization owner. Mainly for bus factor, but also just to help keep things running smoothly. After some discussion on Discord, it feels like the right move and the right time.

Nomination Requirements

  • You should be regularly active and genuinely involved somewhere in the Typst community, not just popping in every once in a while or only asking for help. This could mean being active on the forums, Discord, or anywhere else Typst folks gather. Stuff like answering questions, maintaining projects, translating, or helping out in other ways all counts.
  • Please follow the Code of Conduct for both our community and the Typst Discord.

Election Process

  • This thread will be open for 4 weeks from today (June 18, 2025) through July 16, 2025.
  • Only self-nominations: if you’re interested, just reply here and tell us why you think you’d be a good administrator!
  • After 4 weeks, whoever has the most +1 reactions on their nomination wins.

Responsibilities

  • Onboarding new members to the organization
  • Facilitating project transfer requests
  • Facilitating maintainership updates for all repositories when needed
  • Handling org-level settings (like updating team permissions or GitHub settings)
  • Moderating community spaces managed by the organization (e.g. discussions and issue trackers) and enforcing the CoC
  • Reviewing and approving new repository proposals
  • Acting as a point of contact for external collaborations or partnerships
  • Helping resolve conflicts or disagreements within the community when they come up

If you’re interested, go ahead and nominate yourself below!

#

something along the lines of this?

prime robin
#

Yup

#

Responsibilities would be

  • managing repository transfers
  • moderation of community spaces managed by the github org (discussions and issue trackers) and enforcement of CoC
#

Non-exhaustive list

dense vale
#

good points

#

i guess an administrator would also be the one facilitating maintainership changes

prime robin
#

Mhm

dense vale
#

onboarding new members?

#

i've been willy nilly adding anyone who'd like to become a maintainer/transfer repositories i guess thats fine for now

prime robin
#

Sure, I wasn't sure about that one currently we add people as is if they want to

#

Haha

#

Yeah

dense vale
#
  • Onboarding new members to the organization
  • Facilitating project transfer requests
  • Facilitating maintainership updates for all repositories when needed
  • Handling org-level settings (like updating team permissions or GitHub settings)
  • Moderating community spaces managed by the organization (e.g. discussions and issue trackers) and enforcing the CoC
  • Reviewing and approving new repository proposals
  • Acting as a point of contact for external collaborations or partnerships
  • Helping resolve conflicts or disagreements within the community when they come up
#

do we mention teams?

prime robin
#

I think the permissions and such imply this clearly

dense vale
dense vale
#

where should we redirect people to ask questions relating to the process/org?

#

in the discord?

#

and people should be able to ask nominees on the thread right?

prime robin
prime robin
dense vale
#

i'll just modify last sentence redirecting to the discussion board for posting on the typst forums

prime robin
#

Lgtm

dense vale
#

when do i post?

prime robin
#

I guess at some full hour if we really care about the exact length of the nomination

#

I think it doesn't matter too much as long as we have it open for 4 weeks

ornate condorBOT
#
huwaireb
[org] New discussion #18: Call for Nominations: Second Administrator

👋 Hey everyone,

The Typst Community organization has been around for two years now (since 2023!), working to support and grow Typst-related projects. Since the community’s grown a lot, we think it’s a good time to add another organization owner. Mainly for bus factor, but also just to help keep things running smoothly. After some discussion on Discord, it feels like the right move and the right time.

Nomination Requirements

  • You should be regularly active and genuinely involved so...
dense vale
#

https://forum.typst.app/t/typst-community-call-for-nominations-second-administrator/4630

Typst Forum
(typst-community) Call for Nominations: Second Administrator

📌 Please note that we are unaffiliated with the official Typst team, this is a separate organization. 👋 Hey everyone, The Typst Community organization has been around for two years now (since 2023!), working to support and grow Typst-related projects. Since the community’s grown a lot, we think it’s a good time to add another organi...

#

@errant pulsar @oblique star @prime iris @flat bane @heady grove @obtuse solar @crisp summit @tough crown @solid umbra @daring nymph @prime robin @elfin sparrow @lost void @jagged ridge

i've mentioned every member of the typst-community organization above, please do take note of the above.
I'll reach out to yusancky as he's not in the discord.

#

i've pinned the discussion, do feel free to up vote it in order for it to gain visibility in github discussions as that i cannot control

elfin sparrow
dense vale
elfin sparrow
#

Has indeed! Finished PhD corrections and so haven't used Typst in a while

prime robin
#

One of the mods should pin this one too and unpin the previous poll

dense vale
elfin sparrow
#

That lilaq package by zen is 😘🤌, im almost sour about that fact that I couldn't get to use it more extensively

lost void
dense vale
flat bane
errant pulsar
prime robin
#

Maybe you're up for it?

dense vale
#

is the org still active?

#

mm

prime robin
#

I'm unsure but i saw the thread was not answered at all

dense vale
#

ill unpin the thread

prime robin
#

Last human authored commit on typsium/typst-atomic was 19d ago

#

Doesn't seem abandoned to me

#

It's an honorary position anyway

#

I figured James makes sense as he is a chemist

dense vale
prime robin
#

Active branch?

#

Main?

#

Oh you mean they're working on a branch there

#

Which is less old

dense vale
#

still seems to be a two-person effort

prime robin
#

Well that's OK, but it is ongoing

#

Well see what James says

elfin sparrow
#

I did put thought into a more intuitive input format for declaring structures in Typst but came up blank because of the inherent complexity of molecules

prime robin
#

Well this was more about the honrary position

tough crown
tough crown
elfin sparrow
#

Social overwhelms mostly, I'm now fairly confident I can only handle a small number of communities with which I interact at any one time :p

tough crown
#

yeah totally, I understand

elfin sparrow
#

I was looking at how easily I might add ternary diagrams but it might flatter you to hear that your code skills eclipse mine

tough crown
#

Ternary diagrams would be crazy, however I have no idea how to integrate that at the current stage ... 🤔

but it might flatter you to hear that your code skills eclipse mine
I appreciate the compliment although I think that every programmer has their own powers and specialities, the field just has so many dimensions to it.

dense vale
#

managed to reach yusancky and make him aware of the fact we're nominating a second administrator

daring nymph
prime robin
#

Yes

#

I'd say so

#

Rust just has an RFC repo which just contains each one as a markdown doc identified by a sequential number

#

I left a comment linking back to the discussion we had when mc-zen proposed some new syntax

#

Which is essentially like a mini RFC, I'm just a little confused why we seemingly converged on an easy-to-parse and less ambiguous new syntax on that issue, but it wasn't implemented by tinymist anyway? There are some good points in the discussion ntjess linked there, but you didn't bring those up on the one we had with Mc-zen at all.

#

That one is still open, I'd not point to this as authoritive, but I'd say Mc-zen wouldn't have implemented the new syntax if he didn't have the same conclusion of seeming in agreement.

#

cc: @lilac knot @tough crown

daring nymph
prime robin
#

Oh :/

#

Unlucky I guess

daring nymph
prime robin
#

Ah but wasn't the end result that new new parser can handle these good enough? These are really contrived examples

#

Most you'll see people write is a simple arrays destructure and even then I'd recommend against destructuring anyways because it doesn't make much sense for the caller from a docs perspective

daring nymph
# prime robin Ah but wasn't the end result that new new parser can handle these good enough? T...

I don't think it is good enough and parameter destructing can help readability in certern cases. For an example:

/// A point add function.
///
/// x1 (float): the x-coordinate component of the left.
#let add((x1, y1), (x2, y2)) = (x1+x2, y1+y2);

Comparing with:

/// A point add function.
#let add(
  (
    // the x-coordinate component of the left.
    // -> float
    x1,
    // ...
    y1
  ), 
  (
    // the x-coordinate component of the left.
    // -> float
    x2,
    // ...
    y2
  )
) = (x1+x2, y1+y2);

I personally like the old syntax.

prime robin
#

I don't think how an array is destructure should be of concern for the caller, that's an implementation detail of the function

#

Most of the time it's documented as being a coordinate (in this example) after which the user would know what to pass

#

The immediate destructuring also means the callee cannot emit a good diagnostic

daring nymph
#

Isn't (x1, y1) telling that it is a tuple of the two floats, which should be known by the caller? It is not a detail I think.

prime robin
#

Most public APIs have no type for such cases and validate after it's passed in to emit a better error message

prime robin
#

Cetz calls them positions or coordinates I think

#

Especially since they're usually polymorphic, allowing different forms

#

I have yet to find a case where an array is passed and only an array is valid (in which case it shouldn't be an array)

#

I can see the appeal of the more granular documentation there

#

But I think the use case is just too fringe, it would only apply in cases where it shouldn't even be used like that anymore

#

In my opinion

daring nymph
#

🤔 This kinda solves the problem of documenting functions with parameter destructing, you think it is not possible to have an API which has parameter destructing, but not directly.

prime robin
#

I think destructure parameters are too rare for them to be the reason to not use the new syntax which has a number of improvements in many other areas

#

Not even cetz uses these because their cords are not just simple arrays most of the time

#

Personally, If I look at a function I want to see the actual parameters I will pass, not their components on every function, a square or octagon drawing function would be horribly crowded in the docs for no reason

daring nymph
# prime robin I think destructure parameters are too rare for them to be the reason to not use...

What about following other questions (in https://github.com/Myriad-Dreamin/tinymist/issues/1789#issuecomment-2931773209):

  • Will typst allow docstrings between parameters, in regard to many languages not allowing that?
  • How do we document a function having more that one signature with new syntax, like rgb(hex) | rgb(r, g, b)?
    Overall, I think new syntax doesn't introduce new functionalities but is adding more problems.
prime robin
#

For the former, we don't know, in the end it's up to laurenz, but we've talked about why they were chosen, it greatly declutters the actual help text and is inline with the actual docs also have in per parameter location separately

#

These are just not feasible with either doc string are they? That would be an arg sink anyway.

#

Unless you have an idea how to do this, perhaps with separate signature of the whole function like in Haskell one for each overload?

#

For the former though, one could say this is largely just done because we don't yet have custom elements which definitely will have their own field docs

daring nymph
daring nymph
# prime robin Unless you have an idea how to do this, perhaps with separate signature of the w...

I actual had some unfinished ambiguous idea to do that:

/// - hex (str): A hex
/// - r (color-channel): ...
/// - g (color-channel): ...
/// - b (color-channel): ...
/// #let rgb(hex) = _; // candidate 1
/// #let rgb(r, g, b) = _; // candidate 2
#let rgb(..args) = impl-it;

It is true that both the old syntax and the new syntax don't support signature candidates, but it is also what I said "new syntax doesn't introduce new functionalities but is adding more problems."

prime robin
#

I wouldn't say that it strictly adds new problems, it was specifically designed to aid eventual migration to type hints and custom elements.

prime robin
daring nymph
prime robin
#

I would say no, it has a lot of custom syntax which clashes with regular typst

#

It works, but it's not very future proof

daring nymph
# prime robin Perhaps it's time to start the discussion about it again with him? Verdict from ...

I presume he is busy working towards v0.14, and syntax of docstring is not in scope of v0.14. and docstrings is less important than type annotations, and recent string interpolations. In this situation, perhaps we can discuss and prepare a note first, like.

  1. demand analysis: what specific functionalities we would like to have (may do a literature study to check how other languages have and would like to have). For example, "documenting signature candidates" is a thing that I find in the LSP spec.
  2. annotations in comment, such as warning suppression and 3rd-party tool annotations (like typstyle's @typstyle off).
  3. syntax of docstrings on different items, like let bindings, parameters, files, modules, and packages.
daring nymph
prime robin
#

I could prepare an RFC repo on typst-community an which you can write a PR for a draft?

#

Similar to how rust does it

daring nymph
#

Sounds great.

prime robin
#

We could ping mczen about it

daring nymph
#

A small question, should we use typst and HTML export instead of md rfc?

ornate condorBOT
prime robin
#

Made the repo and copied the rust etc template roughly

prime robin
#

Would probably look much snazzier but harder to view on PRs

#

The rust RFC PRs always linked to the markdown file and you can just view it instantly on the web

daring nymph
#

But view typst source code on PRs also doesn't look like a hell. I believe typst sources pretty readable.

prime robin
#

Yeah honestly that sounds nice

#

Adding contributors is fairly easy

#

I've added the ecosystem team as triage members so they can label and review issues and PRs

tough crown
#

Hey, seems like I missed most of the discussion already. To keep it brief let me just address a few points

tough crown
# daring nymph I actual commented on the tidy repo, but that was closed since I didn't make res...

At the time, there was just the comment on the old parser which I chose to keep around for a while and the comment about destructuring which I agree with @prime robin is not so much of a concern because it should be an implementation detail of the function. Think about the built-in functions line, curve, etc. They accept coordinate pairs and how they exactly look like is described in the param description.

#

I also don't think that the new syntax just introduced new problems. In fact, the problems you mentioned were already there in the old syntax. On top, some issues were solved (like the special syntax for parameter lists and non-Typst-standard syntax).

#

Also the parameters now don't need to be named anymore. This is very beneficial since the parameter names cannot go "out of sync" by accident when the function signature is changed.

#

As an author of many thoroughly-documented Typst packages and after having used both doc-syntaxes for a long time, I would say that I'm way happier with the new syntax than I was with the old one. It feels easier and cleaner - especially for functions with many parameter - to have the description close to the parameter.

#

All in all I believe experience and time will tell. Typst may or may not define a standard way of documenting functions, however, consistency will matter a great deal for tooling.

Some experiments need to be made and tried in real-life and this is what Tidy has been doing from the start. I'm aware that it can't be perfect from the start, but a great effort is made to experiment with doc-syntax before something official needs to be declared, so that the decision can be based on experience values.

prime robin
#

Would be great to incorporate that into the RFC draft

#

And the initial considerations on the guidelines PR

tough crown
#

Also I'd like to hear more opinions from package authors that have been using one or the other syntax or both. I know that parsibility of a certain syntax matters a great deal for tools (some things are just harder to parse) but UX should be even higher on the priority list − at least that is my opinion.

daring nymph
daring nymph
daring nymph
#

@tough crown btw, what's your opinion about non-inline docs on insanely large functions to avoid putting docs inside of many ///s? Just like that:

/// #include "/docs/codly.typ"
#let codly(the-sea-of-params) {}
tough crown
tough crown
prime robin
#

@daring nymph @tough crown would you guys like to join the ecosystem team on typst-community?

#

You both develop things that have stronger ecosystem impact than some other packages/tools

#

I'd also say the team description should be renamed to just "Typst ecosystem Style and API guidance" to reflect that

#

cc: @dense vale thoughts?

#

also regarding the RFCs while we're at it

#

I apologize for all the pings and notifs on github I'm preparing a few issues and PRs

dense vale
prime robin
#

Ah i would've waited for whether they agree since that also comes with pings and such

dense vale
prime robin
#

yeah about the increased scope of the team

dense vale
#

gotcha

#

btw the rust-lang/rfcs link is broken oddly? seems to be github bug

prime robin
#

i forgot the https://

#

wrote that at work

#

wait no i did not

#

i forgot the double slash

dense vale
#

oh

prime robin
#

a pesky typo

dense vale
#

right

#

i did see the https so i was confused

prime robin
#

Regarding the idea of using typst for the RFCs, put your Ideas and opinions here please

#

Any sign of life from @heady grove @hybrid moat? (don't know which one is the active account)

elfin sparrow
#

RFC for template arguments 🤤

prime robin
#

elaborate?

elfin sparrow
#

Like for journal article templates, which broadly should all take the same arguments and be roughly interchangeable, are not

prime robin
#

Ah

heady grove
#

Visiting Discord in particular has become tedious when they blocked it here.

prime robin
#

Just wanted to check up

heady grove
#

I've finished my bachelor (with thesis and presentations in Typst, of course). I hope to spens some time on Typst-related things in this summer, but not sure I will, having too many things require attention.

prime robin
#

congratz :)

prime robin
prime robin
#

Is anyone up for drafting an RFC process for typst-community/rfcs adapted from Rust's RFC process? I have laid down some thoughts on #2

#

Mostly that it should be simpler since these are less official and typst is still less stable

crisp summit
#

I want to publish another package. I've already gotten "permission" (if there is one) to create rowmantic (created) in typst-community, and also greenwood-tree (poetry, does not yet exist) and would like to ask for a third package (term list as table under name tabbyterms). It just feels a bit awkward if I go ahead and create so many repos in the org, but maybe it's ok.. It just feels more future proof to start in a place where spare owners exist and can pass on (or share) maintainership if necessary

elfin sparrow
#

It's relatively straightforward to transfer a repository to the community after the fact, if you wanted to get the ball rolling first, but ultimately I don't think it's a big problem. I'd probably recommend that if you have so many on the community org on the go at the same time and that they are at early stages, it would be nice for you to make "help wanted" style issues (even if these are things you will end up doing yourself) to give people an easy "in" if they wanted to help out

crisp summit
#

yeah that's a good idea, will do that. Maybe I do have the ball rolling a little bit (pre publication) but it's staged in a colocation github repo and I want to break them out into one git repo per package for publishing anyway

prime robin
#

I think James is right, it's probably not a big problem

#

Worst that could happen is that you snipe the name and that'll happen if you open a PR from your personal repo too

crisp summit
#

thanks, just wanted to check that before creating

#

Do you think there will be some name shuffling when typst changes from @preview to something that's not preview? I guess nobody knows. It's reasonable that established packages stay and abandoned ones leave their names free at that point (maybe?)

prime robin
#

I have not had any conversion about this so far, we'd have to ask Laurenz and Martin what their ideas are but those are probably without any warranty for now

ornate condorBOT
elfin sparrow
#

I'd probably want a name shuffle - package names are first come first served, but its not always the first that is the best package and the better name might have already been taken

prime robin
#

We'll see I'm sure prominent packages will receive their names on the new namespaces

#

I'm still unsure how namespaces will eventually work and I think it's not decided anyway

oblique star
#

We could potentially reserve @community

#

(better than @typst-community)

prime robin
#

On the universe? I'm sure we could get that, it obviously makes no sense to add typst before that

#

But this still depends on how those will be structured at the time of 1.0 or so

ornate condorBOT
crisp summit
# ornate condor

realized the minute after it should be the v0.1.0 convention for typst-community (I think)

oblique star
#

Two weeks have passed, and Tingerr is in first place (with no other applicants)

prime robin
#

Sort of unsurpring, tbh. I doubt people would want to nominate, if they haven't been here. And those who have been here all seem busy enough.

prime robin
#

I'm currently drafting the RFC process document by adapting it from the Rust RFC repo.
One of the larger changes is that there are no sub teams, but instead community tooling maintainers that should sign off on RFCs that affect their tools.

I'd like to add the following teams as sub-teams to ecosystem on typst-community such that they can easily be notified about RFCs with certain tags. I've thought about the following teams (and accompanying labels on the RFC repo):

  • test-runners: There's the tinymist internal test runner and coverage testing and tytanic for general regression tests.
  • formatters: There's like three at the moment, I think? We'd have to look at who needs to be added there and which tool is actively maintained.
  • analyzers: There's tinymist and typst-lsp, though the latter is unmaintained at the moment. But this would include language servers, linters, static and dynamic analyzers, anything that does syntactic or semantic analysis.
  • package-managers: There's utpm and typship, though utpm is currently unmaintained.
  • packages: This one is tricky, we don't want to add every package, template or plugin maintainer, perhaps we could call for representatives to be nominated and added to take on the duty of speaking for other maintainers. In the end everyone should be able to review on things, but the team members would be more authoritative voices on matters of contention.
  • others? There are also other tools like site or book generators, e.g. shiora and such. Perhaps we can add a other team and label for this. I can also imagine that we'll see things like package registry maintainers or other typst related projects pop up that should have a say in these things.

Once maintainers from those projects are added RFCs could be used to properly propose and discuss things before they are either implemented in community tooling or proposed and implemented in Typst directly. All in all, I think this will help build a more coherent experience for Typst users by making sure community tools agree on formats, standards and conventions.

What do you guys think about that?

My idea is that an RFC would be useful for three things:

  1. Propose something that more than one tool or package should support but isn't meant to be part of Typst at all.
  2. Propose something that more than one tool or package should support but isn't yet meant to be part of Typst (like doc syntax) where the community tooling can test and refine the feature before presenting it to the compiler maintainers.
  3. Discuss and prepare a larger change to Typst to save the maintainers time in advance.

Some open questions:

  • Should one maintainer be in more than 1/2/3/... teams?
  • If yes, if an RFC is a point of contention, should their voice count for each team that the RFC is labeled with?
  • How many representatives should be in each team, one for each tool? Every maintainer for each tool?
  • Which other teams and labels should we add? Should we remove/split/merge some of them?
flat bane
#

What I don't see represented are bindings for Typst as a library (comparing with the tooling tag description of the forum (disclaimer, written by me), not with what kinds of projects we have in the community)

I'm trying to imagine how the groups will affect actions and notifications in the community. For example, a discussion about type annotations would affect formatters, analyzers, and packages. That's a substantial part of the team, but not pinging test-runners sounds like a win.

#

I'm a bit "worried" that we're creating a taxonomy that's too granular. For example: if I make advances on my prequery preprocessor, do we create a new team "preprocessors"? I don't think it fits in the current teams. Or there could be multiple competing package templates, should there be a subteam for that? It doesn't really cost us so it's not really a problem though, just a mild concern.

The converse approach would be to create subteams when the volume of notifications gets so high that only notifying a subteam makes it more manageable for those unaffected.

  • Pro: when a subteam is created, it's based on the real-world experience of the needs of the community
  • Con: it masks responsibilities and may lead to subteam creation being done later than it would have been useful
  • Anecdote: I wouldn't mind just getting all ecosystem notifications for now, as I'd expect the volume is manageable and I'm basically interested in everything going on
    (I don't mind either approach)
#

Should one maintainer be in more than 1/2/3/... teams?
I think team membership should be descriptive of a maintainer's work and not prescriptive, so limiting seems strange to me

should their voice count for each team that the RFC is labeled with?
That would be a bad idea IMO

Implicit to the two questions: should decisions be democratic? (The alternative I see is consensus) What's the quorum? Is the basis for "voting rights" maintaining a tool, formal team membership (requires being part of the GH org), or a vague sense of relevance to the question? E.g., could I "vote" on an RFC regarding doc syntax without maintaining an LSP or doc generator? If yes, because packages are affected and I maintain some, or because I'm an interested member of the community?

prime robin
#

I'm a bit "worried" that we're creating a taxonomy that's too granular. For example: if I make advances on my prequery preprocessor, do we create a new team "preprocessors"? I don't think it fits in the current teams. Or there could be multiple competing package templates, should there be a subteam for that? It doesn't really cost us so it's not really a problem though, just a mild concern.
Yes perhaps, I was wondering how granular this should be, perhaps just ecosystem is fine for now, but when review is requested we'd basically request review from all ecosystem team members (which can be quite large if we invite more people).

Implicit to the two questions: should decisions be democratic? (The alternative I see is consensus) What's the quorum? Is the basis for "voting rights" maintaining a tool, formal team membership (requires being part of the GH org), or a vague sense of relevance to the question? E.g., could I "vote" on an RFC regarding doc syntax without maintaining an LSP or doc generator? If yes, because packages are affected and I maintain some, or because I'm an interested member of the community?

I haven't actually gotten to that part of the process yet, i stopped drafting earlier mid process section. I would say anyone in the community can review, suggest changes and voice concerns that should be taken seriously, while the ecosystem team (or sub teams of relevance) would essentially triage before and after the FCP (final comment period).

#

When i get further in the draft I'll get back to this with more details.

daring nymph
prime robin
#

Sure i was thinking of the teams being an extension of this essentially

daring nymph
prime robin
#

It's not the tool we're labeling but the teams and those can be adjusted to be less granular if you think that's better

#

For example code assistance could include both lining and test runners and such instead of having them separate

crisp summit
#

the scope of RFCs - is it for things that impact the typst-community organization only, or is it also suggestions/rfcs/whatever for typst/typst itself?

daring nymph
prime robin
#

We'd add a few to get more input and see where it goes perhaps

prime robin
#

Things that aren't yet part of typst itself

#

But could be upstreamed once tried and tested

#

Doc comment syntax for example

daring nymph
prime robin
#

Agreed

#

Helps us test things out beforehand

crisp summit
# prime robin So far typst community tooling

ok. The team list you made now makes it seem like it's very typst-community focused and this draft text on the repo: "This is a repository for drafting, discussing and preparing community RFCs before proposing them on typst/typst as a whole." makes it sound like we're writing change requests for Typst as developed by the Gmbh itself 🙂

#

just laying out my confusion, it's going to be resolved I feel

prime robin
#

yes the wording on the process document is more explicit

#

i kept it short when i created it

prime robin
#

I've done some more work on the process document and the initial draft can be viewed on rfcs#3, There are still some unchanged parts, see the comments and PR description.

I've cleared up the scope of RFCs in the process doc and if those are proper enough I'd amend the README in that PR too.

#

Since it's not fully done yet I've left it as a draft, I'll request review once I've done proof reading, but this way you can alreayd look at where it is now.

prime robin
#

Ok I've revised a little more (mostly phrasing and typos) and it's in a reviewable statem I think.

One of the things mentioned in the Rust RFC process is that the FCP is widely advertised to alert potential unaware stakeholders. They use things like the "This week in Rust" newsletter. @elfin sparrow actually had a similar idea around a year ago with typst-community/newsletter but it's currently unmaintained. Perhaps we should look at this again and get this rolling as one possible avenue for alerting the community. Another obvious platform for this are the official community platforms, e.g. this discord and the discourse forum.

Then there's the point of who and how many people get the last say on an RFC to get it accepted. I think there are two cases:

  • If an RFC affects only community tools (or affects Typst only in the distant future) it should be voted on by the ecosystem team (or relevant sub teams).
  • If an RFC may be a precursor to a Typst feature in the near future (like doc syntax), then it should additionally require sign-off by Laurenz or Martin.

In both cases the scope of the vote would have to be decided and I think this depends on the size of the ecosystem team and whether we will have sub teams or not.

#

Once we have consensus on these points I'd also revise the README to reflect the changes and put the PR out of draft.

#

I guess the one thing that's still not clear is whether we want to use Typst itself for the RFCs right away, but the issue linked in the PR already goes over this, feel free to chime in on that issue in particular.

flat bane
#

I'm writing a few review comments, but this probably fits better here:

Removing language features widely used by community projects.
Is that supposed to create an "obligation" of the Typst team towards the community wrt changes? Or is that more about, if the community is interested in suggesting such changes? I'm not entirely clear on that

prime robin
#

I think it's more so in suggesting these changes, as noted further above in the doc the process itself is not authoritative and thus some changes (especially those by Typst itself) may not go through this process despite the possible impact.

#

That's fine though since Laurenz won't do that without actually asksing community maintainers, I think.

#

I can clear up the wording on that.

flat bane
#

I've just sent my review!

prime robin
#

Thank you!

crisp summit
#

for rowmantic/rowtable I finished a design for a relatively natural extension of its API. If we have rows, there could be a way to apply a transformation to each row.
My main question before merging it is actually about the name of the function. row is the most natural one, and having a short name would be good, but it's a bit bad to have such a simple name that can collide with existing identifiers.
Main options I was thinking of was using a slightly stranger but more unique name like rrow. Or just having it be the "best" name and let users rename it or use through namespace as needed.
https://github.com/typst-community/rowmantic/pull/12

Usage example in typst code: https://github.com/typst-community/rowmantic/blob/7de15caf045e3d7661d14fee2dd109df8054de30/docs/rowmantic-manual.typ#L294-L320
And yes, the function is optional, it's only used when you want to apply a transformation. And yes, I prefer reusable styles with show table.celland so on when possible, but this function provides a power that can and should probably be offered. 🙂 let me know if you have any advice/review/thoughts

daring nymph
#

if you don't have a short name, using a full name may be preferred, and there is no inconvenience when users have a language service for code completion. but that depends on you.

crisp summit
#

It's a lot about what I want the finished product (the typst code!) to look like, since the table input should be convenient and also allow nice alignment in the editor, ultimately look very readable as markup/code.

prime robin
daring nymph
#

in rust I very love to put identifiers in crate paths and make names with no more than two nouns. like instead of Info or PdfDocumentInfo I prefer pdf::DocumentInfo. for other crates frequently use pdf things, I can use pdf::*, for rest cases I can get auto import completed by the a bit unique name. searching on github is also helped a bit.

prime robin
#

Yeah perhaps scoping them to a module is not so bad? I think using conventional identifiers is OK if they aren't used in a prelude, if a user doesn't use a glob import they can explicitly rename it.

#

Rust actually has this in its API guidelines too IIRC, to use modules pdf::DocumentInfo over long descriptive names PdfDocumentInfo

#

Can't find it under the naming section maybe i dreamed that up

crisp summit
#

I'm not sure if Rust's logic for this is applicable. Every little ergonomic detail along the way matters; if you do #import "@preview/package:v": foo, bar then you kind of commit to importing loose names, having to go back to add as package is not necessary in Rust in the comparable scenario, so there it's easier to do both.

In typst to have both - some names loose and some through the namespace - we write out

#import "@preview/package:v" as package: foo, bar

or

#import "@preview/package:v"
#import package: foo, bar
#

I don't hate it, I'm just thinking about it and getting used to it

prime robin
#

Something I've seen used too is the python convention of using a short package identifier and I'm not 100% sure if i like it or not. For example valkyrie uses z because it heavily borrows from the JS zod library which apprently uses this convention.

#import "@preview/valkyrie:0.2.1" as z
#z.schema(...)
#

where it's so short that the prefix doesn't matter i suppose

#

I've honestly only used it with valkyrie itself because I tend to copy code around

crisp summit
#

I think python is gravitating towards this system with "official nickname" and I like it I think. Elembic launched itself with "e" as the official nickname. It's trying to have best of both worlds

prime robin
#

rm/rt 👀

crisp summit
#

It's good for certain kinds of packages and not for others, that's how I think of it in Python. To have a recommended short name.

prime robin
#

Probably only makes sense for those which have have lots of bindings

#

and are used a lot in context where other bindings might conflict

prime robin
#

I'm a little confused about the last comment @flat bane
I've left a reply on it

#

In particular how "implementation" as a phrase is ambiguous, but somehow about the responsibility of the implementation?

flat bane
prime robin
#

yeah to the secon part made it click

#

I suppose we could add a mandatory step for the author or an ecosyste team member to add the guide level docs to some documentation

#

perhaps similar to that of the rust rfc book or a more curated rust book

#

I'll add it to the comment for posterrity

flat bane
#

In reality, that will become relevant only when we get the first RFC of that kind. We could say, as part of the implementation, the final design needs to be documented somewhere appropriate. And like any other implementation step, an RFC doesn't force anyone to do that; we just count on the previously generated buy-in to make it happen.

And when we get close to accepting a guideline RFC, we simply have to also accept a where-to-publish-guidelines RFC 😛

prime robin
#

😆

ornate condorBOT
tough crown
#

I wouldn't recommend single letters for package abbreviations because there are only 26 of them and i, j, x, y, z, a are already out due to them being commonly used as running variables.

Two-letter combinations can make sense for really common packages but even here, there are only 676 combinations (in theory, in practice there are much less for several reasons). With three letters we can start talking (in my opinion).

tough crown
crisp summit
#

I tend to agree. But cuteness in package names is mandatory in Typst and then they often get to be long names. So I don't want to retype the long name.
About the short names, it's kind of a good compromise for a reason - there is a recommendation - let's say e for elembic but any individual user can choose what's right for their project or even that particular file. The compromise is that there is a long package name, and an optional recommended short name

runic moat
#

yeah, having short (2, 3 letters) standard abbreviations is nice for examples and copying snippets

#

it's like import pandas as pd or import numpy as np in the python world

prime robin
#

re RFC process:

I've Updated the RFC and made it ready for review, as noted on the comment, I'd like to get a few members into the ecosystem team so that, if the current process is accepted and merged, the ecosystem team can properly represent the community on the final vote towards an RFC.

#

Do you guys have suggestions who we should get on the team? I think we definitely should get Enter-tainer on for example. A few more package authors should also be added, probably from the featured packages.

#

But we also don't want to bloat the team of course, I think about 9 members sounds like a good amount, this would require a 6-3 majority for an RFC to pass if the process is merged as is.

ornate condorBOT
prime robin
oblique star
#

Crap. I want to change the default branch of utpm to put it back to main. It's dev but I can't change it :((

dense vale
oblique star
#

Thx I can now!

ornate condorBOT
prime robin
ornate condorBOT
ornate condorBOT
tough crown
prime robin
#

I may or may not

#

Watch the late night upset by a prominent member of a non-english speaking community

tough crown
#

?

#

I don't get the reference

oblique star
#

Same I don't get it 😭

#

Btw I'm remaking contributions to utpm

prime robin
#

It's ok, if I explain it it won't be funny

oblique star
#

So far I've made JSON, yml, toml and hjson supports and integrate anyhow and thiserror in it

#

And I need advice on using octocrab and libgit2rs simultaneously, it seems overkill for one command (and a bit too complex)

prime robin
#

why so many formats?

prime robin
#

jujutsu actually does for communicating with remotes

oblique star
flat bane
#

I've made an issue in the template but didn't get around actually evaluating utpm or typship yet; it would be great if you could take a look and see if you think utpm will/could cover these things? 🙂
https://github.com/typst-community/typst-package-template/issues/36

GitHub
Replace bash scripts by a tool for Typst package management such as...

The Justfile and CI actions of the template are currently powered by a few scripts in this package, located in scripts/. This duplicates code between all packages using this template, and makes usi...

oblique star
#
  • location is already in utpm
  • I'm already reading typst.toml but I don't see your use case (or I just don't understand 😔)
  • .typstignore already supported
  • installing package files are already built, checkout install command
  • uninstalling is under unlink
  • publish isn't finished as I'm having trouble with the complexity of using octocrab and libgit2rs but it has a great start
  • logic and command parsing are built-in with clap crates (and I have a PR about error handling)
#

sorry for my poor choice of words, I'm having a hard time reading, writing and not dying in the bus

flat bane
# oblique star - location is already in utpm - I'm already reading typst.toml but I don't see y...

I'm already reading typst.toml but I don't see your use case
basically I'd want a command like utpm meta version that returns a field from the toml or utpm format '{name}-{version}.zip' so that you can e.g. construct file names to be used in scripts (although I guess that could also be achieved with general purpose toml tools)

installing package files are already built
(in general) Is there more command documentation than the README/the CLI help? "Install dependencies listed in typst.toml." the typst.toml doesn't list dependencies, or do I misunderstand?
What I mean here is to copy files in a local package repo to the install location, so more similar to link I guess, but with purposefully not putting excluded files into that package so that you can test for accidental dependencies on excluded files

oblique star
# flat bane > I'm already reading typst.toml but I don't see your use case basically I'd wan...

For the first part, I've an issue for that (more or less), but yeah that's a good idea!

No unfortunately, I don't have more docs than this, I want to add more but I'm not motivated at all but I've listed that as an issue.
And I add under an attribute a list of URLs that would be installed when using the command.
And if I'm not wrong, what you describe resembles a lot on the clone command that can clone a package from any repo into your own dit.

ornate condorBOT
#
tingerrr
[org] Discussion #18 marked answered: Call for Nominations: Second Administrator

I would like to self-nominate and I hope this message serve as inspiration for others to do so too.

Here's why I think I'd be a good fit:

  • I'm fairly active in the community, mostly on the official discord, but also on some Typst issues.
  • I maintain or help maintain tools and packages such as hydra (primary maintainer), subpar (primary maintainer), tytanic (primary maintainer), and valkyrie (secondary maintainer).
  • I have moderated and still moderate some small-to-medium-size...
dense vale
#

congratulations @prime robin 🎉

I’ve updated your GitHub role to Owner. Do send me your email privately I’ll setup a cloudflare for the domain for DNS stuff if you’d like

prime robin
#

Woo yeah! Thanks, I'll do that later today.

dense vale
#

is there a way to close a discussion thread on forums? https://forum.typst.app/t/typst-community-call-for-nominations-second-administrator/4630

if not it’s ok the reply should be enough

Typst Forum
(typst-community) Call for Nominations: Second Administrator

📌 Please note that we are unaffiliated with the official Typst team, this is a separate organization. 👋 Hey everyone, The Typst Community organization has been around for two years now (since 2023!), working to support and grow Typst-related projects. Since the community’s grown a lot, we think it’s a good time to add another organi...

prime robin
#

Wait, which kind of DNS things are we walking about?

prime robin
dense vale
#

I’ll check later on a larger screen, can’t seem to figure it out on mobile

dense vale
prime robin
#

Sure, I assume you'd need my cloudflare email then?

dense vale
flat bane
oblique star
elfin sparrow
#

I demand a recount

oblique star
#

america be like:

prime robin
# dense vale yes that would work

I've sent you a friend request, I think sending an email form that alias would look like spam and hardly be verifyable for you so sending it here makes more sense I think.

oblique star
#

Does the community have an email? I'm fixing some issues regarding authors etc

prime robin
#

It does

#

It's linked on the main org site I think

oblique star
#

Mb it is (I'm not sure since the last commit came from more than one month), but I think it could be a great idea to transfer it

prime robin
#

As a heads up: I deleted the ecosystem/jannies team, it was empty and the name is a little silly too.

prime robin
#

Though, I wonder if we really need to absorb every community repository we come across.

#

I would like to put bump the ecosystem team discussion again, i.e. whether we should have sub teams, who we think should be added (regardless of sub team or not) and how many people we want per team (or in ecosystem itself if no sub teams)

context starts here: #1194684809906237500 message

#

From the current state of the RFC process document PR we're looking at a single team, ecosystem to which I'd like to add a few people not yet in the org to properly represent the community. Ideally we'd do this with a public vote similar to the admin nomination.

#

But I'd propose that we allow non-self nominations this time, where nominees can simply turn down the nomination.

ornate condorBOT
oblique star
#

sorry i'm having trouble with that

#

fc****workflow being trigger for no reason????

oblique star
prime robin
#

Yeah I figured

flat bane
# prime robin I would like to put bump the ecosystem team discussion again, i.e. whether we sh...

I'm more in the "add subteams as necessary" camp as stated in the discussion.

Regarding more people, these came to my mind:

  • @tropic field (typship)
  • @silk crypt aka Enter-tainer (typstyle)
  • @silver aspen aka overflowcat (astro-typst)
  • @solid umbra (elembic)
  • johannes-wolf or @dreamy kite (cetz)

these are all maintainers of packages or tools that have or could have broader impact on things that might be worth standardizing in the Typst ecosystem.

(for the people being silently pinged: that's the context here; finding people who are interested in discussing and ultimately deciding about standards, guidelines, etc. that would be recommended for the Typst ecosystem to adopt, to promote interoperability and a uniform user experience. more info is in the yet-to-be-adopted RFC process. tinger, I hope I didn't butcher it :P)

prime robin
#

Put it perfectly ❤️

oblique star
prime robin
#

You can do so by putting @silent at the start of the message

ornate condorBOT
flat bane
#

oh yeah totally overlooked you of course, @oblique star. Switching between different lists gets confusing 😅

oblique star
solid umbra
#

😎

#

but i mean, if this is about like , setting standards for usage of packages, i think thats a cool idea, though at least for elembic i guess we shouldnt go that deep into it since the idea is to have that stuff built-in eventually
still, it might be good to already experiment with cross-package compatibility and that sort of stuff
though elembic itself already goes to great lengths to ensure packages are cross-compatible

prime robin
#

What to standardize is to be decided, for now we want to find a good team size at which final decisions on RFCs can be done

oblique star
oblique star
#

Btw regarding of the RFC process, i've posted that
tldr: it's easy to use typst when it's files based or we could reserve a part of typst.community to manage rfc process with typst.ts as the renderer

#

I'll add that if someone uses the webapp we could just download the file and put it in the github directly

#

I don't see any real convenient since we are quite small for now, we could just stick to github and typst files.

prime robin
#

I think it's fine to use typst locally and worry about rendering only for some sort of website or book that shows the RFCs

prime robin
#

I think that's a fine amount we could potentially add one more I'd like to cap it at below 10 and an odd number for any sort of tie situation

#

So if you guys think someone should be added you could propose that here

#

Well also have to check if all of them have the time and are willing to actually participate. I think discussing RFCs and voting on them is not as easy as it seems, at least it's more time consuming than one might think.

#

Though for the start it'll likely be fine, there won't be many concurrent RFCs

oblique star
oblique star
prime robin
prime robin
oblique star
#

I'm all in then 🙏

honest girder
#

It would be my pleasure but don't feel obligated 🙂

prime robin
#

Sounds like a good 9th then, at this point I wonder if we should do a nomination process or just choose people and contact them if they want to do it

#

i.e. how much of this should be driven by community input?

oblique star
prime robin
#

I think since these people have an impact on the wider community they should atthe very least be approved by the community

oblique star
#

But I don't think that will happen

prime robin
#

But I think the participation may be sort low again

oblique star
prime robin
#

Last time we used an org discussion and a forum post for visibility

#

I'll first contact everyone though since we sort of pre-nominate a few people we should make sure they're all on board first

solid umbra
oblique star
oblique star
#

Do you think we can create a sort of RFC for a registry? I've already proposed that but I want to propose this as a real idea more than just a random message here

thick talon
#

Do you mean a package registry for Typst packages? Or something else?

prime robin
prime robin
thick talon
#

Then, yes I think it needs to be discussed more broadly. However, if you want to share what your needs would be from the open-source community standpoint, it would be very useful. I don't think it is a priority for the Typst team, we have already talked about it a few times, but there is no urgent need to move forward for now. But we can keep your needs and proposals in mind when we decide to work on it in the future.

prime robin
#

We could discuss it here beforehand to weigh the benefits and drawbacks of certain implementations and then present the findings, but since it has hardly any use for community tools alone i would keep it out of the community RFC repo itself. If typst itself had an RFC repo it, then that would be the right place, I believe.

oblique star
oblique star
oblique star
#

But yeah for now, we could just discuss it in the RFC community

prime robin
#

In the future, I think right now it wouldn't merit the administrative overhead

oblique star
#

Exactly

prime robin
#

Since laurenz already has lots to do on his own

oblique star
#

That's why I propose that, let him have a bit of vacation

#

And the typst team itself

prime robin
#

I think he'll do that himself 😆

oblique star
#

Yes indeed 😭😭

#

But like we don't need to put more work on him

oblique star
tropic field
#

sry😭

tropic field
flat bane
#

I think working together makes sense, but even then it could be that you're aiming to support different usecases/envision different CLI structures, if that's the case, maybe a common crate similar to typst-kit could make sense. (just putting ideas out here, merging the tools is of course also an option)

prime robin
#

I'd love to have such a crate too to factor out stuff like discovering projects and metadata about packages

#

But I feel like that would first need a common agreed upon project structure in some way

tropic field
#

Yep, as discussed before, an RFC would be great

#

iirc there’s a draft PR about this by camiyoru

prime robin
#

On typship?

tropic field
daring nymph
#

i proposed a cp for typst packages

#

like scp

#

cp command

prime robin
#

Ah, I see

#

Does this come with anything that isn't yet part of the manifest? If not then there's nothing we'd need standardized

#

And it can just be done as is without much trouble

ornate condorBOT
#
tingerrr
[org] New discussion #19: Ecosystem Team Pre-Nominations

Preamble

The ecosystem team is a team on the @typst-community organization with triage and contributor access to some repositories, but most notably, with the final vote on whether an open RFC in this repo is accepted or not (as of the current RFC process draft).

The current ecosystem team was created without a formal process, i.e. the members were not voted on in an open process. To ensure that the ecosystem team can meaningfully repre...

prime robin
#

Ah , I don't need to link it.

#

I'd like to point you all at that discussion regarding the pre-nominees of the ecosystem team. Especially the pre-nominees themselves.

oblique star
#

I don't know if that is important but I've made truthfy and esotefy too

#

Esotefy is more a troll than anything and a showcase that we can make anything with typst

flat bane
oblique star
flat bane
oblique star
prime robin
#

I just included some notable things there, I wasn't thinking too hard about what to include, some people just had them in their account readme like with myriad and entertainer

#

But they also work like 10 people at once so they're bound to have more stuff there

oblique star
#

It's already good dw 😭😭
It was just curiosity if that can help people to trust me a little more

prime robin
#

I'll add the links there later

oblique star
#

thx!

solid umbra
#

im so unoriginal with theorems and thesis templates

#

surely theres something better

#

😂

flat bane
prime robin
#

i wonder if elembic would be a good fit for subpar

#

subpar is a mess of show rules within show rules

tacit nymph
#

i mean ideally we could get native subfigures but that might actually also be an interesting design decision that native elements could enable native subfigures much more easily

#

as in defining subfigures in a typst standard library kind of way

#

idk i mean the hardest part is the counters tbh, since essentially it is just a grid of figures at its core

prime robin
#

Yes the counters are the bane of my existence

tacit nymph
#

understandable

solid umbra
#

interesting

#

well, elembic has some support for custom counters

#

by default all elements have custom counters with e.counter(elem) but it just increases by 1 forever

#

but you can customize that , e.g. based on fields
though thats not very innovative by itself, you can also just manage your own counter

#

still, i suppose it cant help much with integrating with native figures using show rules

#

one idea is that you could have a larger normal figure wrapping the two subfigures, which themselves would be custom elements

#

since elembic supports custom references, you wouldnt be losing that much

elfin sparrow
#

The nerd snipe is intense

prime robin
#

I've opened rfcs#4 to list out some topics that have been discussed for possible standardization before.

#

feel free to add your own ideas

oblique star
#

Already done, I've proposed the a registry and a proper package manager

prime robin
#

I don't think the registry is in our hands

#

this must be added to typst and as such designed and discussed there

#

For example if typst doens't support a custom registry to be specified, then it makes absolutely no sense to add it to tytanic or tinymist

#

As for the package manager, the spec and standardization is already there through what typst supports at the moment.

#

What could be standardized is extra fields in the manifest that are non standard and features like .typstignore.

flat bane
#

I think there's place to standardize stuff around custom registries. Even if the compiler can't download them on-demand, utpm and typship can download private packages ahead of time, and as a package author (or package distributor, in that case?) I'm interested in being compatible with these tools. as a tool author, I'm interested in allowing private package installation with minimal friction -- not just individual packages, but whole suites of packages, i.e. registries.

For example, right now I have a "registry" repository that I can clone directly into .local/share/typst/<private-namespace>, and CI to publish into that registry repo. But it requires my users (thankfully there's only one other than me :P) to use git directly, which is not ideal.

I'm not sure what would be standardized in the end, but there is stuff there.

prime robin
#

Ok, sure I see the merit in that, though what Thumus proposed was mainly to move away from a git based approach, a proper registry. ANd I don't think that is something we can do ahead of typst itself.

#

We could add some form of quasi-registry topic for making git installations easier

flat bane
#

ah. yes, moving the official registry is not something we can do. My mind didn't even go there 😛

prime robin
#

I think doing design work for this is ok, it just won't be helpful to do here instead of on typst directly

daring nymph
prime robin
#

I'm not sure what you mean, as in an RFC is proposed and half finished and we merge it before its finished?

#

that wouldn't be inline with the current process document

elfin sparrow
#

Maybe a drafts folder to keep them in?

oblique star
oblique star
prime robin
solid umbra
#

someone opened an elembic PR about the default template example in the docs and i think they're proposing an interesting discussion

#

would be nice to get some input 🙂

prime robin
#

I'll take a look when I'm home

solid umbra
#

no rush 👍

ornate condorBOT
keen gorge
prime robin
#

I've left a comment :)

ornate condorBOT
clever sphinx
#

The bottom should be table 2.2

CleanShot_2025-07-26_at_18.07.482x.png
prime robin
#

I have no idea all i have here is an image and hardly any context

tacit nymph
# clever sphinx The bottom should be table 2.2

subpar doesnt do heading-specific counters, that is something you will have to add yourself. as for it saying table, you can pass kind: table to the subpar.grid function (though idk why 3 neighboring diagrams would constitute a table

clever sphinx
#

how would I implement heading specific counters? numbering: 1.1 doesn't work ofc.

prime robin
#

#quick-questions

#

doc looks nice thought btw

clever sphinx
prime robin
#

nice

clever sphinx
prime robin
#

snazzy

prime robin
#

does anyone know if thee is any difference between outside contriutors and members in an org from a permission perspective?

#

we have three outside contributors, some of which are actually also members

#

seems github keeps it that way after someone joins the org but was added to a repo beforehand

flat bane
#

outside contributors can not be added to teams. A huge annoyance imo...