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.
>> There needs to be some discussion regarding how many lower
>> level fonts should be loaded, since we don't have dynamic
> 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
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
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,
>> 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
>> 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...
Received on Wed Aug 24 22:37:43 2005