[links-list] Re: fonts fonts fonts .... why not draw them ?

aludal aludal at softhome.net
Thu Nov 14 13:25:00 PST 2002

> Dear links addicts,
...and you supposed to be clean of that dope, eh?

> lots of mail on this list on fonts... the advantages for this, the
> advantages of that etc... all seem to kind of take the inclusion of
> hundreds of PNG files for granted.... I'll try to comment on various topics
> that came by :
> On the subject why PNG's seem to be able to be compressed more: only the
> image itself inside the PNG is compressed using libz with a compression
> factor that can be set by the coder and a `filter' method that tries to
> generate the best input for the libz to compress. I've seen `the gimp'
> produce much larger PNG's for example than my PNG codec even though i still
> haven't implemented the `max crunch' filters yet in my encoder. Its obvious
> that the PNGs together can be crunced again to get a smaller file for all
> the other blocks like palettes, descriptors, block headers etc. etc. are
> not compressed and all theoretically have some form of redundancy in them
> and can therefore be crunched again.
> As to using bzip2, the libz also supports this kind of encoding; its all in
> the encoder's view. If i tell the libz to flush all and restart afresh
> after it crunced a certain amount of data when encoding, all libz's will
> happily just follow it making it effectively bzip2. OK ... bzip2 might use
> a different algorithm alltogether but the advantages of blocking is easily
> done using libz too.
yeah, we all came to the conclusion already, that bz2 will squeeze out up to 
60 % of total redundant filesize, and it's great. Now think of something not 
so sweet, but sour like ARM 20x-series processor for a PDA which is I believe 
no better than Pentium 90 MHz for unzipping/font rendering on the fly. It is 
these silly palmtops/tabletPC/mobile-phone Links might have a good market 
share. With a theoretical possibility to get 6-8 basic Unicode PNG sets in 
under 10 MB of (Flash) RAM of these toys, there might be no big need in 
compressing-decompressing them.

> I've also hearded some comments on `why not use freetype2 ?/ Xfonts / ...'
> ... personally i dont like freetype2 that much allthough the output i've
> seen is very reasonable to pretty good. The hard dependency on X is prolly
> not wanted for it might run on a non X system :-D
I don't like freetype2 either, that's why I use so called Xft Hack instead of 
it. As for (non-X) DirectFB driver for Links, it might contain some 
(freetype2, or whatever) font rasterizer backend one day. Or might not, as 
nobody seems to care. So far, we stick to our X.

> Still... whats the problem with say embedding font definition files for a
> few typically used fonts ? i.e. Latin encoded serif/non serif, cyrillics,
> .... and render them to the requested fontsize either to the screen
> directly or to the PNG font cache ? A fontrenderer doesn't have to be big
> at all... I wrote a (soon to be released) fast Postscript compatible render
> engine (with a GPL compatible licence) with Type1 and Risc-OS fonts support
> that has a codesize foorprint of about 87 kb on StrongARM machines and even
> just 95 kb on an Alpha machine.  (see http://www.13thmonkey.org/Artdraw for
> the outdated website)
Good! But try now to compete in footprints of both renderer and font(s) with 
this toy called Font Fusion:


> Given that a gzipped Courier type1 font definition is about 73 kb too its
> easy to see that it won't bloat at all....
Let me see.... A zipped more-or-less complete "lower" Unicode (no CJKV) 
Courier TrueType is about 330 KB, more-or-less complete zipped Courier-like 
monospace TrueType CJKV is anything between 3.1 and 4.5 MB, a lower estimate 
is for "wire" monowidth-stroke characters. All the "bloating talk" was about 
these, no problem of special concern has ever existed with basic Latin, plus 
Cyrillics, plus even Arabic/Hebrew/Katakana/Hiragana.

> Any ideas / comments ?
Oh yeahh.... lots of them.
1. Before the Links authors agree to dump their own font renderer, and replace 
it with your wunderbaby, how about coding some neat standalone ttf2png 
convertor instead? It would be of HUGE help to the project, as I'm exhausted 
of cutting italics one by one....
2. Talking about PDAs/mobile phones and other crappy displays. Back in 80s, it 
took Damon Clark et al., at Apple Corp. couple years to cut an excellent Espy 
family of fonts which, unlike most of todays' stuff, is readable enough on 
screens of 72 dpi. Apple dumped the whole project for some reason
(see http://www.damonclark.com/inside/work/work_fonts.htm), switching to 
Chicago (? or something) instead. So, Espy Serif and Espy Sans became like 
"abandonware". Sort of. With Apple Corp., not at all. But there are some 
free/sharewares cuts like (Nu, Neue) Epsy etc. I don't have (ancient) Mac to 
play with those, but it seems to me that a Links release for embedded devices 
could contain something like this, instead of bloat Century of today. And, it 
would be fun to convert these to PNGs, naturally, with your new shining 
ttf2png convertor.

Good luck,
P.S. Got enough of that chickencrap splosh called "system font"? Attached is 
my cut of Links mascot vignette, as a replacement, grab it and enjoy (less 
than 5 KB, which is very good for "system font" and well below 60 KB limit, 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0000.png
Type: image/png
Size: 4913 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/links-list/attachments/20021114/9a58b8b2/attachment.png>

More information about the links-list mailing list