From: Joseph Jones <bumpycarrot_at_gmail.com>
Date: Wed, 24 Aug 2005 00:26:10 +0100

I think having multiple fonts with one font per screen would be a
great start. Since getting my iRiver, I sure have started noticing how
small my font looks in the WPS ;)

Joe

On 8/24/05, Greg Haerr <greg_at_censoft.com> wrote:
> Hi,
> I thought I'd comment on Daniel's thoughts about adding
> multiple fonts to rockbox. I'd like to think of adding this
> capability in two levels, a lower system level, where fonts
> are loaded and actually displayed, and at an application level,
> where different fonts may be requested to be displayed
> by the running (Rockbox) application.
>
> My comments follow. Of course, basic multiple font support
> is easy, my original contribution had multiple font support.
>
>
> : We have a font cache with named fonts (like "uwe-prop14", "chicago12" and
> : "alt6x10"). The cache fits N fonts, where N must be at least the number of
> : simultaneous fonts we support (which _could_ be dynamic so that we support
> 6
> : small fonts or 2 big ones etc).
>
> The font cache should house numbered fonts, not named fonts. Only
> a system level routine should load a named font into a numbered location.
> The "current font" can then be set by the application level (or added
> as a parameter, if desired to the textout api call), without adding much
> application complexity.
>
> There needs to be some discussion regarding how many lower level
> fonts should be loaded, since we don't have dynamic memory. Perhaps
> the config option that specifies the font name and its application display
> use
> counts them and allocates memory for all specified. The application
> would have a config option allowing for any FONT_xxx to
> have a specific font used if desired.
>
> :
> : Internally, we have a long list of font ID to font name mappings. Like
> :
> : FONT_RADIO
> : FONT_DIRBROWSE
> : FONT_MENU
> :
> : Each of these can be set to a specific font name by the user (through a
> config
> : file). Of course, if a font is to be used that isn't already in the cache,
> it
> : will get loaded into the cache from disk (and the least recently used font
> : gets discarded from the cache if the new one doesn't fit).
> :
> : The system built-in font has its own font name (like "default" or so)
> which
> : means that using that won't occupy space in the font cache at all.
>
> I think the above FONT_xxx should just be an enum, with values
> from 0. FONT_SYSTEM would be 0, with optional values
> starting at 1. 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. The current font format is designed such that
> the font file can be loaded "as-is", with width table and bitmap
> offsets pointed to by the font loader.
>
> The application never knows the optional or default sizes, any
> on-screen formatting must use a lower-level system call to determine
> sizing information. In this way, the application specifies a "desired"
> font, rather than a mandatory font.
>
> : ... and let's assume that WPS1 is the smallest and WPS4 is the biggest.
> Using
> : this, a WPS designer can use 4 sizes, while a user of such a WPS can still
> : elect exactly what fonts to use for those sizes.
>
> Font aliasing could be done in the config file if necessary, otherwise
> dynamic size information would be requested by the application.
> I don't see the need for aliasing, if the font section of the config file
> just specifies the font the user desires for that portion of the
> application display.
>
>
> : Italic/Bold - shall we support such styles to a given font or shall we
> just
> : force users to just specify a font with these characteristics instead?
> These
> : styles can get made on a font run-time and thus not wasting any extra
> space
> : for them, but is it worth the extra code?
>
> The extra code to bold is extremely simple, providing we have a
> low level routine to draw only foreground bits - erase bkgnd, draw bits,
> move right one pixel, draw again. Italic doesn't always look as good,
> but it'd be much cheaper in ram usage not to have to have a italic
> versions of every font available just to draw italic on occasion.
>
> Regards,
>
> Greg
>
> _______________________________________________
> http://cool.haxx.se/mailman/listinfo/rockbox
>

_______________________________________________
http://cool.haxx.se/mailman/listinfo/rockbox
Received on 2005-08-24