[Tuxpaint-dev] Tux Paint mentioned on O'Reilly
A friend just noticed this and sent it to me: http://www.oreillynet.com/pub/wlg/6124 :) -bill! ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] SharewareJunkies.com award!
Tux Paint has received the "Best Macintosh Program" of 2004 award in the 2005 SharewareJunkies.com Awards! http://www.newbreedsoftware.com/tuxpaint/reviews/sharewarejunkies/ :) -bill! ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] --nosysfonts option added
On Tue, 2005-01-04 at 02:20, Bill Kendrick wrote: > I've added a "--nosysfonts" option to Tux Paint > (and corresponding control in Tux Paint Config) which disables any attempts > to load fonts from 'outside' Tux Paint. > > This allows _me_ to keep running the app, until we can figure out what > the problem is with the font grouping code in the latest CVS. ;^) Try now, without that option. Tux Paint now tries to render both 'A' and 'a' for each font. It then compares them to see if they are the same or not. I commented out the blacklist for now. The X11 "Cursor" font won't render. This seems to be a serious undocumented bug in the library. In fact, no error return is even documented. I had to guess that a NULL might be returned. The library should be supplying an image of a box to represent the failure, as it does with other bad fonts, or it should have a documented error code. Several other fonts return generic box images. I have Tux Paint discard any font that has 'a' match 'A'. Probably I should also discard the font if 'a' matches 'z' or if 'A' matches 'Z'. So, what is your bad font? ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] --nosysfonts option added
On Tue, 2005-01-04 at 02:20, Bill Kendrick wrote: > I've added a "--nosysfonts" option to Tux Paint > (and corresponding control in Tux Paint Config) which disables any attempts > to load fonts from 'outside' Tux Paint. > > This allows _me_ to keep running the app, until we can figure out what > the problem is with the font grouping code in the latest CVS. ;^) > It may also prove a useful feature in the 'real world' (for both preventing > possible crashes, as well as culling down the number of available fonts > for people who(se kids) don't need them.) That's probably good for those people who were crazy enough to buy and install a 5000-font CD-ROM. Of course, every other app on their system will be horribly slow. Would you like a memory checker in CVS? I have one, only about 150 lines, that prints a nice report when the app exits. For each alocation, you get a line with: 1. the size 2. the line number, or -1 if allocated from another file 3. the allocation number (1,2,3,4...) Possible enhancements: a. printing the report when a signal is sent b. printing the nearest line-numbered allocations for an unnumbered one c. tracking high-water marks Right now, Tux Paint leaks just under half a megabyte. I've yet to determine if this is a one-time leak or an on-going leak. > Also, I've replaced the 640x480 and 800x600 radio buttons with a pulldown > that lists the window dimensions listed in tuxpaint --help. > (Tux Paint Config also now, obviously, supports the "windowsize=..." syntax.) I think all sizes work now. I haven't really checked the file open dialog. I just recently fixed the low-quality color selector to not overwrite the tux area. I've been testing with heights that are not a multiple of 48, and things have been looking good. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
