[wikireader] Project Gutenberg (again)

Sean Moss-Pultz sean at openmoko.com
Tue Jun 8 23:36:46 CEST 2010

Hi Tom

On Tue, Jun 8, 2010 at 7:20 AM, Tom Bachmann <e_mc_h2 at web.de> wrote:

> >> 1) Is there a "deep" reason why boldface fonts are not implemented? I
> >> figure they are not really relevant for wikis, but would be nice for
> >> some of the books. Unless there is something that complicates the matter
> >> I'm not seeing, I think I will add them (should be straightforward to
> >> mimic the behaviour of italic fonts?).
> >
> > They are implemented. We just didn't include them to save space. (Font
> > sets are super huge when you include all the unicode characters!)
> >
> > If you look at the function "handle_data" within
> > http://github.com/wikireader/wikireader/blob/master/host-tools/offline-renderer/ArticleRenderer.py
> > you'll see what I mean.
> >
> Hm. I thought I had convinced myself that the real problem was that only
> two bits are used to encode the font id, and they are already used up
> (default, italic, title, subtitle, and "supplements" [large files with
> all characters I suppose] for default, title, subtitle). So adding
> boldface fonts to the wiki-app *does* seem to involve some non-trivial
> work. (I guess the advantage of splitting the fonts like this is that
> the small subset can be kept in memory all the time? The size of the
> fontfiles themselves is on the order of megabites so shouldn't matter,
> should it?)

This has nothing to do with the data structures. We cache the fonts
into the SDRAM to speed up the entire system. Without this, WikiReader
is too painfully slow (reading from the SD card caps out at around
125kb/s.) Currently we use 32MB of SDRAM. This means we can hold a few
font styles but we need to move to smaller size SDRAM for future
productions for cost reasons. So we have to be super careful with how
we handle fonts. It's quite a complex problem for us. Especially as we
add more and more language support.


More information about the community mailing list