fontsource
feat(font): add fusion pixel
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
fusion-pixel-8px-monospaced
fusion-pixel-8px-proportional
fusion-pixel-10px-monospaced
fusion-pixel-10px-proportional
fusion-pixel-12px-monospaced
fusion-pixel-12px-proportional
They are added using a script. I didn't include it here; check this branch. You need to run it using Bun.
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.)
My original plan was to create a font name for each locale, but that would result in 6 * 5 = 30 packages.
To my understanding, that is exactly what Google Fonts does.
- Noto Sans TC/Noto Sans SC/Noto Sans KR etc.
- IBM Plex Sans JP/IBM Plex Sans KR
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 4 * 6 = 24 packages as one way.
Since the glyphs for Latin and symbols differ between mono and proportional fonts, and 8/10/12px sizes can indeed be considered as separate fonts, I don't think there's a way to further reduce the count. I will modify my build script to generate 24 packages.
Before that, I'd like to confirm that fontsource should be using fontface to import our fonts, so the family name I specified in the metadata is irrelevant to the font files (woff and woff2, if they have built-in family names). Is it correct?
You need to give each package metadata a different family name, as it will then generate a different @font-face name which will take precedence over any built-in family names.
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.
The test likely failed due to the absence of -latin- in the font files, for which I will make adjustments later.
Google uses JP, KR, TC, SC for the shortened names
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.