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

Support multi-language fonts #45

Open
3 tasks
yous opened this issue Jul 16, 2014 · 9 comments
Open
3 tasks

Support multi-language fonts #45

yous opened this issue Jul 16, 2014 · 9 comments

Comments

@yous
Copy link
Contributor

yous commented Jul 16, 2014

Whitespace supports Korean fonts by #28, but doesn't support Chinese or Japanese characters. Also because of the size issue, we can't ship web fonts for those languages.

  1. Fallback fonts for Windows, Mac and Linux.
  2. Cross-platform default fonts.

Also added fonts should not affect other language fonts.

  • Simplified Chinese fonts
  • Traditional Chinese fonts
  • Japanese fonts

Seeing List of CJK fonts, we can use Microsoft YaHei, Microsoft JhengHei, Meiryo for simplified Chinese, traditional Chinese, Japanese respectively. They are distributed with Windows Vista. Also, we should find more fonts for older Windows.

Adobe, in partnership with Google, announced Source Han Sans. We can consider this as default font for CJK.

Also mention me another languages that can be added.

@yous
Copy link
Contributor Author

yous commented Jul 16, 2014

Instead of adding every fonts to $sans, we can add some language-specific presets like $sans-simplified-chinese, $sans-traditional-chinese, $sans-japanese, $sans-korean. Then user uses them like:

$sans: "Open Sans", "Helvetica Neue", Arial, $sans-korean, sans-serif !default;

@TheChymera
Copy link
Collaborator

I tested extended Cyrillic and Arabic and they both seem to work - though the Arabic font face does not seem antialiased. However, since I seldom use Arabic, I don't know whether it's a general issue with Arabic at normal fontsizes or indeed something to do with our fonts. We would need a user who regularly uses Arabic on the web to contribute at least to the discussion.

How would adding language-specific variables help?

@yous
Copy link
Contributor Author

yous commented Jul 17, 2014

If we find such users, that will be the best. At first, we can add some instructions extending font-family for specific languages. Also add comments asking pull requests or comments to this issue with their own language-specific font-family.

This is current $sans:

$sans: "Open Sans","Helvetica Neue", Arial, NanumBarunGothic, "Apple SD Gothic Neo", AppleGothic, "Malgun Gothic", DotumChe, sans-serif !default;

When I separate $sans-korean and add it to $sans:

$sans-korean: NanumBarunGothic, "Apple SD Gothic Neo", AppleGothic, "Malgun Gothic", DotumChe;
$sans: "Open Sans","Helvetica Neue", Arial, $sans-korean, sans-serif !default;

It seems to work as same as current code. But we should think about which variable should contain general fonts like AppleGothic since Apple SD Gothic Neo should come before AppleGothic.

@TheChymera
Copy link
Collaborator

Since I am not using fonts with larger or less common character sets, I think I would best understand what you want to do if you create a pull request for this.

The one thing I am worried about:
We don't want to make this too intransparent for our users. Is it not possible to make these fonts work out-of-the-box rather than providing some instructions about how to change the code? (Remember that end-user changes should be able to be confined to the */custom/ directories)

@yous
Copy link
Contributor Author

yous commented Jul 17, 2014

Actually $sans-korean things is a suggestion. When we support languages more than 5 or 10, I don't know how long $sans will be. Also I'm not sure about the browser's font rendering (finding?) performance. Readability of sass code is important too. What do you think?

@TheChymera
Copy link
Collaborator

Well, you can test whether specifying something like:

$sans: $base-sans, $sans-korean, $sans-chinese !default;

in sass/custom/* works. If so, I guess we can do it. But it is unclear to me why we can't just do that specification in the theme files where the user doesn't have to bother. Will the theme be less responsive if we do that?

@yous
Copy link
Contributor Author

yous commented Jul 18, 2014

Oh, that's right. $sans-korean in sass/custom/_fonts.scss doesn't work. Making additional variables is unnecessary. Just splitting the line and adding comments will be enough.

@TheChymera
Copy link
Collaborator

Is this done, or are we still working on it?

@yous
Copy link
Contributor Author

yous commented Aug 13, 2014

There is no progress.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants