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

Sample images of Noto CJK TC are incorrect #19

Closed
oliviazhu opened this issue Jun 10, 2015 · 6 comments
Closed

Sample images of Noto CJK TC are incorrect #19

oliviazhu opened this issue Jun 10, 2015 · 6 comments

Comments

@oliviazhu
Copy link

What steps will reproduce the problem?

  1. visit http://www.google.com/get/noto/
  2. search "Traditional Chinese" in the search box
  3. the sample images are incorrect.

What is the expected output? What do you see instead?
They look like SC variant, not TC variant.

I can confirm that the TC fonts were not used to create these specimens. The
punctuation, which is not centered, is another clue.

Moved from notofonts/noto-fonts#157

@jungshik
Copy link

@dougfelt, @xiangyexiao : Is this still an issue?
At least, punctuation marks are now centered.

@jungshik
Copy link

/cc @xiangyexiao
/cc @fontguy

@hfhchan
Copy link

hfhchan commented Aug 20, 2015

It's corrected now.

Strangely, "Cantonese" is listed under Noto Sans CJK SC but not Noto Sans CJK TC. I suspect the majority of written Cantonese users would be people in Hong Kong who may prefer Noto Sans CJK TC. Second, it'll be more preferred if "Cantonese" were written as "Yue Chinese" to be more precise and consistent with the the other Chinese languages / dialects. Cantonese would translate to the language spoken in Guangzhou / Gaungdong, but Yue Chinese is surely not use in use in Guangzhou nor is it the sole majority language of Guangdong. The appropriation of supported languages between SC and TC seem arbritary too. Maybe it makes sense to list everything except SC and TC under both?

@dougfelt
Copy link
Contributor

We're using the CLDR data, so in a fundamental sense these are CLDR issues.

CLDR thinks yue is written only in Hans. I think we can probably patch our copy of CLDR to say both Hans and Hant, with Hant being more likely.

CLDR defines the English name of yue as 'Cantonese'. I think, at least in English, 'Cantonese' is more commonly used than 'Yue Chinese' for yue, despite being technically a misnomer as you say. We identify languages by iso 639-2/3 language code, and there's no language code expressly for Cantonese. Finally, although we use yue internally as the code, I expect the font has been looked at primarily in terms of support for Cantonese in particular. I'm not sure whether Cantonese has character or glyph requirements different from Yue as a whole, but if it does, I expect Cantonese has been the driver of these requirements that we managed to support (and I expect we don't support them all). So all in all I think 'Cantonese' is probably still a better term for us to use.

@hfhchan
Copy link

hfhchan commented Aug 21, 2015

The main dialect of Yue Chinese is indeed usually referred as Cantonese, so it's not too a big deal. The characters required by written Cantonese sans written Standard Chinese are predominantly encoded in HKSCS - of which is the covering target of the TC version.

Patching to say both hant and hans seems a good solution. Apart from their howntown being in China, there's also a hefty hakka population in Hong Kong and a min population in Taiwan, both areas using Traditional Chinese. These other two languages would more accurately be listed under both. Lastly it takes to note that Wikipedia uses simplified Chinese for all Chinese languages except Yue and Literary Chinese by default - so that may suggest default preferences.

@dougfelt
Copy link
Contributor

I'm closing this since the sample image problem has been fixed. I opened a separate bug for the language-script pairing issue.

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

No branches or pull requests

4 participants