[ft-devel] Japenese OTF font with funny encoding
New issue which may or may not be FreeType issue. A tester has identified that the Japenese OTF font DFPKaiSho-SB didn't work right. Looking at it, it doesn't include a Unicode encoding vector. After opening the font, I dumped the charmaps. This is what I get: ftface-num_charmaps = 2 For ftface-charmaps[0] encoding=61726D6E(armn) platform=1 encoding_id=0 (iterating using FT_Get_First/Next_Char yeilds 255 chars). For ftface-charmaps[1] encoding=0(!!) platform=1 encoding_id=1 (iterating using FT_Get_First/Next_Char yeilds 8589 chars). This font works with OS X applications, so I wonder how do I determine what the encoding is for 0 in this case? The charcodes that FT_Get_First/Next_Char yields ranges from 0-128, 33088-40956 and 57408-60924. Looking at the characters, it _looks_ like they are Shift-JIS encoded. How would I determine that programatically using FreeType? Second, can I supply a synthetic charmap somehow to synthesis a Unicode table, or do I need to convert my Unicode to Shift-JIS and just use the existing charmap? Deron - Deron Kazmaier - [EMAIL PROTECTED] Grasshopper LLC Publishing - http://www.pagestream.org PageStream DTP for Amiga, Linux, Macintosh, and Windows ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Japenese OTF font with funny encoding
For ftface-charmaps[1] encoding=0(!!) platform=1 encoding_id=1 (iterating using FT_Get_First/Next_Char yeilds 8589 chars). Hmm, PID/EID 1,1 is Japanese on a Mac, so FreeType is correct in saying that encoding = FT_ENCODING_NONE because it doesn't contain mapping tables. This font works with OS X applications, so I wonder how do I determine what the encoding is for 0 in this case? Value `0' means that FreeType can't handle it, not that it is an unknown encoding! You have to use other means handle the encoding, for example, looking at the PID/EID pair directly. The charcodes that FT_Get_First/Next_Char yields ranges from 0-128, 33088-40956 and 57408-60924. Looking at the characters, it _looks_ like they are Shift-JIS encoded. Yes. I'm quite sure that Japanese for older Macs is always encoded in SJIS. However, you should look up the Mac documentation to verify this. How would I determine that programatically using FreeType? You can't. Second, can I supply a synthetic charmap somehow to synthesis a Unicode table, or do I need to convert my Unicode to Shift-JIS and just use the existing charmap? The latter. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Japenese OTF font with funny encoding
Hi, Werner had already given the answer, but it's a pity for japanese macintosh user to say nothing. I don't have exactly same font with Deron, but I've bought several TrueType and ATM font packages from Dynalab. I want to add 2 supplementary comments. 1) Some Dynalab font has problematic cmap for Shift-JIS. If you have Osaka font on Mac OS X, ftdump will list 3 cmaps: Unicode, Roman, and Shift-JIS. There's no problem. But, some Japanese fonts from Dynalab, ftdump won't list Shift-JIS cmap, in some cases. This is because Dynalab's TTF often includes problematic cmap for Shift-JIS. FreeType2 ignores it. 2) Shift-JIS variants on MacOS At least, there were 2 kinds of Shift-JIS variants on Japanese Macintosh. One was designed for KanjiTalk 6 (MacOS 6) and another was designed for KanjiTalk 7 (MacOS 7). I think there's no official method to distinguish them. I guess if PostScript name of the font finishes with 83pv-RKSJ-H, it's supposed to be Shift-JIS for KT6, and if it finishes with 90pv-RKSJ-H, it's supposed to be Shift-JIS for KT7. However, there are Japanese fonts without such extensions (e.g. Apple's Osaka). Regards, mpsuzuki On Tue, 01 Jan 2008 11:00:07 +0100 (CET) Werner LEMBERG [EMAIL PROTECTED] wrote: For ftface-charmaps[1] encoding=0(!!) platform=1 encoding_id=1 (iterating using FT_Get_First/Next_Char yeilds 8589 chars). Hmm, PID/EID 1,1 is Japanese on a Mac, so FreeType is correct in saying that encoding = FT_ENCODING_NONE because it doesn't contain mapping tables. This font works with OS X applications, so I wonder how do I determine what the encoding is for 0 in this case? Value `0' means that FreeType can't handle it, not that it is an unknown encoding! You have to use other means handle the encoding, for example, looking at the PID/EID pair directly. The charcodes that FT_Get_First/Next_Char yields ranges from 0-128, 33088-40956 and 57408-60924. Looking at the characters, it _looks_ like they are Shift-JIS encoded. Yes. I'm quite sure that Japanese for older Macs is always encoded in SJIS. However, you should look up the Mac documentation to verify this. How would I determine that programatically using FreeType? You can't. Second, can I supply a synthetic charmap somehow to synthesis a Unicode table, or do I need to convert my Unicode to Shift-JIS and just use the existing charmap? The latter. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel -- 鈴木 ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Dynalab SJIS cmap (Re: Japenese OTF font with funny encoding)
Hi, On Tue, 01 Jan 2008 11:16:57 -0700 Deron Kazmaier [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: 1) Some Dynalab font has problematic cmap for Shift-JIS. If you have Osaka font on Mac OS X, ftdump will list 3 cmaps: Unicode, Roman, and Shift-JIS. There's no problem. But, some Japanese fonts from Dynalab, ftdump won't list Shift-JIS cmap, in some cases. This is because Dynalab's TTF often includes problematic cmap for Shift-JIS. FreeType2 ignores it. Do you know what the fonts are so I can get one to test? Do those fonts still list a Unicode cmap? I bought DynaFont Type Studio TrueType for Macintosh including 50 japanese TrueType fonts which was released on 2001-Sept. Sorry, this product is already obsolete. http://www.dynacw.co.jp/dynafont/archive/03mac.html All of them have Roman and Shift-JIS cmap only (no Unicode cmap), and FreeType2 recognizes all (!) MacOS Shift-JIS cmaps are broken. Here's the list of PostScript font names and their versions. DFBunChoMin-W2-90pv-RKSJ-H, 20 Aug 2001 Version 2.00 DFBunChoMin-W4-90pv-RKSJ-H, 20 Aug 2001 Version 2.00 DFDanKaiSho-W5-90pv-RKSJ-H, 1 Aug 1999 Version 2.00 DFEnKai-W10-90pv-RKSJ-H, 20 Aug 2001 Version 2.00 DFEnKai-W5-90pv-RKSJ-H, 20 Aug 2001 Version 2.00 DFEnKai-W8-90pv-RKSJ-H, 20 Aug 2001 Version 2.00 DFGyoKaiSho-W5-90pv-RKSJ-H, 1 Aug 1999 Version 2.00 DFGyoSho-W3-90pv-RKSJ-H, 20 Aug 2001 Version 2.00 DFGyoSho-W7-90pv-RKSJ-H, 20 Aug 2001 Version 2.00 DFGothicP-W5-90pv-RKSJ-H,20 Aug 2001 Version 2.00 DFKKaiShoA-W5-90pv-RKSJ-H, 1 Aug 1999 Version 2.00 DFKKaiShoB-W5-90pv-RKSJ-H, 1 Aug 1999 Version 2.00 DFKKaiShoC-W7-90pv-RKSJ-H, 1 Aug 1999 Version 2.00 DFKaiSho-W5-90pv-RKSJ-H, 20 Aug 2001 Version 2.00 DFKaiSho-W9-90pv-RKSJ-H, 20 Aug 2001 Version 2.00 DFMinchoP-W3-90pv-RKSJ-H,20 Aug 2001 Version 2.00 DFKakuPop-W5-90pv-RKSJ-H,20 Aug 2001 Version 2.00 DFKakuPop-W7-90pv-RKSJ-H,20 Aug 2001 Version 2.00 DFKakuPop-W9-90pv-RKSJ-H,20 Aug 2001 Version 2.00 DFKakuTaiHi-W4-90pv-RKSJ-H, 1 Aug 1999 Version 2.00 DFKanTeiRyu-W11-90pv-RKSJ-H, 20 Aug 2001 Version 2.00 DFKanTeiRyu-W6-90pv-RKSJ-H, 20 Aug 2001 Version 2.00 DFGanKaiSho-W5-90pv-RKSJ-H, 20 Aug 2001 Version 2.00 DFGanKaiSho-W7-90pv-RKSJ-H, 20 Aug 2001 Version 2.00 DFGanKaiSho-W9-90pv-RKSJ-H, 20 Aug 2001 Version 2.00 DFKiSouKyu-W5-90pv-RKSJ-H, 1 Aug 1999 Version 2.00 DFHGKaiSho-W3-90pv-RKSJ-H, 1 Aug 1999 Version 2.00 DFGaGei-W6-90pv-RKSJ-H, 1 Aug 1999 Version 2.00 DFPOPMix-W3-90pv-RKSJ-H, 20 Aug 2001 Version 2.00 DFPOPMix-W4-90pv-RKSJ-H, 20 Aug 2001 Version 2.00 DFPOPMix-W5-90pv-RKSJ-H, 20 Aug 2001 Version 2.00 DFLeiGaSo-W5-90pv-RKSJ-H,20 Aug 2001 Version 2.00 DFLeiGaSo-W7-90pv-RKSJ-H,20 Aug 2001 Version 2.00 DFYuGaSo-W3-90pv-RKSJ-H, 20 Aug 2001 Version 2.00 DFYuGaSo-W5-90pv-RKSJ-H, 20 Aug 2001 Version 2.00 DFYuGaSo-W7-90pv-RKSJ-H, 20 Aug 2001 Version 2.00 DFEnEnA-W2-90pv-RKSJ-H, 1 Aug 1999 Version 2.00 DFEnEnA-W4-90pv-RKSJ-H, 1 Aug 1999 Version 2.00 DFEnEnB-W2-90pv-RKSJ-H, 1 Aug 1999 Version 2.00 DFEnEnB-W4-90pv-RKSJ-H, 1 Aug 1999 Version 2.00 DFHorrorA-W3-90pv-RKSJ-H,1 Aug 1999 Version 2.00 DFHorrorA-W5-90pv-RKSJ-H,1 Aug 1999 Version 2.00 DFHorrorB-W3-90pv-RKSJ-H,1 Aug 1999 Version 2.00 DFHorrorB-W5-90pv-RKSJ-H,1 Aug 1999 Version 2.00 DFPenJi-W2-90pv-RKSJ-H, 20 Aug 2001 Version 2.00 DFPenJi-W4-90pv-RKSJ-H, 20 Aug 2001 Version 2.00 DFRenRenA-W2-90pv-RKSJ-H,1 Aug 1999 Version 2.00 DFRenRenA-W4-90pv-RKSJ-H,1 Aug 1999 Version 2.00 DFRenRenB-W2-90pv-RKSJ-H,1 Aug 1999 Version 2.00 DFRenRenB-W4-90pv-RKSJ-H,1 Aug 1999 Version 2.00 Also I've checked fonts bundled to MS Office v.X for Mac. There are 3 Dynalab fonts which has only Roman and Shift-JIS cmap (without Unicode cmap, again). FreeType2 recognizes all Shift-JIS cmap as broken. DFPKaiSho-Md-MP-RKSJ-H, 1 Apr 1997 Version 2.10 DFPMaruGothic-SB-MP-RKSJ-H, 1 Sep 1997 Version 2.00 DFPSNGyoSho-W5-MP-RKSJ-H, 28 Feb 1997 Version 2.10 Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Re: Truetype Collection fonts
[Please stay on the list.] The issue has been resolved on my end, but for your own information ftmac.c (amongst other things) will load various resource based font data and massage the data into a linear representation that resembles the on-disk format of a Windows TrueType/Type1 font. That is (one) of the conversions that goes on and is useful for not only rendering but outputting to PostScript/PDF files. The same we do for reading Type 42 fonts which are converted to a TTF internally more or less. So you are talking not about font conversion between different formats but conversion between different wrapper formats (as described in FreeType's `formats.txt' file) -- is this correct? I still think that the result of a wrapper conversion is internal to FreeType and can't be exposed to the public so that it is useful for other applications. However, I don't mind to provide hooks to that data if it can be done in a sensible way -- can provide patches for that? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
