Some Korean(CJK) fonts problems

fantong · Post by **fantong** » Tue Jan 13, 2004 8:39 am

I'm korean and use korean fonts (one of double-byte fonts). There are lots of problems in dealing with some of CJK fonts. I'll tell you some of them.

Firstly, most of times, I successfully open and edit korean fonts with FCP 4.0. But some of fonts cannot openned with FCP. When I retry to open these fonts with Fontlab Demo, some of them can be openned and some still cannot. I'd like to know why. I'll upload them if you want.

Secondly, when I view the naming field of korean fonts with FCP, it is hard to edit or make new fonts with naming in Korean. FCP shows "\CC9C\B9AC\C548\CCB4H" instead of Korean. (later I get to know this is in microsoft encoding) Is there any solution to this or sort of converting tables?

vanisaac · Post by **vanisaac** » Wed Jan 14, 2004 1:03 am

The converting table should be simple Unicode encoding. From www.unicode.org, "\CC9C\B9AC\C548\CCB4" comes out as (forgive my horrendous transliteration - I don't know Korean) "cheon-ri-an-che" - pure Hangul. The "H" at the end has me stumped, though. I don't know what that could be.

As for fonts that FCP won't open, are they .ttf files? FCP is a true type font editor, and if you try to open some other font format, it won't work.

fantong · Post by **fantong** » Wed Jan 14, 2004 5:01 am

Thanks

, vanisaac

My second question has now solved by you, it is still not easy though. I expect some next version of FCP support unicode input. I do not want type every letter in my MS word something like that !(\CC9C\B9AC\C548\CCB4H etc)

My first question is still pending. Of course, I'm trying to open Truetype fonts(TTF). What makes me more at loss is some fonts are working all right in Windows but they never will be openned in FCP. Is this result from "fonts'' or "program"? I'm not sure. But one thing I know is that font can be openned with other software like Fontlab.

Erwin Denissen · Post by **Erwin Denissen** » Wed Jan 14, 2004 6:48 am

I expect some next version of FCP support unicode input.

This is on the to do list.

My first question is still pending. Of course, I'm trying to open
Truetype fonts(TTF). What makes me more at loss is some
fonts are working all right in Windows but they never will be
openned in FCP. Is this result from "fonts'' or "program"? I'm not sure.

Can you send the font files that won't open in FCP to me, so I can investigate the problem?

vanisaac · Post by **vanisaac** » Wed Jan 14, 2004 9:40 am

fantong wrote:I do not want type every letter in my MS word something like that !(\CC9C\B9AC\C548\CCB4H etc) :shock:

You shouldn't have that problem unless MS word itself won't let you input Korean normally. It's really just internal to FCP that this problem should be cropping up. With my font, I have no problem inputting Greek and Cyrillic directly by just chosing my Greek and Russian keyboard layouts and typing away.

fantong · Post by **fantong** » Thu Jan 15, 2004 8:03 am

vanisaac wrote:You shouldn't have that problem unless MS word itself won't let you input Korean normally.

I'm not meaning that

I'm joking! Sorry for my broken english. And thanks anyway. With MS word, everything's OK. but With FCP, it is hard to type every letters in converted numbers and find such numbers corresponding the korean letters.

vanisaac wrote: It's really just internal to FCP that this problem should be cropping up. With my font, I have no problem inputting Greek and Cyrillic directly by just chosing my Greek and Russian keyboard layouts and typing away.

I know that this happens just because I'm using Double Byte encoded fonts. I also have no problems with english, or french font name. But you know....

Erwin Denissen · Post by **Erwin Denissen** » Sat Jan 17, 2004 6:22 pm

The font you send to me was corrupt. One table mentions 13716 glyphs while another has information that indicates 13575 glyphs. I have improved the Font Creator Program (see release v4.2) in such a way it will be able to open this font, although 141 (13716 - 13575) glyphs will miss their outlines.

Let me know if this solves all problems related to the other fonts as well.

fantong · Post by **fantong** » Sun Jan 18, 2004 1:25 pm

Thanks a lot,

Erwin.
FCP version 4.2 works greatly with 55 other korean fonts from that font foundry. But aside from that company, there are still tons of other fonts that are impossible to be loaded in FCP. (some of them are chinese fonts made by chinese, and japanese also.)

And now I am sure that some korean fonts didn't abide by the standards so that was the reason why your FCP can't load them. But as you could eliminated the barrier so that some corrupted fonts also can be loaded, I'd like to know if other corrupted fonts (fonts that have some bugs in it) can be loaded in FCP.

I'll send three of them in email.

Erwin Denissen · Post by **Erwin Denissen** » Sun Jan 18, 2004 3:16 pm

I'm glad to know almost all fonts can be processed by the Font Creator Program.

I'm looking forward to investigate the other fonts.

Erwin Denissen · Post by **Erwin Denissen** » Sun Jan 18, 2004 4:01 pm

The Font Creator Program is able to open all three fonts, but they are corrupt like the others.

Here is a report:

Code: Select all

   1 FontsWarnings [D:\Temp\Font\fonts_kor\HYSMMJ.TTF] WARNINGS
Integrity: Font EntrySelector not correct (2 should be 3).
Integrity: Table name Checksum not correct (1364098283 should be 1364098476).
Integrity: Check Sum Adjustment not correct (-1260479020 should be -416771764).
Integrity: Cmap SubtableFormat4 EntrySelector not correct (5 should be 6).
[fixed] Glyph index 350 offsets not correct: GlyphOffsetBegin 10344 GlyphOffsetEnd 0
[ignored] All other glyph outline data will be skipped.

   2 FontsWarnings [D:\Temp\Font\fonts_kor\MPDINA.TTF] WARNINGS
Integrity: Font SearchRange not correct (48 should be 128).
Integrity: Font RangeShift not correct (128 should be 48).
Integrity: Table glyf Checksum not correct (-1622851300 should be -884644580).
Integrity: Table head Checksum not correct (-1630027789 should be -1324734961).
Integrity: Table name Checksum not correct (1085041749 should be 1085041932).
Integrity: Table prep Checksum not correct (-1342141000 should be -1308618056).
Integrity: Check Sum Adjustment not correct (-305292828 should be -1660003655).
[fixed] Glyph index 97 offsets not correct: GlyphOffsetBegin 10606 GlyphOffsetEnd 0
[ignored] All other glyph outline data will be skipped.

   3 FontsWarnings [D:\Temp\Font\fonts_kor\SMDNR.TTF] WARNINGS
Integrity: Font SearchRange not correct (48 should be 128).
Integrity: Font RangeShift not correct (160 should be 80).
Integrity: Table glyf Checksum not correct (0 should be -80401690).
Integrity: Table head Checksum not correct (0 should be -1324996999).
Integrity: Table hhea Checksum not correct (0 should be 129570569).
Integrity: Table hmtx Checksum not correct (0 should be -505656153).
Integrity: Table loca Checksum not correct (0 should be 1347318296).
Integrity: Table maxp Checksum not correct (0 should be 333316694).
Integrity: Table name Checksum not correct (1249015143 should be 1249015326).
Integrity: Table OS/2 Checksum not correct (0 should be 2087458217).
Integrity: Table post Checksum not correct (0 should be 1769497).
Integrity: Table cvt  Checksum not correct (0 should be -1040540251).
Integrity: Table prep Checksum not correct (0 should be 1431379526).
Integrity: Table fpgm Checksum not correct (0 should be -1478926701).
Integrity: Check Sum Adjustment not correct (-1313820742 should be 755208293).
Integrity: Cmap SubtableFormat4 RangeShift not correct (146 should be 80).
[cmap encoding format 4] A character maps to an invalid glyphindex 4906.
[cmap encoding format 4] A character maps to an invalid glyphindex 4907.

<even more invalid mappings>

[cmap encoding format 4] A character maps to an invalid glyphindex 9792.
[cmap encoding format 4] A character maps to an invalid glyphindex 9793.
numglyphs loca (12145) and maxp (4906) are different.
Post numberOfGlyphs (37778) does not equal Maxp numGlyphs (4906).
[fixed] Glyph index 256 offsets not correct: GlyphOffsetBegin 20002 GlyphOffsetEnd 0
[ignored] All other glyph outline data will be skipped.

There is not much I can do about this. You should try to get a copy of the original fonts.

fantong · Post by **fantong** » Sun Jan 18, 2004 5:21 pm

Thanks for quick reply. All three fonts, as I mentioned in email, works fine in Windows98, WindowsME. So I think that even if the fonts are corrupted, it may not that serious. It is bizzare that I could use those fonts with lots of bugs in it.

And two companys out of three (that made those fonts) had got out of business so the only way to use them in Windows XP is correct the fonts myself. But my only hope is gone! Alas.

Great program and great support!

Erwin Denissen · Post by **Erwin Denissen** » Sun Jan 18, 2004 10:31 pm

The next upcoming release will continue to load outlines after a corrupt glyph offset.

fantong · Post by **fantong** » Tue Jan 20, 2004 5:26 pm

Here I am again with one korean OTF file. This font is recognizable in Mac OS X and ,If I know correctly, every OTF fonts are shareable between Mac and Windows. Is this file have someting wrong again or FCP does not yet fully support OTF file? I've emailed this font to you.

Erwin Denissen · Post by **Erwin Denissen** » Tue Jan 20, 2004 6:23 pm

I haven't received the font yet.

The OpenType font format is an extension of the TrueType font format, allowing support for PostScript font data. OpenType was developed jointly by Microsoft and Adobe to produce a hybrid between Type 1 and TrueType fonts, with additional features that works on Macintosh and Windows computers. As part of the deal, Type 1 should receive built-in support in future versions of Windows.

The Font Creator Program doesn't support the Type 1 variant of OpenType.

vanisaac · Post by **vanisaac** » Tue Jan 20, 2004 6:45 pm

Just to let people know, the postscript Type 1 font format uses a different kind of math to create outlines. Instead of the quadratic bezier curves that true type (and FCP) use, they use a cubic bezier curve, where you have anchor points (equivalent to our on-curves), and out of each side, instead of needing only one "off-curve" point between on-curves, there are TWO "handles" used to define a curve. Theoretically, there are shapes that quadratic bezier curves can't make that the cubics can, but neither can make a perfect circle, so it probably doesn't matter. A font's outline data can be perfectly translated from true type's quadratics into postscript's cubics, but not quite the other way around. It is pretty easy to get an approximation that fits so close that it will cause a difference of only a couple pixels in a character filling a whole sheet of paper, so I wouldn't stay up nights worrying about it.