-
-
Notifications
You must be signed in to change notification settings - Fork 39
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
feat(font): add fusion pixel #76
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your submission! Unfortunately, we do not support subsetting (#730) with the custom packager. For now, that's only supported for Google Fonts.
Would it be possible to have a one large file instead? I understand it would be extremely bloated, being a CJK font, but that's the only way we can really support this through our custom packager at the moment. Another way is getting this font approved by Google Fonts which will be the most usable format.
In fact, the subsets here are not actually subsetting. Each individual subset contains the entire font (e.g., the other four contain Latin). For CJK, due to Han unification in Unicode, many characters that look slightly different in different locales are assigned to a single Unicode code point. Therefore, we cannot combine fonts from different locales. So the question is actually if users have the option to manually specify the subsets they wish to utilize. My original plan was to create a font name for each locale, but that would result in 6 * 5 = 30 packages. (Nevertheless, there is no need to worry about size - this is a pixel font, much smaller than typical CJK fonts.) |
To my understanding, that is exactly what Google Fonts does.
And more. I'm not against adding a large number of packages. Google doesn't seem to be either looking at the newest fonts added to Fontsource: But I wonder if all 30 packages are necessary? If you have any ideas to reduce that, that will be great to hear about. But if they are all uniquely different, I think it is okay to introduce these packages separately. |
We could also remove the individual latin subset entirely, and only ship |
You need to give each package metadata a different family name, as it will then generate a different There are times we regenerate the CSS in this repository using only the metadata, thus the metadata has to be accurate. Any custom edits to the CSS would be removed in such cases. |
(24 variants in total)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now ready for review :-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the delay! I was on holiday. Thank you for making the changes.
The changes look functionally fine but I think we should remain consistent with Google for the naming. e.g. instead of Fusion Pixel 10px Monospaced ja
, it should be Fusion Pixel 10px Monospaced JP
or instead of Fusion Pixel 10px Monospaced ko
, it should be Fusion Pixel 10px Monospaced KR
. This would be much less confusing for end users.
You can check on the Fontsource website, but Google uses JP, KR, TC, SC for the shortened names.
The test likely failed due to the absence of
The naming follows the font file's family name, which I checked using FontForge. If changing the names does not cause any issues, then I will proceed with that. Btw Fusion Kai in the repository (not by the same author) uses G / T / J, following font author's naming. Fusion Pixel doesn't explicitly call their variants "Fusion Pixel zh-hant", "Fusion Pixel ja", etc. in their website so I think renaming is fine (?) |
I think we should change the names for consistency. We're already modifying the fonts by subsetting it separately like this, so it should be fine. |
Fusion Pixel Font is an open-source sans-serif pixel font designed to support Chinese, Japanese, and Korean (CJK) characters. It offers clear and sharp readability at 8, 10, and 12-pixel sizes.
The font has 3 pixel sizes, 2 styles (monospace and proportional), and 5 locales, resulting in a total of 30 combinations. Although I have added the locales using subsets, I am not entirely certain if they are functioning correctly (e.g., whether the family names are correctly assigned), as font files are renamed from different, separate locale-specific files.
Fonts added
They are added using a script. I didn't include it here; check this branch. You need to run it using Bun.