So I checked the todo list, double checked it, and decided to finally do something about that flipclock app that's been languishing there for quite a while now. The first thing I had to do was track down the problem with the display. It was way too flickery to leave on all night. I tried it once and it drove me nuts. So I reorganized the code a bit to give the SDL software double buffering a chance to do it's thing. Now I can leave it running without fearing for my sanity.
After spending all that quality time in the code I finally felt more confident adding some command line options to do various messaging functions in the blank space below the actual clock.
Usage: fc [-1|-2|-3|-4][D|f][w|d] [message|file|timeformat]
Displays a flipclock and up to 4 lines of text messages underneath.
f = Display message from a file. Updates whenever the file does.
D = Display the date/time by passing timeformat through strftime().
Line 3 defaults to a date using "%b %d, %Y - %l:%M %p".
w = white text (default = grey)
d = darker grey text.
eg: fc -1d "Nice weather." -2D "%b %d, %Y" -3 "" -4 "Wake at 7 AM"
This should work on either IZ2S or the iz2jffs, although I haven't yet tested the alarm script in the bash shell on IZ2S.
I'd still like to see if I can get it to use the gmu font files in addition to sfont files and the modified gmenu2x sfont file. I suspect gmu uses only fixed width fonts because the fonts lack the "magic pink" spacers on the top image line.
I added a -t option for 24hr time in the main clock display, and -p for padding the upper hour digit with a zero for folks who need to see 4 digits all the time. I also experimented with various options for the date string to see what could be done with that. Here I tried it with a bigger message font and this command for an ISO 8601 date with 24 Hour time.
fc -tp -3w "%F - %R %p"
I have to say, I definitely prefer the layout of the GMU font file to the gmenu2x "sfontplus" file. The GMU font files are quite small because they use fixed width characters. The magic pink spacers don't seem to compress so well in the sfont files. But what I really like about the GMU file is that it's a simple 256 character latin1 font, which works quite well with the latin15 setup of the iz2jffs. The gmenu2x sfontplus file has the glyph order scrambled all willy-nilly. Who came up with that? If I ever do get back to working with the openwrt-zipit version of the gmenu2x code, the first thing I'm gonna do is re-order the glyphs in the font file. It's unicode so I'll just put them in unicode standard order with the gaps for missing characters compressed.
Now if only I could convince gimp or mtpaint to generate a decent png font file, I'd be all set with the flipclock app.
Maybe this microfontmaker thing will do it for me? I just gotta find me a PC that still has java on it.
Or maybe I can hack the code from that tiny sdl font previewer to save a png file.
Or use one of the many Windows texture font makers like bmfont. Something's gotta work.
Or maybe I should just come to terms with the fact that libfreetype and libSDL_ttf actually fit on the jffs with plenty of room to spare. I really should be using ttf fonts for everything. In fact, the best change I could make to the jffs would be to chop the huge png font outta links and replace it with some nice ttf fonts that all the apps can use. I really need to take another look at that plan9 ttf version of links...
I managed to modify the dingux gmenu2x font generator program gen_sfont_image.py to create a latin1 png font instead with gen_sfont_latin.py. I used it to create an sfont file with the same latin1 glyph order as the gmu font file, except this one uses a proportional spaced 15 point DejaVuSansCondensed font. The file is a bit larger than I'd like so maybe the gmu font makes more sense for the jffs. I might do some more experiments generating fonts, but more likely I'll start converting the flipclock to use a ttf font. Heck, even the tiny imgv program uses the ttf font.
I did a quick latin test on puppy linux and it seems to work, maybe.
Meanwhile, since I'm still waffling over then benefits and drawbacks of libfreetype I should probably mention stb_truetype.h over at http://nothings.org. It replaces libfreetype with a small C header file. You give up some quality (hinting) and performance for the tiny size but you also lose the dependency on the huge shared lib. I probably can't use it on the zipit because I really want the hints for the smaller fonts. But I'm gonna have to try it. And some of the other code there too.