Noto CJK fonts
Home Page: http://www.google.com/get/noto/help/cjk
Download individual fonts from the download guides for Noto Sans CJK or Noto Serif CJK or look in Releases
Release notes and version history are documented separately for Sans and Serif
Noto CJK fonts are also available on Google Fonts but under different names than in this repository. The two letter code here is replaced at Google Fonts as follows:
...
I did a new experiment and the result is different from what I wrote above and
is still NOT what we expect to see. I couldn't reproduce what I wrote above.
Results:
a. Firefox : The last column (Apple SD Gothic Neo) is rendered in 9 distinct
weight instances of Apple SD Gothic Neo
b. Chrome and Safari : It appears that font-weight={100,200,300} are NOT
distinguishable. It appears that 'Apple SD Gothic Neo Light' is used for
font-weight={100,200,300}. The reason I'm not sure is Chrome's DOM Inspector
does not give the full font name (including weight) in Computed section for
this font (it does give the full font names for Noto Sans fonts).
Given that all the browsers behave identically (except for Apple SD Gothic
Neo), something in CoreText is at play here and we have to talk to Apple to
figure out what's going on.
BTW, TextEdit can distinguish all 7 weights (it does not use numeric weight. I
can simply choose 'weight' in the menu).
https://storage.googleapis.com/google-code-attachments/noto/issue-199/comment-3/thin_vs_light.html
...
Blink (Chrome) bug : https://code.google.com/p/chromium/issues/detail?id=449310
Firefox bug : https://bugzilla.mozilla.org/show_bug.cgi?id=1122693
I'll file a bug against Webkit, too.
...
Moved from notofonts/noto-fonts#199
Moved from notofonts/noto-fonts#94
I checked "noto sans" font on Google font examples at:
I tried to input Chinese characters into the "Preview Text" box, but the output are only black crosses, means can not render those words.
Why? I think you created NOTO font to solve those tofus issue when displaying Chinese characters on screen.
If you think noto sans font really support Chinese characters, then, how to use this font when developing a webpage (use it as web font)?
Thank you.
The sample text for Literary Chinese is just a collection of characters from the start of the CJK unified block, it's not representative of Literary Chinese. Consider providing a custom sample.
see #16
Moved from notofonts/noto-fonts#228
What steps will reproduce the problem?
set Noto Sans CJK as the default font for some ubuntu applications (e.g. firefox, spotify)
What is the expected output? What do you see instead?
the width of the font in firefox and spotify is narrower than usual. However, there's no problem with most ubuntu applications: including chrome and ubuntu itself.
What version of the product are you using? On what operating system?
Noto Sans CJK TC/SC 1.001 on Ubuntu 14.04
Moved from notofonts/noto-fonts#70
Moved from notofonts/noto-fonts#102
What steps will reproduce the problem?
What is the expected output? What do you see instead?
No tofu (it is right in the name of the font).
What version of the product are you using? On what operating system?
MacOS X 10.10.1 (Yosemite)
...
Er, uh, the same comment equally applies to Extensions C through E (Extension E
is being added to Unicode this year as Version 8.0). To play the devil's
advocate, I feel obliged to point out that it takes a non-trivial amount of
time to design glyphs for the tens of thousands of CJK Unified Ideographs that
are in Plane 2, so a great deal of patience is necessary.
...
Well, sure. Things do take time. At least we should probably document where
we are along the continuum from mo-tofu to noto-fu. I suggest a character set
coverage table or something. The project proposes to be a font for all of
Unicode, but if stuff like Extension B (which was in Unicode 3.1, and is 14
years old now) are always going to be on the nice to have list, then maybe we
need to call it "lessto", not "noto". I happen to care about Extension B
because my genealogy data includes given names which are out there in ExtB, so
they are (typically) tofu on my family tree website. It's also useful for
testing surrogate pair support with real text.
Moved from notofonts/noto-fonts#242
What steps will reproduce the problem?
What is the expected output? What do you see instead?
CJK fonts third_party/noto_cjk/* shall be in tarball in packages. However, they
are not.
The attached patch can create tarball / zip releases for CJK fonts.
https://storage.googleapis.com/google-code-attachments/noto/issue-110/comment-1/cjk.patch
Any update for this issue? The current make still does not create package for
noto-CJK fonts.
Moved from notofonts/noto-fonts#110
Moved from notofonts/noto-fonts#376
Comma positioning was wrong, but fixed in Version 1.001 CJK.
But another little issue, at the official Google Noto Fonts page, specimen
section, the comma of Noto Sans CJK TC appears lower than usual.
Although I downloaded it and it works right on any text editing app.
The specimen issue is already known:
https://code.google.com/p/noto/issues/detail?id=157
Moved from notofonts/noto-fonts#315
I have some technical problem with implementing font @noto Sans CJK JP Regular (JP/TC/SC/KR) into our application program.
So I need some help to solve this.
Let me explain about the matter in detail.
It seems that the font oddly makes extremely wide line width when it is displayed in VERTICAL LINES.
Please see the attachment and how it looks.
This problem has not seen with other font (e.g. MS Gothic shows appropriate line width).
Thus I assume only Noto Sans may have some problem with displaying line width.
So far, I have confirmed the same matter in Microsoft Word (JP), Microsoft Paint (JP) , so is our application program.
The following is what I have tested to resolve it.
-Wrote code with getting the line width by using Draw Text API from Windows GDI.
-As a result, it did not work Ill. In library of FreeType2, ‘max-advance’ which hold the maximum number of line width shows much larger than any other fonts.
After these experiments, I came to the conclusion that the matter is not related to the implementation but Noto Sans font itself.
Based on that, I would be much appreciated to get any solutions.
If there is anything unclear, please ask me.
[My evaluation environment ;
Windows7 Ultimate (x64)
Noto Sans :Version 1.004;PS 1.004; hotconv 1.0.82; makeotf.lib2.5.63406 ]
Hi, and thanks for the great fonts!
While testing your .ttc files with mPDF (http://www.mpdf1.com/mpdf/index.php) which does not support PostScript/CFF outlines in .otf files, I read the suggestion that in the specification for the TrueType Collection a .ttc file can only contain TrueType outlines (see https://en.wikipedia.org/wiki/OpenType#Description). Would it help users if the OpenType Collection format had a distinct file extension?
What steps will reproduce the problem?
What is the expected output? What do you see instead?
The archive is either in unknown format or damaged.
What version of the product are you using? On what operating system?
WinRAR 3.61
(Windows7)
...
looks fine on linux and mac. will try to locate a win7 with winrar and see if
I can reproduce.
...
I tried the latest version of WinRar (5.21; 64-bit version) [1] and there's no
issue at all in extracting Noto Sans CJK TC. The built-in zip support of
Windows 7 does not have any issue, either.
Why don't you update Winrar to the latest or just use the built-in zip support
on Windows 7?
[1] http://www.rarlab.com/download.htm
Moved from notofonts/noto-fonts#379
using HTML print the char "x33C2" & "x33D8"
Expected: to be displayed as defined in Unicode Chart
33C2 ㏂ SQUARE AM
≈ 0061 a 002E . 006D m 002E .
33D8 ㏘ SQUARE PM
≈ 0070 p 002E . 006D m 002E .
Actual: it displayed as am & pm
See attachment
Hi support team.
How are you?
Thanks for your kindness share great fonts. These days I using the NotoSansCJKKR-hinted fonts.
So I tried to install our intra-net server, but our system only have to use the *.TTF or *.TTC fonts.
Then, do you have TTF font of NotoSansCJKKR-hinted?
If not, do you know how to change the font correctly?
Thank you.
Best Regards.
Leo.
Moved from Moved from notofonts/noto-fonts#120
@roozbehp reported on 6 Aug 2014 at 8:07:
According to Denis (@moyogo), the fullwidth angle brackets in the CJK fonts
should be proportional for Korean, any recent Korean font (by Sandoll or Yoon
Design) would do that.
@kenlunde wrote on on 7 Aug 2014 at 2:11:
Given that an ideal Korean experience with Noto Sans CJK (and, of course, the
Adobe-branded Source Han Sans) requires support for the 'locl' GSUB feature,
along with proper language-tagging at the character, paragraph, or document
level, in order to access the Korean- or CJK-specific forms of
proportional-width Western punctuation (the glyphs are aligned to the em-box
rather than to Latin features, such as the x-height or cap-height), I would
lump this request in with that, specifically that the 'palt' (or 'vpal' for
vertical) GPOS feature should be invoked, which will make the glyphs for U+3008
and U+3009 immediately suitable for proportional use. The 'palt' GPOS feature
additionally handles other similar character pairs, in case they're used
instead of their ASCII (proportional) counterparts. I thus consider the
priority relatively low.
@jungshik wrote on on 15 Aug 2014 at 12:34:
Blink (and Webkit) have two contents rendering paths. By default, CJK is
rendered in a 'simple script' rendering path where most GSUB/GPOS features are
not invoked.
The majority of documents on the web in Korean will go through that simple
script path.
Even if those 'palt' and 'vpal' can be turned on by default in 'Noto Sans CJK
Korean' (or 'Noto Sans Korean'), I'm afraid that it might not work for the
above scenario.
So, it appears that we need to have separate glyphs for U+3008 ~ U+300B (and
potentially more). As we discussed at the meeting, we'll try to come up with a
list of characters whose advance widths are different between Noto CJK/Source
Han and Korean fonts by Sandoll/Yoon design.
Attached are two screenshots, one with NanumGothic and the other with Noto Sans
Korean. They have U+300A and U+300B. The text used is "《로스트》는
평론과 대중"
There's no space between U+300B '》' and '는' (the first character after
U+300B), but visually, it looks like there is if Noto Sans Korean is used.
With NanumGothic, there's no such problem.
As I mentioned during the meeting, we can open up glyph slots by removing
separate glyphs for Hangul Halfwidth Jamos (U+FFA0 - U+FFCx) and just mapping
them to the corresponding nominal glyphs for Hangul Jamos (U+11xx block) or to
the corresponding Hangul Compat Jamo (U+31xx block). That way, we can open up ~
50 glyph slots.
@kenlunde wrote on 17 Aug 2014 at 1:21:
This issue is definitely being deferred for the first update, and I'd prefer to
defer it indefinitely because this doesn't seem to be the right way to address
the issue, especially for the long term.
Referencing what other fonts do may seem like the right approach, but that is
not always a good idea. For those who are interested in this issue, I strongly
encourage going through KLREQ: http://www.w3.org/TR/klreq/
What should happen is interaction between the layout engine and fonts, with
awareness of the language. Japanese layout engines have matured, and the same
thing is happening for Korean. Some characters are best left full-width, such
as those in U+30xx, which will allow the layout engine to deal with them
consistently.
The problem with the what is being proposed is where to draw the line. Instead,
the line should be drawn between what the font specifies and what is expected
on the layout engine. That happened for Japanese, and it needs to happen for
Korean.
Also, mapping the nominal glyphs for the U+11xx block from the half-with jamo
block (U+FFxx) would be a disaster, because combining jamo takes place at the
GID level, not character code level.
Again, please read KLREQ carefully. It sets the stage for better Korean layout.
What the referenced fonts are doing is ad hoc at best.
@jungshik wrote on 25 Aug 2014 at 10:46:
Also, mapping the nominal glyphs for the U+11xx block from the half-with
jamo block (U+FFxx) would be a disaster, because combining jamo takes place
at the GID level, not character code level.
I did realize that after writing my comment. However, there'd be no problem if
we just remap U+313x glyphs for U+FFxx half-width jamo block. Nobody would care
whether or not U+FFxx block uses the same glyphs as U+313x block.
@jungshik wrote on 25 Aug 2014 at 10:51:
Instead, the line should be drawn between what the font specifies and what is
expected on the layout engine. That happened for Japanese, and
it needs to happen for Korean.
Where has it happened for Japanese? InDesign?
@kenlunde wrote on 25 Aug 2014 at 11:02:
Any application that claims Japanese support for line layout should be able to
many of these basis adjustment tasks. Adobe InDesign was one of the first
desktop apps to do so, and serves as a benchmark. The fact that JLREQ is
emanating from W3C suggests that some web browsers include such support.
What the fonts you have referenced have done is equivalent to jerry-rigging the
glyph set, which is something that should be avoided, mainy because it gives
birth to legacy issues and concerns.
@kenlunde wrote on 26 Aug 2014 at 2:31:
About mapping the half-width jamo (U+FFxx) to the glyphs for compatibility jamo
(U+31xx), while you may may not care, I am guessing that a non-zero number of
users will care, which is the reason why I am reluctant to jettison those
glyphs. In any case, we'll be discussing this issue in more depth in October.
@moyogo wrote on 28 Aug 2014 at 6:14:
KLREQ is still a draft and does not clearly address spacing of punctuation.
There are already some issues with KLREQ that might need to be dealt with to
clarify this:
http://www.w3.org/International/track/issues/269 Inconsistent spacing
http://www.w3.org/International/track/issues/271 Punctuation
@kenlunde wrote on 28 Aug 2014 at 12:16:
Precisely, which is exactly why we shouldn't rush into adding such glyphs to
the fonts in case doing so creates a nasty legacy condition.
@behdad wrote on 26 Oct 2014 at 1:50:
Action item for Jungshik to test U+30xx and U+FFxx (proportional versions of
ASCII brackets) against a bunch of (15 / 20?) high-quality Korean fonts for
comparison.
Hi
I am using Nexus 5 Android 6.0.
When I set system language to Japanese, some Chinese simplified font looks strange.
Please see the follow pictures to confirm.
Thanks!
Moved from notofonts/noto-fonts#42
What steps will reproduce the problem?
1. In font setting, set serif to Noto sans CJK SC
2. In advanced font setting, set serif to Noto sans CJK SC
What is the expected output? What do you see instead?
Expected Ouput: when web page font family use serif, the font should be Noto sans CJK SC
Actually output: the serif font shows Song or something relative.
What version of the product are you using? On what operating system?
It's on chrome on OS X Yosemite
Please provide any additional information below.
When I set the serif value to other fonts like STHeiti, sans, Noto sans...., the output is right.
...
Sorry for the late reply. What version of Chrome are you using?
I can't reproduce this problem. After setting the default serif font to Noto
Sans CJK SC, I tried the following URL.
data:text/html;charset=UTF-8,维基百科
Noto Sans CJK SC is picked up.
I'm on 40.0.2214.94. What version of Chrome did you use?
Moved from notofonts/noto-fonts#211
using HTML print the char U+2640..2647
Need to look the same as defined in Unicode set
Attached is a comparison between MAC,Android & Unicode with comments about problems
Those glyphs are not implemented on many platform including OSX10.10.3
變
using HTML print the char "xFAC0" & "xFAD0" ==> 變 &
Expected: to be displayed as defined in Unicode Chart
Actual: it displayed as squares
See attachment
From Roozbeh:
Confirming the problem, but these are two separate bugs:
From Jungshik Shin:
This is partly an old issue. Ken Lunde would not map U+FAC0 to its canonical equivalent (one of glphs for U+8B8A) saying that he does not know exactly what glyph to use for DPRK variant (U+FAC0) and supporting DPRK is not in the scope of Noto CJK. Both Roozbeh and I disagreed, but failed to persuade him.
If we do care about DPRK compatibility ideographs (the chance of them being used on the web/Android is virtually zero), we can map all of them with canonical equivalents to existing characters in Noto CJK.
Those without the canonical equivalents (like U+FAD0) covered in Noto CJK are out of luck. They do not have canonical equivalents because they're in Plane 2 and Noto CJK is scoped to cover a small subset of Plane 2 essential for regular Japanese/Chinese/Korean usage.
Moved from notofonts/noto-fonts#378
Noto sans CJK Japanese,
Adobe acrobat DC, PDF creator, cube pdf, Promo pdf and a few Japan local pdf softwares(Free and commercial).
Windows7 32bit, 64 bit
making PDF via pdf printer driver, almost only 2 bit character text are deleted (a few character is kept)
Using other font, no delete.
Changing from Noto sans to Han sans font (adobe), we have no-trouble
Adobe acrobat PDF maker have no-trouble with Noto sans CJK japanese.
Probably, Noto sans CJK Japanese do NOT support postscript print with postscript PDF printer driver.
Or Noto sans CJK Japanese have a bug for postscript PDF driver..
Moved from notofonts/noto-fonts#105
Re-arranging them to the following categories:
SuperOTC
OTC
OTF
SubsetOTF
HW-OTF
In terms of directories will really help with choosing the fonts to use (for packagers, and users).
Please consider this, thanks.
What steps will reproduce the problem?
What is the expected output? What do you see instead?
Since Noto Sans can show all Chinese/Japanese/Korean characters, no umbrella
font (e.g., 'Gulim') should be used when viewing typical web pages containing
CJK letters.
But when I choose Noto as default (and Sans-serif) font in Chrome, every Korean
letter is in Gulim, which is ugly since it does not support ClearType.
What version of the product are you using? On what operating system?
Please provide any additional information below.
I guess .OTF files are filtered by some applications. When using font dialog in
several applications, the enumeration skips Noto Sans in some apps and not in
others. For example in MS Word Noto works perfectly, in IE11 not even on the
list, in Chrome on the list but not working.
Here is the screenshot of IE11 font enumeration not showing Noto Sans.
https://storage.googleapis.com/google-code-attachments/noto/issue-192/comment-1/nonoto.PNG
Turning off DirectWrite makes me see Google Noto Sans CJK fonts in browser, but
they are way more ugly than them in Firefox...I cannot describe it but native
CJK users will definitely see it at a glance
...
Adobe's testing suggests that there is an issue with Chrome about selecting
non-default fonts. About IE, it seems that only TrueType fonts can be
specified, which probably makes sense to Microsoft given that they bundle only
TrueType fonts with their OS. In other words, the issue is not with the fonts,
but with browsers' inability to use or select them.
Moved from notofonts/noto-fonts#192
See #19
The images were fixed, but the auxiliary information about Cantonese, Min Nan, and Hakka is limited, since these can be written in both Hans and Hant.
Moved from notofonts/noto-fonts#62
The zip download shouldn't have hinted in the name. It doesn't really mean
anything in the context of CFF and it will probably be confusing.
Characters (U+0000 to U+001F) have length of 1 and map to space.
Please advice me how to use NotoSansCJKsc font for web.
I have tried online tools for web font conversion and failed.
Moved from notofonts/noto-fonts#357
Moved from notofonts/noto-fonts#200
Moved from notofonts/noto-fonts#98
What steps will reproduce the problem?
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
Moved from notofonts/noto-fonts#96
Hi, after testing Noto Sans CJK SC Light with some Vietnamese and English text, I experienced the following issues:
Hope this helps!
Please note that the download link on https://www.google.com/get/noto/help/cjk/ regarding Noto Sans CJK All-in-one Super OTC font is broken. http://www.google.com/get/noto/pkgs/NotoSansCJK.ttc.zip cannot be found.
I tried to download Noto CJK TC in my fonts subdirectory and create font-face in SASS under stylesheets subdirectory. My project structure like this
/public
/fonts
/stylesheets
Here is my SASS file font-face segment:
/* Noto Sans CJK TC Light */
@font-face {
font-family: "Noto Sans CJK TC";
src: url("../fonts/NotoSansCJKtc-Light.otf") format("opentype");
font-stretch: normal;
font-weight: 300;
font-style: normal;
}
/* Noto Sans CJK TC Regular */
@font-face {
font-family: "Noto Sans CJK TC";
src: url("../fonts/NotoSansCJKtc-Regular.otf") format("opentype");
font-stretch: normal;
font-weight: 400;
font-style: normal;
}
/* Noto Sans CJK TC Medium */
@font-face {
font-family: "Noto Sans CJK TC";
src: url("../fonts/NotoSansCJKtc-Meidum.otf") format("opentype");
font-stretch: normal;
font-weight: 500;
font-style: normal;
}
When I open my web page in Chrome, I encounter the following error and I can directly download the font file if I open the URL.
Failed to decode downloaded font: http://localhost:3000/fonts/NotoSansCJKtc-Regular.otf
Do you have any hint?
Although the fonts appear to contain the actual glyphs, the cmap format 14 subtables are incomplete or even missing.
For example, the glyph for <U+9089, U+E010E> (cid62814) does exist in both NotoSansCJKtc-Regular.otf and NotoSansCJKjp-Regular.otf, but only the Japanese font has cmap format 14 mappings to it. The Traditional Chinese font has a much smaller cmap format 14 subtable, which doesn't map to the glyph.
(In fact, there seems to be no way to reach the glyph in the Traditional Chinese font, except through the glyph ID/name.)
Platform: Windows 10.
I tried to set Noto Sans CJK SC TC JP Regular as default but they couldn't be applied .
But Noto Sans CJK Demlight / Light / Bold /... can be applied.
U+339F, U+33A3, U+33A4 look bad. See the image below:
339F ㎟ SQUARE MM SQUARED
≈ 006D m 006D m 00B2 ²
33A3 ㎣ SQUARE MM CUBED
≈ 006D m 006D m 00B3 ³
33A4 ㎤ SQUARE CM CUBED
≈ 0063 c 006D m 00B3 ³
BTW, this was filed internally : b/21499141
My google chrome on android say:
404. That’s an error.
The requested URL /get/noto/cjk.html was not found on this server. That’s all we know.
I got 1.002 and tested with CJK glyphs,
Latin(ASCII) glyphs are corrected half-width,
but Korean glyphs are not full-width yet.
And I found CJK unified ideographs some mismatch too.
Please look at this attached image.
If font's CJK width to full-width correctly
blue blocks will balanced.
After correct glyph, please check monospaced proportion value in PANOSE.
...
Lots of stuff going on here, but the end result is the same: As Designed.
The Korean glyphs (hangul letters and syllables) were specifically designed to
use horizontal advances that are 92% (920 units) of full-width (1000 units).
Making them full-width (1000 units) would entail the complete design of the
glyphs, which would necessarily fork the monospaced OTFs and OTC font
instances, and would negate almost all of the space savings from sharing the
'CFF' tables in the OTCs. Simply changing their horizontal advances would
result in far too much perceived inter-character spacing, and would also
require separate CFFs, again negating the size benefit of the OTCs. Keep in
mind that the number of glyphs that would be affected is well over 13,000. In
other words, making the glyphs for the Korean hangul letters and syllables
tabular with respect to the half-width ASCII glyphs and those for the
ideographs, is not going to happen.
The issue about some CJK Unified Ideographs apparently not being completely
full-width (1000 units) is an application issue. I carefully ensured that the
horizontal advances for the 48,810 ideograph glyphs (CIDs 1348-1376, 1819-1854,
2430-47536, 58810-58918, 59452-61768, and 61783-62994), and I just rechecked
them to reconfirm this point. The fonts are okay.
About the OS/2.panose array, the current value for the fourth bit (Proportion)
is correct when you consider that less than 100 characters were changed from
proportional to half-width. There are 200 to 300 additional characters,
specifically additional Latin ones, along with those for Greek and Cyrillic,
that continue to be proportional.
The "Mono" OTFs and OTC font instances simply repurpose half-width glyphs that
have been included as part of the glyph set from Version 1.000, and they are
made default (encoded) through the use of different mappings in the 'cmap'
tables. More details can be found in the detailed 25-page Source Han Sans
ReadMe file:
https://github.com/adobe-fonts/source-han-sans/raw/release/SourceHanSansReadMe.p
df (the PDF file will download when the URL is clicked)
Moved from notofonts/noto-fonts#343
Only a few glyphs in Latin-extended part are supported by this font family (Noto Sans CJK JP/KR/SC/TC). Look at this page in Noto Sans CJK TC:
See? Those letters consonant letters with caron above, such as č š, are mapping to a different font! This is because this part of glyphs is not finished yet.
Please, get this done by your next release.
Btw, this part is already done in the Noto Sans font (non-CJK). Noto Sans CJK fonts are using different patterns for Latin glyphs. You may notice this by looking at the glyphs such as "I" in upper case and "l" in lower case in Noto Sans and Noto Sans CJK. Why not simply take the glyphs from Noto Sans?
PDF files generated by Google's internal PDF generator with Noto Sans CJK cannot be opened in Adobe Reader.
See also #36 for a related issue.
This is from Google's internal bug ( https://b/21402687 )
Sorry, I don't know if it's a bug of noto sans cjk, but I just report it to here first.
█ Steps:
█ The result I got:
What steps will reproduce the problem?
Go to noto site, search for Chinese, click on Literary Chinese. Character
sample includes some simplified characters.
Or scroll through the list, click on Noto Sans CJK TC. The sample is a
collection of characters that includes simplified characters.
From ken.lunde (comment on issue 337):
"Noto Sans CJK TC sample still includes characters that are specific to
Simplified Chinese (this is because the sample is simply U+4E00 through U+4E40,
which includes characters that are out-of-scope of Traditional Chinese)."
If you click on Taiwan and select Traditional Chinese, you see a sample of
Article 1 from the UDHR that is better.
What is the expected output? What do you see instead?
It's misleading that samples for Literary Chinese and for CJK TC include
characters that have only a simplified form.
Please use labels and text to provide additional information.
Moved from notofonts/noto-fonts#341
There are a lot of glyphs that don't match their unicode:
Example:
U+5486 uses the same glyph as U+5485
U+5514 uses the same glyph as U+5513
I think there are hundreds of these occurences.
First, my MS Word 2010 file:
https://www.dropbox.com/s/95l2cc3x1xfys2r/%EA%B3%A0%EC%A0%95%ED%8F%AD%20%EC%84%9C%EC%B2%B4.docx?dl=0
When i save this file into a PDF file using 'Save as' menu, I got the below PDF file.
(I unchecked 'Bitmap text when fonts may not be embedded' option)
https://www.dropbox.com/s/u1ckna6fz48ybms/%EA%B3%A0%EC%A0%95%ED%8F%AD%20%EC%84%9C%EC%B2%B4.pdf?dl=0
As you see in 'Document Properties' in Acrobat or Reader,
Noto Sans Mono CJK KR Regular wasn't subset or at least not subset as TrueType.
And when copying the 4th line, Korean characters "한글" is not copied at all. It's just a bitmap, I guess.
I don't know whose problem this is (maybe MS Word?) but
I think the font itself should be easier to use universally, ie independent of applications.
Any idea or similar problem?
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.
