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

feat(font): add fusion pixel #76

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

OverflowCat
Copy link

@OverflowCat OverflowCat commented Jun 30, 2024

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.

Copy link
Member

@ayuhito ayuhito left a 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.

@OverflowCat
Copy link
Author

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.)

@ayuhito
Copy link
Member

ayuhito commented Jul 3, 2024

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:

image

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.

@ayuhito
Copy link
Member

ayuhito commented Jul 3, 2024

We could also remove the individual latin subset entirely, and only ship 4 * 6 = 24 packages as one way.

@OverflowCat
Copy link
Author

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.

8px 10px 12px

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?

@ayuhito
Copy link
Member

ayuhito commented Jul 3, 2024

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.

(24 variants in total)
Copy link
Author

@OverflowCat OverflowCat left a 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 :-)

Copy link
Member

@ayuhito ayuhito left a 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.

@OverflowCat
Copy link
Author

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 (?)

@ayuhito
Copy link
Member

ayuhito commented Jul 25, 2024

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.

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

Successfully merging this pull request may close these issues.

2 participants