tuxpaint-devel — General discussion list for Tux Paint developers

Re: [Tuxpaint-devel] Chinese fonts

[Ben A. <sy...@sa...>]

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

Re: [Tuxpaint-devel] Chinese fonts

[Song H. <So...@so...>]

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~!!

Best regards,
song.


----- Original Message ----- 
From: "John Popplewell" <jo...@jo...>
To: "Discussion list for Tux Paint developers"
<tux...@li...>
Sent: Saturday, October 14, 2006 11:28 PM
Subject: Re: [Tuxpaint-devel] Chinese fonts


> 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.
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>

Re: [Tuxpaint-devel] unsubscribe

[Albert C. <aca...@gm...>]

On 10/13/06, Bill Kendrick <nb...@so...> wrote:
>
> On Fri, Oct 13, 2006 at 01:03:54PM -0700, Bill Kendrick wrote:
> > Hi - you actually sent this to the mailing list (so, about 70 people,
> > only one of which could do anything for you ;^) ... hint: he's writing
> > to you now)
>
> Oops!  And Mutt confused me, making me think I was replying _only_ to
> them.  Sorry for the noise!

This is one reason why many mailing lists are configured to have
replies go to the sender. The "reply to all" or "group reply" feature
is used to send mail to the list. The other reason is that replying
to the sender becomes easy; with tuxpaint-devel I have to do a
group reply and then manually edit the list of recipients.

See the linux-kernel mailing list for a popular example of a
mailing list that doesn't force a reply to the list.

Mail to you seems to be even worse. Group reply seems to send
two copies to the list and none directly to you.

Re: [Tuxpaint-devel] Tux Paint 0.9.16 build for Mac OS X?

[Bill K. <nb...@so...>]

On Sun, Oct 15, 2006 at 07:01:54PM -0700, Bill Kendrick wrote:
> One more issue.

Ok, one more, then I'm done.  ANy reason you include only the english
plain-text (TXT) version of the documentation, and not the HTML docs
(either instead of, or as well as the plain-text)?

Thanks!

-bill!

Re: [Tuxpaint-devel] Tux Paint 0.9.16 build for Mac OS X?

[Bill K. <nb...@so...>]

On Sun, Oct 15, 2006 at 06:55:04PM -0700, Bill Kendrick wrote:
> On Sun, Oct 15, 2006 at 06:24:50PM -0700, Bill Kendrick wrote:
> > 
> > Awesome, thanks! I've put them on my FTP site here:
> > 
> >   ftp://ftp.tuxpaint.org/unix/x/tuxpaint/testbuilds/macosx/
> > 
> > And will test it on my PPC Mac Mini momentarily! ;)
> 

One more issue.  It seems the locale is not being kept track of inside
Tux Paint.  If I change the locale to Catalan in Tux Paint Config,
the UI text is all Catalan, which is correct.

However, none of the stamps play their descriptive (spoken) sounds,
when I click them.

e.g., when I click the Rooster stamp, I do not hear "rooster_desc_ca.ogg"
play after "rooster.ogg" plays.

Additionally, when I click the number stamps (i.e., "0.png" thru "9.png"),
I get the english sounds (e.g., "0_en.png"), rather than the Catalan
ones (e.g., "0_ca.png").

Any ideas?  (I'll need to double-check this works right in Win32.
It works fine in Linux.)

Thx,

-bill!

Re: [Tuxpaint-devel] Tux Paint 0.9.16 build for Mac OS X?

[Bill K. <nb...@so...>]

On Sun, Oct 15, 2006 at 06:24:50PM -0700, Bill Kendrick wrote:
> 
> Awesome, thanks! I've put them on my FTP site here:
> 
>   ftp://ftp.tuxpaint.org/unix/x/tuxpaint/testbuilds/macosx/
> 
> And will test it on my PPC Mac Mini momentarily! ;)

Testing now.  First off, the splash screen within Tux Paint still
says 0.9.15 from 2005.11.25.  I see your About screen has the right
version (although the build seems to be from a few days in the future ;^) )

Secondly, Chinese (both), Japanese and Korean are ALL showing up as squares.
Can you perhaps try using an older SDL_ttf, like John is on Win32, and
see if these locales render properly for you?

I tried playing with locale settings in the Mac's System Preferences
dialog, and some worked, some didn't seem to do anything, except pick the
next option down the list (e.g., if I moved Portuguese to the top of
the list in the Mac's settings, Tux Paint would end up using the next
language down... other languages worked properly, e.g., Hebrew)

Thanks!

-- 
-bill!
bi...@ne...
http://www.newbreedsoftware.com/

Re: [Tuxpaint-devel] Tux Paint 0.9.16 build for Mac OS X?

[Bill K. <nb...@so...>]

On Sun, Oct 15, 2006 at 07:20:15PM -0600, Martin Fuhrer wrote:
> I've posted the Mac OS X Tux Paint 0.9.16rc5 builds here:
> 
> www.cpsc.ucalgary.ca/~fuhrer/temp/tuxpaint-0.9.16rc5-macosx.dmg
> www.cpsc.ucalgary.ca/~fuhrer/temp/tuxpaintstamps-2006.10.12-macosx.dmg
> 
> They are compiled as universal binary, though because I only have a  
> PowerPC Mac, it would be nice if someone with an Intel-based Mac  
> could test these and make sure they run fine.

Awesome, thanks! I've put them on my FTP site here:

  ftp://ftp.tuxpaint.org/unix/x/tuxpaint/testbuilds/macosx/

And will test it on my PPC Mac Mini momentarily! ;)

-bill!

Re: [Tuxpaint-devel] Tux Paint 0.9.16 build for Mac OS X?

[Martin F. <mf...@gm...>]

I've posted the Mac OS X Tux Paint 0.9.16rc5 builds here:

www.cpsc.ucalgary.ca/~fuhrer/temp/tuxpaint-0.9.16rc5-macosx.dmg
www.cpsc.ucalgary.ca/~fuhrer/temp/tuxpaintstamps-2006.10.12-macosx.dmg

They are compiled as universal binary, though because I only have a  
PowerPC Mac, it would be nice if someone with an Intel-based Mac  
could test these and make sure they run fine.

The eraser ghosted lines problem still exists.  I've noticed that  
this problem only exists in windowed mode; if Tux Paint runs  
fullscreen, the problem is gone...  Could this be an SDL problem?
>
> How much bigger will a Universal Binary be, compared to a PPC-only
> and an x86-only binary?

For the Tux Paint application bundle (binaries + resources):

Tux Paint 0.9.16 PPC:  13 MB
Tux Paint 0.9.16 Universal: 13.3 MB

So a fairly negligible size difference.  Mind you, the PPC  
application bundle contains the universal binary SDL frameworks, so  
these will definitely add some disk space in terms of x86 code.  The  
0.3 MB size increase in the universal is due to the x86 Tux Paint  
code, plus the x86 code linked in from the static libraries libpng.a,  
libiconv.a, and libintl.a.

> Also, any chance of Tux Paint 0.9.16 running on OS X 10.2.8?
> Last I heard (last year after 0.9.15 was released), many people were
> still using that version on their Macs.  (Presumably, mostly  
> schools w/
> tight budgets.)
>
> So... it's pretty important to me that we support it.

I have read recently that it actually is possible to create a  
universal binary app that supports OS X 10.2.8, but I'm not certain  
as to how this is done.  I might have to peruse some developer forums  
for more information about this - but I have a feeling there are some  
tricks and caveats involved (Apple's stance is that universal  
binaries require OS X 10.3.9 or newer)...  It is definitely possible  
to build a PowerPC-only app that supports OS X 10.2.8 and up (this  
would be distributed alongside the universal binary version of Tux  
Paint), but I ran into some odd compile errors when I tried this  
earlier in the year.  I can revisit this, but the next few weeks are  
busy for me, so it won't be for a while (I also have to visit some of  
the longstanding Mac OS X bug reports for Tux Paint).

Martin

Re: [Tuxpaint-devel] Tux Paint 0.9.16rc6 released

[Bill K. <nb...@so...>]

On Sun, Oct 15, 2006 at 04:49:04PM -0700, Bill Kendrick wrote:
> 
> The source to Tux Paint 0.9.16rc6, Tux Paint Config 0.0.7rc6 and
> Tux Paint Stamps 2006.10.15 are now available on my FTP site:
> 
>   ftp://ftp.tuxpaint.org/unix/x/tuxpaint/testbuilds/source/

John has already built Win32 versions of this, available from here:

  ftp://ftp.tuxpaint.org/unix/x/tuxpaint/testbuilds/win32/

Thx!

-bill!

[Tuxpaint-devel] Press Contants for Europe, Africa, Oceania?

[Bill K. <nb...@so...>]

Would anyone like to be listed as a Press Contact for Tux Paint in
Europe, Africa or 'Oceania'?

(Ref: http://www.tuxpaint.org/latest/tuxpaint-0.9.16-press-release-en.php3 )

-- 
-bill!
bi...@ne...
http://www.newbreedsoftware.com/

[Tuxpaint-devel] Tux Paint 0.9.16rc6 released

[Bill K. <nb...@so...>]

The source to Tux Paint 0.9.16rc6, Tux Paint Config 0.0.7rc6 and
Tux Paint Stamps 2006.10.15 are now available on my FTP site:

  ftp://ftp.tuxpaint.org/unix/x/tuxpaint/testbuilds/source/

Chances since 0.9.16rc5 include:

  * Added missing Gujarati font
  * German stamp updates
  * Turkish UI & stamp updates
  * Spanish UI updates
  * Mac OS X updates from Martin Fuhrer
  * fonts/locale/zh_tw_docs/tuxpaintsubset.pe update (no TTF change, though!)
  * Locale vs. english text display fix (or was that already in rc5?)


I'm inclined (in fact, eager!) to get a final 0.9.16 release out soon.

What remaining issues are people concerned about?  Thx!

-- 
-bill!
bi...@ne...
http://www.newbreedsoftware.com/

Re: [Tuxpaint-devel] Tux Paint 0.9.16 build for Mac OS X?

[Bill K. <nb...@so...>]

On Sun, Oct 15, 2006 at 05:25:21PM -0600, Martin Fuhrer wrote:
> 
> I have universal binaries working (I'll get them posted tonight for  
> public testing).

BTW, I've just put 0.9.16rc6 (see an upcoming post) on my FTP site,
which incorporates all of the OSX changes you made to CVS since rc5. Thx!


<snip>
> In the TuxPaint XCode project, I turned on the Intel and PPC options  
> and selected the Mac OS X 10.4u SDK (see the Read Me in the XCode  
> project), and compiled the app.

How much bigger will a Universal Binary be, compared to a PPC-only
and an x86-only binary?

Also, any chance of Tux Paint 0.9.16 running on OS X 10.2.8?
Last I heard (last year after 0.9.15 was released), many people were
still using that version on their Macs.  (Presumably, mostly schools w/
tight budgets.)

So... it's pretty important to me that we support it.
(Hell, I still want to see Tux Paint on OS 9 some day, but... :) )

Thx!

-- 
-bill!
bi...@ne...
http://www.newbreedsoftware.com/

Re: [Tuxpaint-devel] Tux Paint 0.9.16 build for Mac OS X?

[Martin F. <mf...@gm...>]

On 15-Oct-06, at 4:33 PM, Albert Cahalan wrote:

>>> Would you be able to build a binary that runs native on Intel, too?
>>
>> Yes, I will look into making a Universal binary (PPC/Intel).  The SDL
>> libraries are already universal, so the frameworks just need to be
>> included in the TuxPaint application bundle.  I'll have to compile
>> libiconv, libintl, and libpng as universal libraries, and link those
>> in - provided this goes alright, we should be in business.  We have
>> to keep in mind that universal binary apps need to be compiled with
>> gcc 4, and gcc 4 compiled apps typically require Mac OS X 10.3.9 or
>> later to run (so a universal binary that also runs on 10.2.8 is most
>> likely not possible).
>
> I think you can do this:
>
> 1. compile the ppc version with the old tools
> 2. compile the x86 version with the new tools
> 3. use the new tools (lipo?) to join them into a universal binary
>
> If you do end up with two separate installs, there isn't much
> point in doing a universal binary.

I have universal binaries working (I'll get them posted tonight for  
public testing).  In short, to compile universal binaries of  
libraries with configure scripts, I did the following:

 > setenv CFLAGS '-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc  
-arch i386''
 > setenv CXXFLAGS '-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch  
ppc -arch i386'
 > setenv LDFLAGS '-Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk - 
arch ppc -arch i386'
 > ./configure
 > make

Both ppc and x86 object files and libraries are generated and  
"lipoed" together into universal libraries. To check the architecture  
of a library file, I run:

 > lipo -info libiconv.a
Architectures in the fat file: libiconv.a are: i386 ppc

For libraries without configure scripts (eg. libpng), I first ran  
make to build the ppc library, and copied it into a "ppc" directory.   
I then manually edited the makefiles to include the "-arch i386"  
compiler flag, ran make to build the x86 library, and copied it into  
an "i386" directory.  Finally, I ran lipo as follows:

 > lipo -create i386/libpng.a ppc/libpng.a -output libpng.a

In the TuxPaint XCode project, I turned on the Intel and PPC options  
and selected the Mac OS X 10.4u SDK (see the Read Me in the XCode  
project), and compiled the app.

Martin

Re: [Tuxpaint-devel] Managing large # of stamps

[Albert C. <aca...@gm...>]

On 10/15/06, Bill Kendrick <nb...@so...> wrote:
> On Sun, Oct 15, 2006 at 05:10:50PM -0400, Albert Cahalan wrote:
> >
> > Like this: the "tuxpaint" is an empty package which depends on
> > a "tuxpaint-bin" package (containing the executable) and on every
> > stamp package. If you install "tuxpaint" you get absolutely everything.
>
> Not a bad idea.  How do other large packages (say, OpenOffice.org,
> or some clipart collection) manage this, though?

I got the idea from Debian's GNOME and X11 packages.

I installed GNOME. I got everything GNOME-related, including
stuff that I personally find to be useless junk. Later, after I had
everything set up and knew what I liked, I deleted the main
package (leaving the stuff it had installed) and then deleted the
unwanted packages. The big package got me started though,
with nothing missing.

The same for X11. I got all the stuff I might need, plus lots of
drivers for hardware I don't have and some other stuff I don't
need. That's OK. The important thing is that nothing was missing.
Later, I removed the main package and the excess drivers.

I think this is a great way to do things. If I didn't know what
was going on, I'd still have what I want. If I really want to save
a bit of disk space, it is still possible.

Re: [Tuxpaint-devel] Tux Paint 0.9.16 build for Mac OS X?

[Albert C. <aca...@gm...>]

> > Would you be able to build a binary that runs native on Intel, too?
>
> Yes, I will look into making a Universal binary (PPC/Intel).  The SDL
> libraries are already universal, so the frameworks just need to be
> included in the TuxPaint application bundle.  I'll have to compile
> libiconv, libintl, and libpng as universal libraries, and link those
> in - provided this goes alright, we should be in business.  We have
> to keep in mind that universal binary apps need to be compiled with
> gcc 4, and gcc 4 compiled apps typically require Mac OS X 10.3.9 or
> later to run (so a universal binary that also runs on 10.2.8 is most
> likely not possible).

I think you can do this:

1. compile the ppc version with the old tools
2. compile the x86 version with the new tools
3. use the new tools (lipo?) to join them into a universal binary

If you do end up with two separate installs, there isn't much
point in doing a universal binary.

Re: [Tuxpaint-devel] Managing large # of stamps

[Bill K. <nb...@so...>]

On Sun, Oct 15, 2006 at 05:10:50PM -0400, Albert Cahalan wrote:
> Things in the sky (moon, F-15, hawk, blimp, fireworks) belong together.
> As it is now, the user is forced to spend much of their time scrolling.

Perhaps once Tux Paint's own UI provides access to stamp subsets, that
symbolic links/shortcuts/aliases could be used.

So "sky" could be a meta-category which simply includes different stamps
from vehicles/aircraft, space/, etc.

So you could get to the moon from both 'space/' (where it truly "lives"),
or from 'sky/', which is a metacategory.


I really don't want to worry about this (or even think much about it ;^) )
at this point, since I want to get 0.9.16 out the door BEFORE our baby
is born.  Otherwise it won't happen for another year. ;^)


-bill!

Re: [Tuxpaint-devel] Managing large # of stamps

[Bill K. <nb...@so...>]

On Sun, Oct 15, 2006 at 05:10:50PM -0400, Albert Cahalan wrote:
> 
> Like this: the "tuxpaint" is an empty package which depends on
> a "tuxpaint-bin" package (containing the executable) and on every
> stamp package. If you install "tuxpaint" you get absolutely everything.

Not a bad idea.  How do other large packages (say, OpenOffice.org,
or some clipart collection) manage this, though?


<snip> 
> That'd give you firemen and firetrucks without a fire! It's bad
> enough that they don't go together. (and where do I add the
> fire hydrant that I have? town???)

Correct. ;^)  Perhaps in the future we can provide a less hierarchical
division of stamps, and provide metadata 'tags'.

Of course, we begin worrying about both packaging/distribution issues
AND stamp access within Tux Paint itself.  I'd like to tread lightly,
for now. :^/


-bill!

Re: [Tuxpaint-devel] Managing large # of stamps

[Albert C. <aca...@gm...>]

On 10/15/06, Ben Armstrong <sy...@sa...> wrote:
> It is encouraging to see the stamps divided into smaller subsets now.
> But I still can't decide how to deal with this in Debian.  For one
> thing, 16 packages is a lot of new packages if I were to just create a
> new package per category.  For another, it still doesn't help me choose
> which stamps (if any) to install by default.  I could install just a few
> of these by default, but which ones?

Like this: the "tuxpaint" is an empty package which depends on
a "tuxpaint-bin" package (containing the executable) and on every
stamp package. If you install "tuxpaint" you get absolutely everything.

>   And even if I did decide on, say:
> animals, food, people, plants, symbols, town and vehicles as being
> reasonable "core" categories, with clothes, hobbies, household, medical,
> military, naturalforces, seasonal, space and sports being considered
> "extra", that's still 247 stamps!  Or let's say just one category:
> animals.  There are 47 stamps in this category!

That'd give you firemen and firetrucks without a fire! It's bad
enough that they don't go together. (and where do I add the
fire hydrant that I have? town???)

> Here's a different tack: do we need to break it down very much at the
> level of packages?  What if we just install *all* of the stamps, and
> allow tuxpaint to be easily configure to select some arbitrary subset?
> For example, we could have a "Stamps" tab in tuxpaint-config that
> presents a tree of categories & stamps with checkboxes by each directory

This assumes that the directories are decent, but they are not.
Consider my firemen/firetruck/fire/hydrant example.

Things in the sky (moon, F-15, hawk, blimp, fireworks) belong together.
As it is now, the user is forced to spend much of their time scrolling.

Re: [Tuxpaint-devel] tuxpaint, tuxpaint-config, tuxpaint-stamps now in Debian incoming

[Ben A. <sy...@sa...>]

Ben Armstrong wrote:
> Debian sid users, tuxpaint, tuxpaint-config and tuxpaint-stamps are now
> at http://incoming.debian.org/ for the next little while, and shortly
> afterwards will appear in sid.
>   

Also, I have now put the packages at:

deb http://packages.debian.org/~synrg/tuxpaint/sid ./

Ben

[Tuxpaint-devel] tuxpaint, tuxpaint-config, tuxpaint-stamps now in Debian incoming

[Ben A. <sy...@sa...>]

Debian sid users, tuxpaint, tuxpaint-config and tuxpaint-stamps are now
at http://incoming.debian.org/ for the next little while, and shortly
afterwards will appear in sid.

Ben

[Tuxpaint-devel] Managing large # of stamps

[Ben A. <sy...@sa...>]

It is encouraging to see the stamps divided into smaller subsets now. 
But I still can't decide how to deal with this in Debian.  For one
thing, 16 packages is a lot of new packages if I were to just create a
new package per category.  For another, it still doesn't help me choose
which stamps (if any) to install by default.  I could install just a few
of these by default, but which ones?  And even if I did decide on, say:
animals, food, people, plants, symbols, town and vehicles as being
reasonable "core" categories, with clothes, hobbies, household, medical,
military, naturalforces, seasonal, space and sports being considered
"extra", that's still 247 stamps!  Or let's say just one category:
animals.  There are 47 stamps in this category!

Clearly this approach isn't working.  How about a "sampler" package that
contains a few from each of the "core" categories listed above (we can
haggle later about what's in "core")?  There is a potential issue with
this approach: if something's in the sampler package, do we remove it
from the "extra" packages?  What if someone wants some of the stamps in
the sampler, but not the whole sampler?

Here's a different tack: do we need to break it down very much at the
level of packages?  What if we just install *all* of the stamps, and
allow tuxpaint to be easily configure to select some arbitrary subset? 
For example, we could have a "Stamps" tab in tuxpaint-config that
presents a tree of categories & stamps with checkboxes by each directory
& by individual stamps, with a stamp preview pane to allow the admin to
decide.  This would allow an admin to, for instance, select different
subsets for children of different ages, or rotate the "seasonal" stamps,
only enabling certain subsets at certain times of year.

A cheap way of providing this degree of admin control is to just allow a
different path to be specified for stamps, i.e. a --stampspath variable
that can be set to a colon-separated list of paths.  Then the admin can
create a /usr/local/share/tuxpaint/stamps populated with symlinks to the
desired categories, or even to individual stamps.

Ben

Re: [Tuxpaint-devel] Chinese fonts

[Ben A. <sy...@sa...>]

Bill Kendrick wrote:
> 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.
>   

I will use ttf-arphic-uming.  An alternative is ttf-arphic-ukai.  I
don't read Chinese, though.  My daughter, however, reads a little, and
we agree uming is easier to see because the script is plainer.

I'll need someone who can actually read this stuff to try it out and see
if it all looks OK, and then let me know.

Ben

Re: [Tuxpaint-devel] Chinese fonts

[Bill K. <nb...@so...>]

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/

Re: [Tuxpaint-devel] Chinese fonts

[Ben A. <sy...@sa...>]

I've got it!  It must be the subsetting procedure.  Please fetch:

ftp://cle.linux.org.tw/pub/fonts/wangfonts/wp010-05.ttf

Then symlink zh_tw.ttf to it.  The one-row-of-pixels problem is gone!

Maybe we just need to alter our subsetting procedure to extract the font
in such a way that SDL_ttf can accurately determine the height.  Perhaps
it does this by measuring one special character, a character which the
subsetting procedure has omitted?

Ben

Re: [Tuxpaint-devel] Chinese fonts

[John P. <jo...@jo...>]

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.