Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allowing for a display name parameter in typst.toml for cleaner package listings in Typst Universe #586

Open
Spelkington opened this issue Apr 22, 2024 · 1 comment

Comments

@Spelkington
Copy link
Sponsor Contributor

Spelkington commented Apr 22, 2024

Premise

Howdy, all!

While putting together the guided-resume-starter-cgc package, I tinkered around with the current name parameter in the TOML and discovered it must match the subdirectory for the package in @preview

The target audience for this package is less-technical folks — particularly university undergraduates who aren't necessarily Computer Science-oriented — and I anticipate that the vast majority of this audience will be going through the Typst Universe portal to initialize a new instance of this (or another) template.

With this audience in mind, I tried to use the name parameter as a "clean" name of the package, since guided-resume-starter-cgc is a bit verbose in the interest of avoiding collisions or using a "canonical" name. My hope was to use a more generic name when displaying the package to end users, such as "Resume Starter Guide" or something similar.

However, it appears that the name category is more akin to a package slug, and used to validate the package against its parent directory within @preview.

Recommendation

I understand the behavior of name as a validation check, but I do think it would be nice to have something akin to a display-name parameter (or something semantically equivalent) to declare a cleaner name. This parameter could then be used in GUI frontends for display purposes, such as in the packages listing of the Typst Universe portal.

While this may seem like a small detail, I've noticed that seemingly small things like kebab-case labels can be intimidating to a less-technical audience and may function as a barrier to Typst adoption. The kinder syntax of Typst versus my previous LaTeX template has been amazing, and I feel that accompanying this with a softer GUI label for packages would help encourage Typst adoption among this audience.

While this may not a usual practice among package managers (npm, brew, etc.), I feel that Typst's choice to encourage template creation via Universe makes this an appropriate addition to the package metadata schema.

Example

In the charged-ieee typst.toml, the current display name in Typst Universe is charged-ieee, matching the name parameter:

[package]
name = "charged-ieee"
version = "0.1.0"
compiler = "0.10.0"
entrypoint = "lib.typ"
...

My recommendation would be some additional parameter representing a clean name to be used in Typst Universe (or other GUIs):

[package]
name = "charged-ieee"
+ display-name = "Charged IEEE Template"
version = "0.1.0"
compiler = "0.10.0"
entrypoint = "lib.typ"
...

This label could then be used for the template's Typst Universe entry:

image

Caveats

In this case, the addition of a display-name parameter would ensure backwards compatibility. Current implementations of GUIs would continue to reference the slug contained at name, while updated GUIs could reference the display-name parameter for packages if they choose.

@Spelkington Spelkington changed the title Allowing for a clean-name parameter in typst.toml for less intimidating views on Typst Universe portal Allowing for a display name parameter in typst.toml to allow cleaner package listings in Typst Universe Apr 22, 2024
@Spelkington Spelkington changed the title Allowing for a display name parameter in typst.toml to allow cleaner package listings in Typst Universe Allowing for a display name parameter in typst.toml for cleaner package listings in Typst Universe Apr 22, 2024
@Spelkington
Copy link
Sponsor Contributor Author

Just an addendum - I understand the actual implementation of this would be a pretty small change to the schema file. I'm willing to make a PR for it, but wanted to prompt a discussion first before learning how to run & test Rust.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant