You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When 3.0.x was released, there were breaking changes that changed how we imported fonts, from fontsource-<package>/<subset>-<weight>-<style>.css to fontsource-<package>/<weight>-<style>.css since it was no longer necessary to specify subsets with the new unicode-range feature.
Unfortunately, the non-Google fonts that were manually added did not follow through with the update and still follows the old subset import method, primarily because they do not have any unicode-range data for us to use.
This has led to confusion from the lack of consistency to cause situations such as #91.
Solution
To resolve this, all these fonts should be repackaged with the default subset used when there isn't any subset specified in the import, irrespective of whether it has unicode-range data or not. That will need changes made to the generic packager and rebuild scripts.
The text was updated successfully, but these errors were encountered:
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.
Use the 'not stale' label to prevent the issue from automatically closing.
Problem
When 3.0.x was released, there were breaking changes that changed how we imported fonts, from
fontsource-<package>/<subset>-<weight>-<style>.css
tofontsource-<package>/<weight>-<style>.css
since it was no longer necessary to specify subsets with the new unicode-range feature.Unfortunately, the non-Google fonts that were manually added did not follow through with the update and still follows the old subset import method, primarily because they do not have any unicode-range data for us to use.
This has led to confusion from the lack of consistency to cause situations such as #91.
Solution
To resolve this, all these fonts should be repackaged with the default subset used when there isn't any subset specified in the import, irrespective of whether it has unicode-range data or not. That will need changes made to the generic packager and rebuild scripts.
The text was updated successfully, but these errors were encountered: