2008-04-14

Proportional Fonts

Thanks to Jeff’s hard work, Woopsi now has two proportional font classes. One works with 1-bit fonts, whilst the other works with 16-bit fonts. I’ve tidied up the existing font classes a little to support this, moving things out of the base classes into the subclasses.

Jeff also supplied a new version of his “bmp2font” Python script, which will generate the sourcecode needed to describe one of the new fonts. This is included in a new “pythonscripts” folder.

Lastly, I’ve fixed a couple of bugs introduced when I refactored the click/focus system. Screens now receive focus correctly when clicked (and get raised up the gadget stack). They also get dragged properly - they were being dragged when clicked anywhere instead of just the title bar.

Comments

Jeff on 2008-04-15 at 04:04 said:

Cool. Back to Wifi. ;-)

One question about the cleanup. Is there a reason you prefer the #ifdef/#endif inclusion guards over #pragma once ?

The pragma is definitely supported by devkitpro, the only compiler that any of this stuff is ever compiled with. And its way faster than the #ifdef guard because the pre-processor can stop as soon as its sees the pragma whereas with the #ifdef it still has to scan the source file for the matching #endif

Not to mention that you can’t accidently mismatch #endif’s with the pragma.

The only argument I’ve seen against them is that people can get it confused if they use different paths to access the same file. For example, if you use

“header.h” and “../source/header.h”

where this is the “source” directory. The pragma records the pathname used to open the current header and compares that against subsequent includes.

Personally, however I don’t mind this one because I consider those two different access paths as a BUG - if you sometimes have to use a specific path like that, it typically means you have the wrong -I switch to the compiler, or that you should always be using the specific path.

ant on 2008-04-15 at 05:59 said:

I started using #ifndef initially because I didn’t know gcc supported #pragma. I use it now for consistency.

ant on 2008-04-15 at 08:04 said:

Heheh, there’s nothing like empirical evidence to prove a point. Fixed.

Jeff on 2008-04-15 at 08:44 said:

I hate to say it, but, um, the latest checkin to svn, um …


Albatross:include jeff$ grep define packedfont1.h
#define _PACKED_FONT_1_
Albatross:include jeff$ grep define packedfont16.h
#define _PACKED_FONT_1_

Oops.

#pragma once rocks…

Jeff on 2008-04-15 at 10:52 said:

After trying the font stuff in anger (with some better font images), I’ve made a tweak to it - space characters were being rendered as ‘widmax’ pixels wide whereas they should really only be about ‘cheight/4’.

I’ve added a new member variable, adjusted the constructors, and updated the script appropriately. Here’s an archive…

http://rapidshare.com/files/107652117/fontfixes.zip.html

d_fens on 2008-04-15 at 13:35 said:

makefile.lib should be Makefile.lib, linux is case sensitive and fails unless its actually called as make -f Maefile.lib since make -f makefile.lib seems to want to have it capitalised either way.

ant on 2008-04-15 at 19:36 said:

Thanks Jeff! Latest font classes committing to SVN now.

d_fens, according to the GNU make docs - http://www.gnu.org/software/make/manual/make.html - “makefile” does not need to be capitalised. Make should look for both files. You might have more luck if you rename it from “makefile.lib” to “makefile”, though, which is how I imagine people would generally use it.

Jeff on 2008-04-16 at 05:30 said:

Not true on makefile.lib.

If you specify a name explicitly (via -f) then you need to get the case right. Its only in the default case that it looks for GNUMakefile, then Makefile then makefile, etc.

I have an updated makefile.lib (and makefile.app) that address this properly by using the $(MAKEFILES) variable properly. I will try to upload those when I get home tonight.

Jeff on 2008-04-16 at 05:31 said:

I wasn’t clear in that previous post - the problem is that the makefile uses this curious “reinvoke myself via make -f” which is great when you are using the default, and crap when you don’t want to mandate what you are called.

I’ve been trying to completely get rid of the recursive make since its not needed - there are other ways of achieving what its doing.

ant on 2008-04-16 at 11:37 said:

This is why open source is great - free code! I’ll definitely steal all of these fonts and add them into the “bonus” folder, if that’s OK with you.

When I start rejigging the Woopsi package, I’ll probably follow PALib’s lead and have an “examples” folder. I’ll move the demo code into there, and probably include this whole app as a font demo rather than try to merge it in to the existing demo.

Jeff on 2008-04-16 at 12:13 said:

Here’s a proposition for you.

http://rapidshare.com/files/107935710/FontDemo.zip.html

In there is an extremely quick and dirty program that demos the bunch of fonts that I’ve converted for myself. I think it would be relatively trivial for you to change the way I’ve done the buttons to use your popup menu instead.

That way, you test the popups in anger, and get to own yet another test program for the suite…

I’m happy that it shows me what I wanted to see - of course, it also shows that most of my fonts are no good for buttons because the text doesnt end up centred (I’m prepared to believe I’ve made them too tall, for clarity - if I were changing it, it would be to use a list.

One warning, however, I believe it manages to go very close to the limit on how much ‘const’ data you can have in a program, which surprises me. When you add a little bit more sample text, some of the fonts manage to get corrupted. Or perhaps there’s some other bug that I just can’t see…

Jeff on 2008-04-16 at 21:03 said:

I’m happy for you to have the fonts, though I believe they need some tuning. Once I’ve done that, I’ll let you have the updated bitmaps and .cpp/.h files.

Yes, its definitely better to make this a seperate demo, though it should also serve as a warning - don’t try to include hundreds of fonts into an app - you’ll blow one or more compiler limits very quickly.