|
Rockbox mail archiveSubject: Re: Thoughts on Multiple Fonts in RockboxRe: Thoughts on Multiple Fonts in Rockbox
From: Jens Arnold <arnold-j_at_t-online.de>
Date: Wed, 24 Aug 2005 22:36:49 +0200 On 24.08.2005, Daniel Stenberg wrote: > On Tue, 23 Aug 2005, Greg Haerr wrote: >> I thought I'd comment on Daniel's thoughts about adding >> multiple fonts to rockbox. > Thanks, I value your input a lot! Just some additions from me as well. >> The font cache should house numbered fonts, not named fonts. > Right. >> There needs to be some discussion regarding how many lower >> level fonts should be loaded, since we don't have dynamic >> memory. > Actually, I had a slightly more complicated but flexible > approach in mind: > ... > Thus, we can support displaying of numerous fonts, while we > only support N simultaneous ones. In most screens you only use > a single font anyway. The only downside is that the selecting > of a font that isn't in the cache requires a disk spin-up and > load. I think just loading multiple fonts into the buffer is quite simple, however, I think that forcing a disk spinup just to change fonts if the cache can't hold both is bad. Imagine a wps using 2 different fonts in alternating elements, and both fonts can't be loaded at the same time -> a spinup every few seconds... However, we will need font caching anyway, and somewhat more sophisticated than for multi-font support, if we want unicode support (a much more valuable thing than multiple font support, imho). >> ... >> Rather than loading fonts on the fly, which has memory >> allocation issues because of the differing bitmap sizes, all >> fonts could be loaded at boot, and then when the application >> requests FONT_xxx, the font is used if present, or >> FONT_SYSTEM is defaulted. > Forcing users to reboot when they switch font seems harsh to > me. Agreed 100%. >> The application never knows the optional or default sizes, >> any on-screen formatting must use a lower-level system call >> to determine sizing information. > Already today the applications don't know the size until they > figure it out using the proper function(s). Here is the most difficult point of multiple font support. Plain text output is simple, we can even drop the line-based output functions and enforce using lcd_putsxy(). However, we need to implement a suitable mechanism for scrolling text. As long as we don't want to allow more than one font per scrolling item, this seems manageable.... Hmm, when I think of it... maybe it's not *that* difficult.. >> In this way, the application specifies a "desired" font, >> rather than a mandatory font. > I would imagine that we could have the font changing function > have a parameter that asks for the specified font mandatory or > optionally, and in the latter case we could have a fancy way > for the font subsystem to pick the one of the already loaded > fonts that is most similar to the one you ask for. That sounds a bit too sophisticated for me... I think we should have a fairly low number of different fonts, just one more than the current 2 would be enough. I'm all for supporting styles, as that doesn't cost extra memory. ** A related thing, the status icons should be widgets, and the status bar just using them. This way a wps designer could place them at will, the default wps would include them in the default status bar layout, and the real status bar would never be shown in the wps. I think that doing that properly requires vector icons... Regards, Jens _______________________________________________ http://cool.haxx.se/mailman/listinfo/rockbox Received on 2005-08-24 Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |