Open cmroanirgo opened 7 years ago
I'm able to render CJK character using DroidSansFallbackFull.ttf see googlei18n/noto-cjk#81. Some people point that the issue is with opentype.js
, not Noto.
I've added support for CID-keyed fonts in 0.7.0 and I don't get the parsing bugs anymore for NotoSansTC-Light.otf
.
@edouard-lopez perhaps you want to do some additional testing and let me know if we can close this issue? The previewer at opentype.js.org is updated to the latest version.
Awesome work @fdb! Many thanks for your efforts. My preliminary tests are working flawlessly with many versions of the CJK project (TC, SC in Regular, Bold, Italic, etc). It'll take a natural reader to triple check, but it's looking very good to my western eyes.
Thanks, though the credit mostly goes to @tshinnic who did the bulk of the work. 😄
Grave digging this issue a bit. Unfortunately, NotoSans-KR fails when extracting some of the glyphs into a new copy of the font:
TypeError: Cannot read property 'length' of undefined
at encode.CHARARRAY (/src/kor/font-system/node_modules/opentype.js/dist/opentype.js:1006:28)
at Object.encode.OBJECT (/src/kor/font-system/node_modules/opentype.js/dist/opentype.js:1806:13)
at Object.encode.INDEX (/src/kor/font-system/node_modules/opentype.js/dist/opentype.js:1645:25)
at sizeOf.INDEX (/src/kor/font-system/node_modules/opentype.js/dist/opentype.js:1674:20)
at Object.sizeOf.TABLE (/src/kor/font-system/node_modules/opentype.js/dist/opentype.js:1881:22)
at Table.sizeOf (/src/kor/font-system/node_modules/opentype.js/dist/opentype.js:1949:20)
at Object.makeCFFTable [as make] (/src/kor/font-system/node_modules/opentype.js/dist/opentype.js:5152:24)
at Object.fontToSfntTable [as fontToTable] (/src/kor/font-system/node_modules/opentype.js/dist/opentype.js:7148:25)
at Font.toTables (/src/kor/font-system/node_modules/opentype.js/dist/opentype.js:13449:18)
at Font.toArrayBuffer (/src/kor/font-system/node_modules/opentype.js/dist/opentype.js:13463:27)
at generateFonts (/src/kor/font-system/cli.js:427:44)
at Object.<anonymous> (/src/kor/font-system/cli.js:516:23)
at Module._compile (internal/modules/cjs/loader.js:799:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:810:10)
at Module.load (internal/modules/cjs/loader.js:666:32)
at tryModuleLoad (internal/modules/cjs/loader.js:606:12)
at Function.Module._load (internal/modules/cjs/loader.js:598:3)
at Function.Module.runMain (internal/modules/cjs/loader.js:862:12)
at internal/main/run_main_module.js:21:11
For any of the Chinese variants of Noto Sans (NotoSans-TC and NotoSans-SC), I also get a flooding of Glyph 20154: unknown operator
errors in addition to the above error.
Here's just a sample (though there are hundreds, perhaps thousands of lines):
Glyph 13577: unknown operator 0
Glyph 13579: unknown operator 16
Glyph 13582: unknown operator 16
Glyph 13582: unknown operator 0
Glyph 13582: unknown operator 1228
Glyph 13582: unknown operator 1447
Glyph 13582: unknown operator 16
Glyph 13582: unknown operator 0
Glyph 13582: unknown operator 0
Glyph 13582: unknown operator 0
Glyph 13583: unknown operator 16
Glyph 13585: unknown operator 0
Note that I'm using this library by extracting subsets of glyphs from the original fonts into a new Font object (via the glyphs:
property) and then saving the new OTF out to an ArrayBuffer.
If you want to reproduce:
#!/usr/bin/env bash
set -euo pipefail
git clone git@github.com:kor-tech/npm.font-system.git font-system
cd font-system
npm i
curl -LOJ 'https://fonts.google.com/download?family=Noto%20Sans%20SC'
unzip Noto_Sans_SC.zip
curl -LOJ 'https://fonts.google.com/download?family=Noto%20Sans%20TC'
rm OFL.txt
unzip Noto_Sans_TC.zip
curl -LOJ 'https://fonts.google.com/download?family=Noto%20Sans%20KR'
rm OFL.txt
unzip Noto_Sans_KR.zip
cat > font-system.json <<EOF
{
"TestFont": {
"cjk": [
"./NotoSansTC-Regular.otf",
"./NotoSansSC-Regular.otf"
],
"korean": [
"./NotoSansKR-Regular.otf"
]
}
}
EOF
mkdir out
node ./cli.js -G -o out ./font-system.json
@Qix- I don't see the code you mentioned but I guess it is https://github.com/kor-tech/npm.font-system/blob/master/cli.js?
Yes, correct - specifically https://github.com/kor-tech/npm.font-system/blob/master/cli.js#L381-L458 is where the "pruning" happens.
We take a list of unicode character ranges, find the intersection with the glyphs present in the font itself, and then create a new font out the intersection.
fonteditor-core
is used in order to convert TTF/OTF to other font formats since OpenType doesn't support that out of the box (though, ironically, OTF reading is bugged in fonteditor-core
) but is otherwise unrelated to the bugs we're seeing here.
I notice a few bugs (#188, #139) citing Chinese is not supported. Fair enough, but do you know of any JS libraries supporting CJK? (I came across https://github.com/kekee000/fonteditor-core some time ago, but found it a bit buggy... and writing a new ttf very difficult to achieve without understanding everything about ttf).
This fault raises how all the otf fonts generated for the CJK project (https://github.com/googlei18n/noto-cjk) all seem to have glyph issues, particularly reporting 'unknown operator' errors, eg:
when reading the glyph's CFF path.
The error's source seems to be in
parseCFFCharstring
line 4258.This is a sample otf that is failing: https://github.com/googlei18n/noto-cjk/blob/master/NotoSansTC-Light.otf
As I was trying to assist in generating this report, I looked up the referenced link in the source (https://www.microsoft.com/typography/OTSPEC/charstr2.htm), to find information about these operators... but all 3 are listed as --Reserved--, which I realise is very unhelpful indeed, although https://www.microsoft.com/typography/otspec/cff2.htm#section13 does hint at operator#16 being a 'blend' operator:
(I'm not sure how helpful at all this last information is)