Thread: [Tuxpaint-devel] Chinese fonts
An award-winning drawing program for children of all ages
Brought to you by:
wkendrick
Menu
▾
▴
tuxpaint-devel
|
From: Ben A. <sy...@sa...> - 2006-10-12 17:04:22
|
I see I'm going to have to fix the Traditional Chinese font, as there are missing characters if I just symlink zh_tw.ttf -> ../../../fonts/truetype/arphic/gbsn00lp.ttf I guess I'll just have to include the extract. Like the Japanese font, this is tailor-made for Tuxpaint and doesn't make sense to package separately. Also, I don't see a Simplified Chinese font in rc5 (zh_cn.ttf). Is this deliberate, or an oversight? Ben |
|
From: Ben A. <sy...@sa...> - 2006-10-12 17:20:01
|
Ben Armstrong wrote: > I see I'm going to have to fix the Traditional Chinese font, as there > are missing characters if I just symlink zh_tw.ttf -> > ../../../fonts/truetype/arphic/gbsn00lp.ttf > > I guess I'll just have to include the extract. Like the Japanese font, > this is tailor-made for Tuxpaint and doesn't make sense to package > separately. > > Also, I don't see a Simplified Chinese font in rc5 (zh_cn.ttf). Is this > deliberate, or an oversight? > > Ah, and no Korean ships in rc5, either. The Debian package has: lrwxrwxrwx 1 root root 41 Oct 12 14:04 /usr/share/tuxpaint/fonts/locale/ko.ttf -> ../../../fonts/truetype/baekmuk/gulim.ttf Is this still correct? Maybe zh_cn was supposed to symlink to arphic/gbsn00lp.ttf? (I used to have zh.ttf symlinked to this font.) Ben |
|
From: Bill K. <nb...@so...> - 2006-10-12 17:28:27
|
On Thu, Oct 12, 2006 at 02:14:57PM -0300, Ben Armstrong wrote: > Ah, and no Korean ships in rc5, either. Correct, they are too large, so are (as in the past), available separately from my website on the Fonts download page. :) Dunno about what symlinks were used in the past on Debian. I tend to not use the packages of things I'm developing ;) -bill! |
|
From: Ben A. <sy...@sa...> - 2006-10-13 12:35:56
|
Whoops. OK, I now include zh_tw.ttf in tuxpaint-data, but when I start tuxpaint --lang traditional-chinese, all that shows is the top row of pixels of each character. Simplified Chinese is fine, though (which is the one that I have symlinked: zh_cn.ttf -> ../../../fonts/truetype/arphic/gbsn00lp.ttf). Does zh_tw.ttf need to be regenerated for the current version of tuxpaint? Ben |
|
From: Bill K. <nb...@so...> - 2006-10-13 20:01:00
|
On Fri, Oct 13, 2006 at 09:35:31AM -0300, Ben Armstrong wrote: > Whoops. OK, I now include zh_tw.ttf in tuxpaint-data, but when I start > tuxpaint --lang traditional-chinese, all that shows is the top row of > pixels of each character. Simplified Chinese is fine, though (which is > the one that I have symlinked: zh_cn.ttf -> > ../../../fonts/truetype/arphic/gbsn00lp.ttf). > > Does zh_tw.ttf need to be regenerated for the current version of tuxpaint? What version of SDL_ttf and FreeType do you have? I've switched over to the (K)ubuntu side, recently, so it may be different from what you have. Like I said, Chinese fonts are screwed up in rc4 for Windows, when I tested it in WinXP, but worked great under Linux. John - what version of SDL_ttf and FreeType are you including in the Win32 build? Thx! -bill! |
|
From: John P. <jo...@jo...> - 2006-10-14 00:44:55
|
On Fri, Oct 13, 2006 at 01:00:56PM -0700, Bill Kendrick wrote: > On Fri, Oct 13, 2006 at 09:35:31AM -0300, Ben Armstrong wrote: > > Whoops. OK, I now include zh_tw.ttf in tuxpaint-data, but when I start > > tuxpaint --lang traditional-chinese, all that shows is the top row of > > pixels of each character. Simplified Chinese is fine, though (which is > > the one that I have symlinked: zh_cn.ttf -> > > ../../../fonts/truetype/arphic/gbsn00lp.ttf). > > > > Does zh_tw.ttf need to be regenerated for the current version of tuxpaint? > > What version of SDL_ttf and FreeType do you have? I've switched over > to the (K)ubuntu side, recently, so it may be different from what you have. > > Like I said, Chinese fonts are screwed up in rc4 for Windows, when I tested > it in WinXP, but worked great under Linux. > > John - what version of SDL_ttf and FreeType are you including in the Win32 > build? rc1: freetype-2.1.9 SDL_ttf-2.0.8 rc2 and rc4: freetype-2.1.10 SDL_ttf-2.0.8 cheers, John. |
|
From: John P. <jo...@jo...> - 2006-10-14 01:13:26
|
On Sat, Oct 14, 2006 at 01:44:52AM +0100, John Popplewell wrote: > > Like I said, Chinese fonts are screwed up in rc4 for Windows, when I tested > > it in WinXP, but worked great under Linux. > > > > John - what version of SDL_ttf and FreeType are you including in the Win32 > > build? > rc1: > freetype-2.1.9 > SDL_ttf-2.0.8 > > rc2 and rc4: > freetype-2.1.10 > SDL_ttf-2.0.8 Hi, got a chance to try these out - all broken. I dropped in an old SDL_ttf from 0.9.15 (which I think was freetype-2.1.9 and SDL_ttf-2.0.7) and chinese worked fine so it looks like it's an SDL_ttf/Freetype problem. Will try and look at this later, cheers, John. |
|
From: Ben A. <sy...@sa...> - 2006-10-14 01:55:04
|
John Popplewell wrote: > got a chance to try these out - all broken. I dropped in an old SDL_ttf > from 0.9.15 (which I think was freetype-2.1.9 and SDL_ttf-2.0.7) and > chinese worked fine so it looks like it's an SDL_ttf/Freetype problem. > > Will try and look at this later, > I appreciate this. I cannot, of course, make the SDL packages revert to an earlier version in Debian. So for Chinese to work in Debian, we have to move forward starting with what's there now. Ben |
|
From: John P. <jo...@jo...> - 2006-10-14 15:12:22
|
On Fri, Oct 13, 2006 at 10:54:55PM -0300, Ben Armstrong wrote: > John Popplewell wrote: > > got a chance to try these out - all broken. I dropped in an old SDL_ttf > > from 0.9.15 (which I think was freetype-2.1.9 and SDL_ttf-2.0.7) and > > chinese worked fine so it looks like it's an SDL_ttf/Freetype problem. > > > > Will try and look at this later, > > > > I appreciate this. I cannot, of course, make the SDL packages revert to > an earlier version in Debian. So for Chinese to work in Debian, we have > to move forward starting with what's there now. Sure, I understand. For what it's worth, I've built similar versions to the ones in Debian: freetype-2.2.1 SDL_ttf-2.0.7 SDL_ttf-2.0.8 with this patch (so that SDL_ttf builds): http://www.freetype.org/freetype2/patches/SDL_ttf-2.0.7-noftinternals.patch and the problem with SDL_ttf-2.0.8 and the small zh_tw.ttf font remains. If I use the original zh_tw.ttf (13MB) it works fine. At least it's probably not a freetype problem :-) regards, John. |
|
From: Ben A. <sy...@sa...> - 2006-10-19 18:22:15
|
Ben Armstrong wrote: > But the description of the ttf-arphic-uming package in Debian says: > > It has been extended from the original "AR PL Mingti2L Big5" and > "AR PL SungtiL GB" fonts with additional glyphs now covering > ISO8859-1,2,3,4,9,10,13,14,15, BIG5, GB2312-80 and HKSCS 2004. > It also includes Bopomofo Extensions for Hakka and Minnan according > to the Unicode 4.1 standard. MBE variants of those glyphs are also > included. > I asked more about this today on #dot @ irc.debian.org. AndrewLee tells me ArneGoetje is both the Debian maintainer and upstream for uming, and is quite active maintaining his package. I think this is a strong argument for switching Tuxpaint to use uming and not worry about getting wangfonts packaged for Debian. Andrew encouraged me to contact Arne at ar...@li... if we discover any problems with substituting uming for wangfonts, and Arne will quickly provide us with a fix. The only issue is this one: http://lists.debian.org/debian-chinese-big5/2005/02/msg00019.html In this message, Ming Hua states: "Arphic license is NOT GPL compatible". This causes problems for including the font in Tuxpaint upstream, but not for Debian because I'm not including the font in the GPL-licensed Tuxpaint. In theory, Tuxpaint upstream could solve the problem the same way, by distributing tuxpaint-font-zh_tw as a separate package under the Arphic license, though this would be cumbersome, and may not therefore be worth it. If Debian does continue to diverge from Tuxpaint upstream because we use a different font for zh_tw, I worry about possible support issues in future due to this difference. But we'll cross that bridge when we get to it. Ben |
|
From: <so...@so...> - 2006-10-20 15:10:26
|
On Thu, Oct 19, 2006 at 03:21:59PM -0300, Ben Armstrong wrote: > Ben Armstrong wrote: > > But the description of the ttf-arphic-uming package in Debian says: > > > > It has been extended from the original "AR PL Mingti2L Big5" and > > "AR PL SungtiL GB" fonts with additional glyphs now covering > > ISO8859-1,2,3,4,9,10,13,14,15, BIG5, GB2312-80 and HKSCS 2004. > > It also includes Bopomofo Extensions for Hakka and Minnan according > > to the Unicode 4.1 standard. MBE variants of those glyphs are also > > included. The uming includes Bopomofo it's just meaning there includes 37 symbols, but chinese character and bopomofo symbols combined with characters in wangfont subset, the symbols can to represent the sounds of Mandarin and in conjunction with that character. FYR: http://www.omniglot.com/writing/mandarin.htm#bopomofo http://pinyin.info/romanization/bopomofo/ > > > > I asked more about this today on #dot @ irc.debian.org. AndrewLee tells > me ArneGoetje is both the Debian maintainer and upstream for uming, and > is quite active maintaining his package. I think this is a strong > argument for switching Tuxpaint to use uming and not worry about getting > wangfonts packaged for Debian. Andrew encouraged me to contact Arne at > ar...@li... if we discover any problems with substituting uming > for wangfonts, and Arne will quickly provide us with a fix. > > The only issue is this one: > > http://lists.debian.org/debian-chinese-big5/2005/02/msg00019.html > > In this message, Ming Hua states: "Arphic license is NOT GPL > compatible". This causes problems for including the font in Tuxpaint > upstream, but not for Debian because I'm not including the font in the > GPL-licensed Tuxpaint. In theory, Tuxpaint upstream could solve the > problem the same way, by distributing tuxpaint-font-zh_tw as a separate > package under the Arphic license, though this would be cumbersome, and > may not therefore be worth it. > > If Debian does continue to diverge from Tuxpaint upstream because we use > a different font for zh_tw, I worry about possible support issues in > future due to this difference. But we'll cross that bridge when we get > to it. |
|
From: Ben A. <sy...@sa...> - 2006-10-20 17:30:55
|
so...@so... wrote: > The uming includes Bopomofo it's just meaning there includes 37 symbols, > but chinese character and bopomofo symbols combined with characters in > wangfont subset, the symbols can to represent the sounds of Mandarin > and in conjunction with that character. > > FYR: > http://www.omniglot.com/writing/mandarin.htm#bopomofo > http://pinyin.info/romanization/bopomofo/ > I see now. Thanks, Song. That's very useful info to have. But after further discussion with AndrewLee on #dot, I have learned that Arphic Inc. wants to sue the Wangfonts author, which brings the GPL status of the font into question. This is why it hasn't yet been packaged for Debian. However, we don't yet know the outcome. Do you have any info about this? See: http://www.arphic.com.tw/tw/service/talk/cont.asp?id=493&toppage=4 Ben |
|
From: Ben A. <sy...@sa...> - 2006-10-16 14:37:27
|
Song Huang wrote: > Dears, > > I fixed this problum of zh_tw.ttf, I don't known what differ from SDL, > but I change the fontforge script to keep all orig font's properties. > > pls kindly to confirm the fixed, and put the zh_tw.ttf into tuxpaint 0.9.16 > release, > thanks~!! > Thanks, Song. This is good to have in Tuxpaint upstream. But for the Debian package, I think it is best to keep on using ttf-arphic-uming as I do now. I am sure Traditional Chinese Debian users will already have this package installed, so there is no need for me to use the subset of the wangfonts font. If we decide that the wangfonts font is superior for some reason, then it should be packaged for Debian, and then I will switch. Regards, Ben |
|
From: Bill K. <nb...@so...> - 2006-10-16 16:59:44
|
On Mon, Oct 16, 2006 at 11:37:04AM -0300, Ben Armstrong wrote: > Thanks, Song. This is good to have in Tuxpaint upstream. But for the > Debian package, I think it is best to keep on using ttf-arphic-uming as > I do now. I am sure Traditional Chinese Debian users will already have > this package installed, so there is no need for me to use the subset of > the wangfonts font. Agreed! however! Ben, would you mind experimenting to see if Song's changes to the TTF actually helps? :) Just so we have a datapoint. ;) Thx -bill! |
|
From: <so...@so...> - 2006-10-19 14:23:28
|
On Mon, Oct 16, 2006 at 11:37:04AM -0300, Ben Armstrong wrote: > > Thanks, Song. This is good to have in Tuxpaint upstream. But for the > Debian package, I think it is best to keep on using ttf-arphic-uming as > I do now. I am sure Traditional Chinese Debian users will already have > this package installed, so there is no need for me to use the subset of > the wangfonts font. If we decide that the wangfonts font is superior > for some reason, then it should be packaged for Debian, and then I will > switch. Dear Ben, I prefer use the wangfont subset, because there have Bopomofo symbols in the wangfont's right side. Bopomofo, a semi-syllabic script used in Taiwan mainly to help teach children to read. Best regards, song. |
|
From: Ben A. <sy...@sa...> - 2006-10-16 17:15:44
|
Bill Kendrick wrote: > however! Ben, would you mind experimenting to see if Song's changes > to the TTF actually helps? :) Just so we have a datapoint. ;) > Sure. I'll try to fit it in. Actually preparing the release (or at least the next release candidate) will take precedence. Ben |
|
From: Ben A. <sy...@sa...> - 2006-10-19 14:45:07
|
so...@so... wrote: > I prefer use the wangfont subset, because there have Bopomofo symbols in > the wangfont's right side. Bopomofo, a semi-syllabic script used in Taiwan > mainly to help teach children to read. > But the description of the ttf-arphic-uming package in Debian says: It has been extended from the original "AR PL Mingti2L Big5" and "AR PL SungtiL GB" fonts with additional glyphs now covering ISO8859-1,2,3,4,9,10,13,14,15, BIG5, GB2312-80 and HKSCS 2004. It also includes Bopomofo Extensions for Hakka and Minnan according to the Unicode 4.1 standard. MBE variants of those glyphs are also included. How can I tell if this works properly with my Tuxpaint package for Debian? Ben |
|
From: Ben A. <sy...@sa...> - 2006-10-12 18:16:10
|
Bill Kendrick wrote: > On Thu, Oct 12, 2006 at 02:14:57PM -0300, Ben Armstrong wrote: > > Correct, they are too large, so are (as in the past), available > separately from my website on the Fonts download page. :) > > Dunno about what symlinks were used in the past on Debian. > I tend to not use the packages of things I'm developing ;) > Understood. OK. Since everything in fonts is confirmed to be GPL-compatible, and some fonts are so customized they're not useful anywhere but in Tuxpaint, I've changed my policy. I'm now including all fonts provided by upstream that I don't symlink to a font already available in Debian from a separate package. Please see: deb http://people.debian.org/~synrg/tuxpaint/sid/ ./ However, I still want to see each font that's included in Tuxpaint that is generally useful to other packages packaged separately. But that can be pursued in parallel with this release. So, in my rc5 package I now have: lrwxrwxrwx 1 root root 48 Oct 12 14:26 ar.ttf -> ../../../fonts/truetype/ttf-arabeyes/ae_Nice.ttf -rw-r--r-- 1 root root 28580 Oct 12 14:24 bo.ttf lrwxrwxrwx 1 root root 47 Oct 12 14:26 el.ttf -> ../../../fonts/truetype/thryomanes/thryrg__.ttf lrwxrwxrwx 1 root root 55 Oct 12 14:26 gu.ttf -> ../../../fonts/truetype/ttf-gujarati-fonts/lohit_gu.ttf -rw-r--r-- 1 root root 25104 Oct 12 14:24 he.ttf -rw-r--r-- 1 root root 134372 Oct 12 14:24 hi.ttf -rw-r--r-- 1 root root 100236 Oct 12 14:24 ja.ttf lrwxrwxrwx 1 root root 45 Oct 12 14:26 ka.ttf -> ../../../fonts/truetype/freefont/FreeSans.ttf lrwxrwxrwx 1 root root 41 Oct 12 14:26 ko.ttf -> ../../../fonts/truetype/baekmuk/gulim.ttf lrwxrwxrwx 1 root root 54 Oct 12 14:26 ta.ttf -> ../../../fonts/truetype/ttf-tamil-fonts/TSCu_Comic.ttf lrwxrwxrwx 1 root root 44 Oct 12 14:26 th.ttf -> ../../../fonts/truetype/thai/Garuda-Bold.ttf -rw-r--r-- 1 root root 301056 Oct 12 14:24 vi.ttf lrwxrwxrwx 1 root root 43 Oct 12 14:26 zh_cn.ttf -> ../../../fonts/truetype/arphic/gbsn00lp.ttf -rw-r--r-- 1 root root 692564 Oct 12 14:24 zh_tw.ttf bo.ttf has "issues" (non-Unicode, locale not present on Debian) he.ttf waiting on the Debian Hebrew group to package hi.ttf waiting on the Debian Indian group to package ja.ttf custom font for Tuxpaint vi.ttf don't know who to ask about packaging this; I'll ask around zh_tw.ttf custom font for Tuxpaint Ben |
|
From: Ben A. <sy...@sa...> - 2006-10-13 23:27:42
|
Bill Kendrick wrote: > On Fri, Oct 13, 2006 at 09:35:31AM -0300, Ben Armstrong wrote: > >> Whoops. OK, I now include zh_tw.ttf in tuxpaint-data, but when I start >> tuxpaint --lang traditional-chinese, all that shows is the top row of >> pixels of each character. Simplified Chinese is fine, though (which is >> the one that I have symlinked: zh_cn.ttf -> >> ../../../fonts/truetype/arphic/gbsn00lp.ttf). >> >> Does zh_tw.ttf need to be regenerated for the current version of tuxpaint? >> > > What version of SDL_ttf and FreeType do you have? Ah. My system was a bit out of date. I had libsdl 1.2.11-3 and am now at 1.2.11-4. I also had sdl-ttf2.0 2.8.0-2 and am now at 2.8.0-3. However, even after the upgrade, Traditional Chinese fonts are still mangled. > I've switched over > to the (K)ubuntu side, recently, so it may be different from what you have. > > Like I said, Chinese fonts are screwed up in rc4 for Windows, when I tested > it in WinXP, but worked great under Linux. > Ugh. OK. What versions of SDL/ttf do you use on Ubuntu, then? Ben |
|
From: Bill K. <nb...@so...> - 2006-10-13 23:35:17
|
On Fri, Oct 13, 2006 at 08:27:31PM -0300, Ben Armstrong wrote: > Ugh. OK. What versions of SDL/ttf do you use on Ubuntu, then? >From an earlier email I sent: FYI, on Kubuntu I have: SDL 1.2.9 SDL_ttf 2.0.7 SDL_image 1.2.4 Freetype6 2.1.10 :) -bill! |
|
From: Ben A. <sy...@sa...> - 2006-10-13 23:39:23
|
Bill Kendrick wrote: > On Fri, Oct 13, 2006 at 08:27:31PM -0300, Ben Armstrong wrote: > >> Ugh. OK. What versions of SDL/ttf do you use on Ubuntu, then? >> > > >From an earlier email I sent: > > FYI, on Kubuntu I have: > > SDL 1.2.9 > SDL_ttf 2.0.7 > Ah, right, then I lied ... it's 2.0.8, not 2.8.0 ... (that'll teach me to not cut-and-paste :) > SDL_image 1.2.4 > Freetype6 2.1.10 > > My freetype is now 2.2.1-5 and my SDL_image is 1.2.5. Ben |
|
From: Bill K. <nb...@so...> - 2006-10-14 05:46:47
|
On Sat, Oct 14, 2006 at 02:13:21AM +0100, John Popplewell wrote: > > got a chance to try these out - all broken. I dropped in an old SDL_ttf > from 0.9.15 (which I think was freetype-2.1.9 and SDL_ttf-2.0.7) and > chinese worked fine so it looks like it's an SDL_ttf/Freetype problem. YAY! >:^X -bill! |
|
From: John P. <jo...@jo...> - 2006-10-16 22:15:16
|
On Fri, Oct 13, 2006 at 10:46:43PM -0700, Bill Kendrick wrote: > On Sat, Oct 14, 2006 at 02:13:21AM +0100, John Popplewell wrote: > > > > got a chance to try these out - all broken. I dropped in an old SDL_ttf > > from 0.9.15 (which I think was freetype-2.1.9 and SDL_ttf-2.0.7) and > > chinese worked fine so it looks like it's an SDL_ttf/Freetype problem. > > YAY! > Just for the record, I got round to looking at the code for SDL_ttf and this: http://www.libsdl.org/cgi/viewvc.cgi?view=rev&revision=2304 causes the change in behavior we are seeing between 2.0.7 and 2.0.8 cheers, John. |
|
From: John P. <jo...@jo...> - 2006-10-14 15:29:03
|
On Sat, Oct 14, 2006 at 04:12:19PM +0100, John Popplewell wrote: > > <snip!> > > I appreciate this. I cannot, of course, make the SDL packages revert to > > an earlier version in Debian. So for Chinese to work in Debian, we have > > to move forward starting with what's there now. > Sure, I understand. > > For what it's worth, I've built similar versions to the ones in Debian: > > freetype-2.2.1 > SDL_ttf-2.0.7 > SDL_ttf-2.0.8 > with this patch (so that SDL_ttf builds): > http://www.freetype.org/freetype2/patches/SDL_ttf-2.0.7-noftinternals.patch > > and the problem with SDL_ttf-2.0.8 and the small zh_tw.ttf font remains. > If I use the original zh_tw.ttf (13MB) it works fine. > > At least it's probably not a freetype problem :-) > An additional data-point. If I use the 'showfont' test program that comes with SDL_ttf-2.0.8: $ showfont c:/windows/fonts/arial.ttf 32 "Hello world." Font is generally 36 big, and string is 36 big [displays correctly] $ showfont ../tuxpaint/fonts/locale/zh_tw.ttf 32 "Hello world." Font is generally 1 big, and string is 1 big [displays the top row of pixels only] regards, John. |
|
From: Bill K. <nb...@so...> - 2006-10-14 18:30:07
|
On Sat, Oct 14, 2006 at 04:28:57PM +0100, John Popplewell wrote: > > and the problem with SDL_ttf-2.0.8 and the small zh_tw.ttf font remains. > > If I use the original zh_tw.ttf (13MB) it works fine. So for now, it looks like on Debian Ben will simply recommend an existing Traditional Chinese TTF, and not include the subset one that I'm releasing with the source. John, you can go ahead and not include the subset Traditional Chinese TTF, since it doesn't work, and ALSO not include the original TTF, since it's something like 15MB. People who need a font can simply download it from me separately, like they had to do in past versions of Tux Paint. (See: http://www.tuxpaint.org/download/fonts/ ) -- -bill! bi...@ne... http://www.newbreedsoftware.com/ |
Thanks for helping keep SourceForge clean.
X