feat: use variable fonts with subsetting #2817
No reviewers
Labels
No Label
area/internal-code
changes requested
confirmed
dependencies
duplicate
good first issue
help wanted
hosting
invalid
kind/bug
kind/feature
question
wontfix
No Milestone
No project
No Assignees
3 Participants
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: vikunja/frontend#2817
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "dpschen/frontend:feature/variable-fonts-with-subsetting"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Allthough individual filesize of the variable fonts is larger, the total loaded filesize should be smaller than before.
Hi dpschen!
Thank you for creating a PR!
I've deployed the changes of this PR on a preview environment under this URL: https://2817-feature-variable-fonts-with-subs--vikunja-frontend-preview.netlify.app
You can use this url to view the changes live and test them out.
You will need to manually connect this to an api running somehwere. The easiest to use is https://try.vikunja.io/.
Have a nice day!
@ -435,7 +435,7 @@ $vikunja-nav-selected-width: 0.4rem;
.menu-list {
li {
font-weight: 500;
It seems like our 500 file was actually a semi-bold, meaning 600.
When I changed to the variable font everything was a bit to thin.
Also the exported 500. That's the reason for this change.
One disadvantage of this: if there is no variable font loaded the browser might round this up to bold for the fallback font. Since we preload the font the probability should be very small that this happens.
@ -480,2 +480,4 @@
color: var(--grey-500);
margin-right: .5rem;
// align brackets with number
font-feature-settings: "case";
This aligns the brackets with the number.
@ -98,5 +98,6 @@ function setSubscriptionInStore(sub: ISubscription) {
<style scoped lang="scss">
.dropdown-trigger {
padding: 0.5rem;
display: flex;
Aligns the three dots with the rest of the line
@ -39,3 +39,3 @@
{{ pt.title }}<template v-if="(i + 1) < task.relatedTasks.parenttask.length">, </template>
</template>
>
›
More fitting sign for the parent child relation indicator
@ -72,3 +72,3 @@
:aria-expanded="showDefer ? 'true' : 'false'"
>
- {{ $t('task.detail.due', {at: formatDateSince(task.dueDate)}) }}
– {{ $t('task.detail.due', {at: formatDateSince(task.dueDate)}) }}
Longer sign.
@ -10,13 +10,14 @@
// are defined here.
//
$family-sans-serif: 'Open Sans', Helvetica, Arial, sans-serif;
This was the actual issue why Open Sans wasn't used.
Because the variable was defined after the bulma import?
yes. by setting the variable before the variables in bulma dont fall back to their default
@ -1,65 +1,105 @@
$font-files-path: '/fonts/';
$font-files-path: '@/assets/fonts/';
By not using the public folder for the font files, a hash gets added to the final font file.
This should simplify caching, since we could cache forever.
This additional hash is needed in case we change something inside the
instance_and_subset
function that has nothing to do with the input arguments (original font file / parameters).@ -12,0 +3,4 @@
// this is the same as the latin range that google uses.
// see for examle the unicode-range definition here:
// https://fonts.googleapis.com/css2?family=Open+Sans
$unicode-range: "U+0000-00FF,U+0131,U+0152-0153,U+02BB-02BC,\
The current unicode range only supports (what google defines as) 'latin'. We could extend that in the future and create more additional subsets.
@ -21,0 +11,4 @@
@font-face {
font-family: 'Quicksand';
src: url($font-files-path + 'Quicksand[wght]_87bdcc7f.woff2') format('woff2-variations');
src: url($font-files-path + 'Quicksand[wght]_87bdcc7f.woff2') format('woff2') tech('variations');
This is the upcoming syntax. Recommended to use both currently
@ -21,0 +15,4 @@
font-style: normal;
font-weight: 400 700;
font-display: swap;
unicode-range: $unicode-range;
If I remember correctly the font files before were already subsetted. So this unicode-range definition basically just tells what's written in the file. It gets useful in the moment that we add multiple ranges.
@ -30,0 +21,4 @@
@font-face {
font-family: 'Open Sans';
src: url($font-files-path + 'OpenSans[wght]_54a65da5.woff2') format('woff2-variations');
src: url($font-files-path + 'OpenSans[wght]_54a65da5.woff2') format('woff2') tech('variations');
Every time we update the font we need to change the file name here. I don't have a better solution for this as of now. For sure I could have created this file via a script, but that seemed more complex than simply updating the hash. It doesn't happen that often that a new font version is released. But it's good that in that case we are prepared.
Looks fancy!
Not sure if I understood everything so here's my recap:
-> Is it backwards compatible?
Is that correct?
the smaller font size is a neat side effect. yes. variable fonts allow us also to do stuff like animating the font weight.
yes. we also still create static fallbacks. see the fonts.scss. must browsers should support it by now though.
I places the original font files inside the repo. by original I mean in this case: the variable font without any change. I decided to do this as a backup in case the download isn't possible in the future out of whatever reasons. It's really just a precaution.
The instantiation (dropping of axis and / or their range) and subsetting happens on top of the downloaded font.
Does it work for you?
In theory it shouldn't change the font files since the hash should stay the same.
I tried to use as few dependencies as possible. Do you think a script in this form makes sense? Or should it run e.g. in a docker file.
That's a good idea. Also we'll avoid network traffic to external sources every time this is built in CI.
yes!
I think this is fine, but the dependencies like python etc should be documented (or added to the nix flake)
I don’t see this as something that would run in the CI. More as sonneting you would run manually from time to time.
Considering the above: should it still be included? Send if so can you help me with that?
If a Dockerfile makes it easier, yes please add one.
It would make it more complex.
Then it's fine to not include one. But please document what dependencies the script has (can be a comment in the header of the shell script).
159e064851
to1da52d5bc1
I guess the only real dependency is python 3. The required packages are installed here
I added instructions here.
The rest should be installed on most distributions (maybe not alpine, but 0815 ubuntu should work I guess).
Is that enough for you or were you expecting more?
PS: Next time I'll write it in python from the start.
🥳