Forum Menu




 


Log in Problems?
New User? Sign Up!
AVR Freaks Forum Index

Post new topic   Reply to topic
View previous topic Printable version Log in to check your private messages View next topic
Author Message
Torby
PostPosted: Sep 03, 2013 - 06:46 PM
Raving lunatic


Joined: Nov 11, 2003
Posts: 5781
Location: Broken Arrow OK USA

This tool seems to come from http://www.mikroe.com/glcd-font-creator/ these days.

A useful tool for creating fonts for your LCD and other graphic displays.

_________________
Torby

You can't always believe everything you think.
 
 View user's profile Send private message Visit poster's website 
Reply with quote Back to top
Torby
PostPosted: Sep 04, 2013 - 02:46 PM
Raving lunatic


Joined: Nov 11, 2003
Posts: 5781
Location: Broken Arrow OK USA

It produces a structure that looks something like this.

Code:

const unsigned short Tahoma10x11[] = {
        0x06, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  // Code for char 
...


Gives you one line per character. You'll want to edit it to be an array of bytes instead of shorts as none are bigger than 0xff. I also added PROGMEM.

The first byte of each line is the pixel width of the character. All the characters take the same memory so you can easily calculate where in the array to look for 'Q'. You could likely save some space by removing extra blanks and making another array to look up the offset into this array for each letter.

The rest of the line consists of the pixel data, one bit per pixel, arranged in columns. If your font is 16px high, there will be 2 bytes per column. The bits seem in reverse order to me, but aren't hard to read. Start with the first byte of the column. Bit 0 is the topmost pixel of the column, bit 1 below that and so on. The next byte goes below that.

A font is really big. "12 pt Tahoma" yielded 2880 bytes and 36pt Tahoma was 40KB. (I didn't use 36pt. Too big for display and memory.) I wonder if a simple "run length" compression would make it smaller but still easy to decode.

_________________
Torby

You can't always believe everything you think.


Last edited by Torby on Sep 04, 2013 - 03:16 PM; edited 1 time in total
 
 View user's profile Send private message Visit poster's website 
Reply with quote Back to top
theusch
PostPosted: Sep 04, 2013 - 03:05 PM
10k+ Postman


Joined: Feb 19, 2001
Posts: 28194
Location: Wisconsin USA

Quote:

I wonder if a simple "run length" compression would make it smaller but still easy to decode.

"Font converter" has been discussed before.

Gabotronics mentions compression:
http://www.avrfreaks.net/index.php?name ... 638#888638

>>You<< mentioned compression here:
http://www.avrfreaks.net/index.php?name ... 52#1004652
Wink

The MikroElektronika tool is mentioned in this thread, along with the tool I use and links to more discussions:
http://www.avrfreaks.net/index.php?name ... 92#1026792

"Pavius" tool:
http://www.avrfreaks.net/index.php?name ... 360#600360
http://www.pavius.net/2009/07/the-dot-f ... generator/
 
 View user's profile Send private message  
Reply with quote Back to top
david.prentice
PostPosted: Sep 04, 2013 - 03:21 PM
10k+ Postman


Joined: Feb 12, 2005
Posts: 19412
Location: Wormshill, England

Fonts can use up quite a lot of flash memory even with a 128x64 KS0108 display.

A 240x320 TFT display certainly benefits from better fonts. If you have a SDCard, memory is no problem. Otherwise just use subsets of fonts. e.g. if you are only displaying ascii text, you only need 0x20-0x7E.

Rendering detailed fonts on high resolution displays can use all sorts of tricks. Ask your Laser printer. I doubt that it is worth bothering when you only have 240x320.

Incidentally, the <Adafruit_TFTLCD.h> library simply uses a 7x5 font and multiplies each pixel. So it looks horrible in big sizes.

David.
 
 View user's profile Send private message Send e-mail  
Reply with quote Back to top
theusch
PostPosted: Sep 04, 2013 - 03:53 PM
10k+ Postman


Joined: Feb 19, 2001
Posts: 28194
Location: Wisconsin USA

Quote:

Incidentally, the <Adafruit_TFTLCD.h> library simply uses a 7x5 font and multiplies each pixel. So it looks horrible in big sizes.


Hmmm--is there the equivalent of "TrueType" for zooming fonts suitable for an AVR8? Perhaps it is just easier to burn the storage for the needed fonts, than to spend time rendering and buffering the results in scarce SRAM.
 
 View user's profile Send private message  
Reply with quote Back to top
Torby
PostPosted: Sep 04, 2013 - 04:10 PM
Raving lunatic


Joined: Nov 11, 2003
Posts: 5781
Location: Broken Arrow OK USA

I posted all this info here so it would show up if somebody searched. It's kindof an "update to the threads" posting.

I made 2 fonts from "Tahoma" and they are nicely readable on my tft. Tahoma is a font designed specifically to be read on screen. It does work well in print.

_________________
Torby

You can't always believe everything you think.
 
 View user's profile Send private message Visit poster's website 
Reply with quote Back to top
bobgardner
PostPosted: Sep 04, 2013 - 04:17 PM
10k+ Postman


Joined: Sep 04, 2002
Posts: 23451
Location: Orlando Florida

Yikes. A byte per pix. But I guess that makes sense if one has an 8 bit pixel. So each 10x11 char is 110 pix, 110 bytes, and you look up the 565rgb in a lookup table and draw the rgb pix?

_________________
Imagecraft compiler user
 
 View user's profile Send private message Send e-mail Visit poster's website 
Reply with quote Back to top
joeymorin
PostPosted: Sep 04, 2013 - 04:22 PM
Raving lunatic


Joined: Jul 17, 2012
Posts: 2276
Location: Location, Location

theusch wrote:
Hmmm--is there the equivalent of "TrueType" for zooming fonts suitable for an AVR8? Perhaps it is just easier to burn the storage for the needed fonts, than to spend time rendering and buffering the results in scarce SRAM.
And the storage requirements for a scalable vector-based font would be much greater than for a small-to-medium sized raster font. Add that to the code complexity, and I imagine the tipping-point where scalable beats raster is for very large fonts indeed.

JJ
 
 View user's profile Send private message  
Reply with quote Back to top
theusch
PostPosted: Sep 04, 2013 - 04:57 PM
10k+ Postman


Joined: Feb 19, 2001
Posts: 28194
Location: Wisconsin USA

Quote:

I imagine the tipping-point where scalable beats raster is for very large fonts indeed.

I've only done a couple of GCLD apps. Given the font storage size issue as is under discussion here, I stored only a partial font with the characters I needed and limited myself to a couple sizes.

I could certainly envision an app that wanted to display arbitrary strings and require a more-or-less full displayable character set. Upper+lower+numbers and space and period is 64. Add some other punctuation and symbols--say, 96? 80?

Now say you want it in several sizes. Keep it practical...say, x1/x2/x4. Three or four sizes?

So, where would the "breakeven" be to render a single font at several sizes and have it look good at x4?

Just noodling...
 
 View user's profile Send private message  
Reply with quote Back to top
joeymorin
PostPosted: Sep 04, 2013 - 05:58 PM
Raving lunatic


Joined: Jul 17, 2012
Posts: 2276
Location: Location, Location

theusch wrote:
I've only done a couple of GCLD apps. Given the font storage size issue as is under discussion here, I stored only a partial font with the characters I needed and limited myself to a couple sizes.

I could certainly envision an app that wanted to display arbitrary strings and require a more-or-less full displayable character set. Upper+lower+numbers and space and period is 64. Add some other punctuation and symbols--say, 96? 80?

Now say you want it in several sizes. Keep it practical...say, x1/x2/x4. Three or four sizes?

So, where would the "breakeven" be to render a single font at several sizes and have it look good at x4?

Just noodling...
A look at a simple non-serifed font like Arial shows it to be 266 KB (TTF format).

Looking at the font in FontForge we see the entry for the lower-case letter 'l' is described by 4 (x,y) points that are the endpoints of 4 joined lines.

The upper-case letter 'O' is described by 24 (x,y) points used to generate two concentric splines.

The special character '@' is described by 61 (x,y) points.

The average of the 3 characters is about 30 points. Let's assume this is excessive, and that a more realistic figure for a font designed for a small display is an average of 20 points per character.

Each point is represented by it's co-ordinates, a point type (linear, spline, etc), and some other attributes (angle, curvature, etc). For a simple implementation, let's assume we need only the co-ordinates.

With 20 points, each consisting of 2 co-ordinates, each stored as a 16-bit number, that's 80 bytes.

Add to that the expected code space required to do linear and even simple spline rendering, and we're looking at a fair amount of flash storage.

This is for one of the simpler fonts.

Compare that to a 5x8 1-bit raster font that takes only 5 bytes per character. A 10x16 font (twice the linear size) would take 20 bytes per character. A font family consisting of 5x8, 6x9, 7x11, 8x12, 9x14, and 10x16 would take about 5 + 9 + 11 + 12 + 18 + 20 = 75 bytes per character, but the code footprint would likely be much smaller than that of a scalable font engine.

Mind you, a scalable font implementation for a small display run by an 8-bit mcu wouldn't need all the features available in your average TTF font. You could possibly get away with 8-bit co-ordinates and still get decent results.

Noodles are tasty.

JJ
 
 View user's profile Send private message  
Reply with quote Back to top
Torby
PostPosted: Sep 05, 2013 - 12:43 PM
Raving lunatic


Joined: Nov 11, 2003
Posts: 5781
Location: Broken Arrow OK USA

bobgardner wrote:
Yikes. A byte per pix. But I guess that makes sense if one has an 8 bit pixel. So each 10x11 char is 110 pix, 110 bytes, and you look up the 565rgb in a lookup table and draw the rgb pix?


That would be scary. I use a bit per pix.

_________________
Torby

You can't always believe everything you think.
 
 View user's profile Send private message Visit poster's website 
Reply with quote Back to top
bobgardner
PostPosted: Sep 06, 2013 - 01:53 PM
10k+ Postman


Joined: Sep 04, 2002
Posts: 23451
Location: Orlando Florida

Hope this idea helps someone

_________________
Imagecraft compiler user
 
 View user's profile Send private message Send e-mail Visit poster's website 
Reply with quote Back to top
Display posts from previous:     
Jump to:  
All times are GMT + 1 Hour
Post new topic   Reply to topic
View previous topic Printable version Log in to check your private messages View next topic
Powered by PNphpBB2 © 2003-2006 The PNphpBB Group
Credits