Support japanese subset for next/font/google

[setouchi-h]

Goals

1. Allow using subsets: ['japanese'] with next/font/google (e.g. Zen_Kaku_Gothic_New) without TypeScript errors.
2. Clarify the intended behavior and performance guidelines for CJK subsets in next/font/google.
3. Get maintainers’ feedback on an acceptable approach and whether a PR would be welcome.

Non-Goals

No response

Background

When using Zen_Kaku_Gothic_New from next/font/google, the japanese subset is not included in the generated TypeScript definitions.

In this repo, scripts/update-google-fonts.js builds packages/font/src/google/index.ts and font-data.json. The script filters out several subsets via an ignoredSubsets array, including 'japanese', 'korean', and the Chinese subsets. As a result, the generated metadata for “Zen Kaku Gothic New” only includes ['cyrillic', 'latin', 'latin-ext'], and the subsets option in the Zen_Kaku_Gothic_New type does not allow 'japanese'.

At runtime, next/font/google still loads the font correctly from Google Fonts (the CSS response includes Japanese glyphs), so Japanese text renders fine. However, TypeScript reports an error, and if we try to use preload together with 'japanese', the validation code treats it as an unknown subset.

For Japanese users, this means we either have to suppress type errors (e.g. with @ts-ignore) or avoid using the subset/preload options, even though the font actually works in practice.

Proposal

I would like to understand the intended policy for CJK subsets in next/font/google, and whether enabling japanese (and potentially other CJK subsets) in the metadata is something that could be supported.

My initial thought is:

• Stop filtering out 'japanese' (and possibly other CJK subsets) from the generated metadata so that subsets: ['japanese'] is allowed at the type level.
• To avoid unexpected large downloads, consider keeping preload: false as the default for these CJK fonts, and document that preloading CJK subsets can significantly increase bundle size and initial load time.

I’m happy to open a PR implementing whatever approach maintainers prefer (for example, enabling only 'japanese' first, or adding an explicit opt‑in for CJK subsets). I’d appreciate guidance on the direction you’d consider acceptable before starting implementation.