Font compression and decompression

Just off the top of my head, I'd say that run-length encoding would save you quite a bit. Here's a link:

but you'd have to have enough RAM to store the decompressed results

--
Tim Mitchell

One only has to store the decompressed characters you need to display. One would expect that there is room for the display info, or am I wrong?

Cheers Roland

In article , Roland Mathijssen writes

The way run-length encoding works, you'd need to decompress the whole thing to extract one character. You could do this every time you want a character but it would use up a lot of processor time.

--
Tim Mitchell

About 16 _bits_ :-)

However, you have to select the compression order to be match the display controller protocol or display memory organisation.

If the display requires that horizontal scan line is written in a single operation and the lines under it in separate operations, use the same RLE algorithm as in a telefax machines, i.e. use a full horizontal RLE of the _first_ scan line only. When compressing further scan lines, compare the scan line to the line just above it and note the differences. RLE encode the differences. When decoding, uncompress the first line, save it (requires as many bits as the character is wide:-) and write it to the display. When decoding the subsequent lines use the decoded and saved previous line as a starting point and apply changes.

If the display expects that a column is written at a time, RLE encode the leftmost column of the character. For subsequent columns, encode differences compared to the column immediately to the left. When decoding RLE decode the leftmost column and save it (requires as many bits as the character height) and write it to display. For the other columns, apply changes to the saved version and write result to display.

Paul

Any algorithm not required to decompres the whole?

"terry" schreef in bericht news: snipped-for-privacy@posting.google.com...

How do you calcultate that? 512 bytes rom size? 16x16 pixel characters?

512*8/16/16=16 -> characters, not fonts. Not even enough for a complete character set.

RLE encoding is a rather simple encoding scheme to implement, and probably the best choice for monochrome bitmaps. Or emulate 14 segment character display, two bytes for each character needed, and draw lines to display your characters, at any size you want.

--
Thanks, Frank.
(remove 'x' and 'invalid' when replying by email)

Yes, you can get algorithms that are character-aligned, but that can restrict the savings. Compression is a trade off, you need to define before you start:

CODE & RAM size that can be used for the algorithm ? EEPROM size needed/available to store the fonts ? Options during un-compress : do they have to come out in raster-order ?

Next, you should analyse the characters/fonts themselves, and their bit-spreads, and coherence.

The best compression schemes use the non-random nature of the data to best effect, and you can also use the users eyes.

Call this compression by pixel reduction :)

eg a very simple one, is to take your 16x16 char area, and encode as

8x8 where possible : Customer may decide 4 times as many, but chunkier, soft characters is a good idea. LCDs are workable down to ~5x7 fonts : that's a 7.3:1 compression

Or, going further to a 14 or 16 segment stroke- font, and stroke-decode sw, turns the 256 bits into 16 bits, for 16:1 compression. If you design your own 32 segment font, that's 8:1 compression, so you get the general idea.

Of course, serial memory is also very cheap, and starts in SOT23 packages...

-jg