bit mapped fonts for lcd displays in stock

I am using a 3.5: TFT LCD display with an Arduino Uno and the library from the manufacturer, the KeDei TFT library. The library came with a bitmap font table that is huge for the small amount of memory of an Arduino Uno so I"ve been looking for alternatives.

What I am running into is that there doesn"t seem to be a standard representation and some of the bitmap font tables I"ve found work fine and others display as strange doodles and marks or they display upside down or they display with letters flipped. After writing a simple application to display some of the characters, I finally realized that different bitmaps use different character orientations.

What are the rules or standards or expected representations for the bit data for bitmap fonts? Why do there seem to be several different text character orientations used with bitmap fonts?

Are these due to different target devices such as a Windows display driver or a Linux display driver versus a bare metal Arduino TFT LCD display driver?

What is the criteria used to determine a particular bitmap font representation as a series of unsigned char values? Are different types of raster devices such as a TFT LCD display and its controller have a different sequence of bits when drawing on the display surface by setting pixel colors?

Is there some method other than the approach I"m using to determine what transformation is needed? I currently plug the bitmap font table into a test program and print out a set of characters to see how it looks and then fine tune the transformation by testing with the Arduino and the TFT LCD screen.

I"m not fully conversant with the standard descriptions of bitmap fonts however I think of this as being an 8x16 bitmap font in which each character is 8 pixels wide and 16 pixels in height or an 8x16 bitmap font.

With the size of this table and the small amount of memory on the Arduino Uno, I started hunting for other bitmap fonts that would be legible while also taking up less memory. See reducing memory required for KeDei TFT library used with 3.5" TFT display with Arduino

What I hoped to find was something around a 6x6 bitmap font so that the definition of the bitmap font table would change from const unsigned char font_table_16_col[96][16] = { to const unsigned char font_table_16_col[96][6] = { which would free up a significant amount of memory. And experiments with cutting the table down by removing lower case letters showed that helped as well.

Finding alternative bitmap fonts has been more difficult than I thought, envisioning someone with the motherlode of bitmap fonts in a GitHub repository somewhere, easily found with a search or two.

What I have run into is that while I have found several different examples of bitmap fonts not all seem to be compatible with my specific 3.5" TFT LCD display.

For instance here are representations of four different bitmap fonts showing the bits of the bitmaps for two characters, the exclamation point (!) and the double quote ("). The 5x8 seems to be rotated to the clockwise by 90 degrees. The 8x8 and the 16x8 seem to be oriented correctly and the 13x8 seems to be upside down.

The bitmap font representations in the image above, showing the differences in text character orientation, were generated by a simple Windows GUI and displayed with a dash (-) representing a bit value of zero and an asterisk (*) representing a bit value of 1. This is the output of a Microsoft Windows GUI application whose WM_PAINT message handler which draws the displayed image is as follows:

I have modified the code that displays text using the bitmap fonts so that for a particular bit map the character drawing logic will perform several different kinds of translations between the bitmap font representation as a series of hexadecimal digits and how the series of digits are used to determine which pixels to turn on and which to turn off.

The code for drawing a single line of a character is as follows. The outline of this function is to provide to the LCD controller a rectangle specifying the region of the display to be modified followed by a series of two 8 bit writes to set the two byte RGB565 color value of each of the pixels in the region.

static bool TFTLCD::draw_glyph(unsigned short x0, unsigned short y0, TftColor fg_color, TftColor bg_color, unsigned char bitMap, unsigned char bmWidth, unsigned char flags)

and the source code that uses the above function for drawing a complete characters is as follows. This code uses the drawGlyph() function to draw a series of slices of the text character from top to bottom. When a bitmap transformation is done depends on the bitmap representation.

TFTLCD::draw_glyph(Font::now_x, Font::now_y, Font::font_color, Font::txt_backcolor, Font::font_table.table[char_i_x + char_m], Font::font_table.nCols, glyphFlags);

TFTLCD::draw_glyph(Font::now_x, Font::now_y, Font::font_color, Font::txt_backcolor, Font::font_table.table[char_i_x + char_m], Font::font_table.nCols, glyphFlags);

TFTLCD::draw_glyph(Font::now_x, Font::now_y, Font::font_color, Font::txt_backcolor, Font::font_table.table[char_i_x + char_m], Font::font_table.nCols, glyphFlags);

TFTLCD::draw_glyph(Font::now_x, Font::now_y, Font::font_color, Font::txt_backcolor, Font::font_table.table[char_i_x + char_m], Font::font_table.nCols, glyphFlags);

TFTLCD::draw_glyph(Font::now_x, Font::now_y, Font::font_color, Font::txt_backcolor, Font::font_table.table[char_i_x + char_m], Font::font_table.nCols, glyphFlags);

TFTLCD::draw_glyph(Font::now_x, Font::now_y, Font::font_color, Font::txt_backcolor, Font::font_table.table[char_i_x + char_m], Font::font_table.nCols, glyphFlags);

There are a number of font specifications including rasterized bitmap type fonts. These specifications do not necessarily describe the glyph bitmaps used in application such as the KeDei TFT library but rather provide a device independent description of a bitmap font format.

Oracle in Solarix X Window System Developer"s Guide, Chapter 4 Font Support at https://docs.oracle.com/cd/E19253-01/816-0279/6m6pd1cvk/index.html has a table listing several different bitmap font formats and has this to say:

Here’s a neat little trick: take the jaggies out of scaled fonts on the fly! This technique is for use on graphic displays where you might want to scale your fonts up. Normally you’d just write a 2×2 block of pixels for every area where there would have been one pixel and boom, larger font. Problem is, that also multiplies each empty area and you end up with jagged edges in the transitions that really catch your eye.

The technique has been packaged up in a simple function that [David] wrote to play nicely in the Arduino ecosystem. However, the routine is straightforward and would be quick to implement no matter the language or controller. Keep this one in your back pocket!

Now if all you have on hand is an HD44780 character LCD, that one’s arguably even more fun to hack around on just because you’re so limited on going beyond the hard-coded font set. We’ve seen amazing things like using the custom character slots to play Tetris.

Currently I am working on the deluxe version of the data logger. This version has a LCD screen and capacitive buttons to control the software. The Adafruit library for the display is quite large and almost uses the whole RAM, because it is a pixel oriented library. My own implementation is a text only library using 8×8 pixel characters. This simplify everything and reduces the RAM costs.

To convert the bitmap font into bytes, I wrote a small application for OS X (minimum version 10.10). It accepts a PNG image with the characters in it and converts it into bytes with the correct bits set.

First you select the mode on the left side of the application window. In this example the mode is set to “8×8 Fixed Top-Down”. Select the output format in the bottom left corner of the window.

Here an example 8×8 pixel font file for the converter. The font converter ignores any transparent and light values. So you can use them on a second layer as a grid for the font.

You can use this font template for Adobe Photoshop if you plan to deign a own font. The template uses a grid on one layer, so you can draw the font information on the second layer.

The software is written in Swift 2 and is using many of the new features of this language. The code is extensible and you can easily add own converter and output formats. If you created useful additions, please let me know.

This page describes the SGX-120L"s fonts and instruction set. For hookup, configuration and specifications, please see the hardware reference. These instructions apply to SGX-120L, version 2.0 and later. For a summary of differences from the earlier versions, see the upgrade guide.

The SGX-120L is a 120x32-pixel graphics LCD with a 9600bps serial interface. It can store a customizable font and 15 full-screen bitmap images in its flash memory. The SGX has four font sizes that can be mixed on the screen, and can draw lines and plot points. This page describes the control codes that format text and the escape codes that download, draw and store graphics.

SGX-120Ls accept asynchronous serial at 9600bps, 8 data bits, no parity, 1 or more stop bit(s), often called "N81." They will accept RS-232 input, inverted TTL, or non-inverted TTL. Non-inverted TTL requires cutting the SPol jumper on the circuit board. See the hardware reference for further information.

SGX-120Ls accept character codes 32 to 191, with the lower codes (< 128) corresponding to the standard ASCII character set. Characters can be added or changed by editing the .BMP graphics stored in pages 0 and 1 of the display"s memory. (In the character set shown below, the higher codes, 128+, contain guidelines for designing your own characters). See here for more information on downloading bitmaps.

Any pair of stored bitmaps can be used as a font; the display controller selects a 6x8-pixel chunk of the selected bitmap according to the character code received and displays it on the screen in the current font size and position. See ESC-F in the Escape instructions below.

SGX-120L offers multiple font sizes, which can be freely mixed on the screen. The following screen layouts show position values for the various font sizes. Positioning (ctrl-P below) works in terms of the font-size in effect at the time. In the illustrations below, position = row + column.

SGX-120Ls understand a small set of control codes that format incoming text. Some are standard (carriage return, backspace, tab) and others are display-specific (position, right-align, backlight on/off). Codes not listed below (e.g., Null, 0) are ignored by the display.

For example, you clear the screen and send the text Hello— Hello appears at the upper left of the screen, in positions 0-4. Now you send ctrl-A, followed by J— Hello becomes Jello.

Screen positions are in terms of the font size in effect at the time, so the range is 0-79 for the 4x20 font and 0-19 for the 2x10 font. It"s not recommended for programming purposes, but you can also use a text number like "24" to specify ctrl-P position values. Text numbers must be followed by a throwaway character—like a space or a period—which will terminate the number but won"t be displayed.

Displays text (usually numeric) within a field 2 to 8 characters wide. The byte that follows ctrl-R is a text number from "2" to "8" (50-56 dec, 0x32-0x38 hex) that sets the field width. The text after that will be invisibly stored until one of the following is received:

These are multipart instructions that begin with the Escape character; 27 dec, 0x1B hex. Escape instructions work with graphics and/or memory: downloading/storing/recalling bitmaps, plotting points and lines, setting startup configuration.

Numbers Used in Escape Instructions:Many Escape instructions accept number(s) to specify coordinates, screen pages, etc. The standard way of specifying numbers is as a single byte set to 64+n, where n is the desired number. For example, the value 123 decimal (0x7B hex) is sent as a byte containing 123 + 64 = 187 decimal (0xBB hex). However, most numbers can also be sent as a text string such as "123." (i.e., four bytes set to the ASCII codes of the printable numbers and the period: 49 50 51 46 decimal (0x31 0x32 0x33 0x2E hex). This allows you to type instructions from a terminal program for demonstration purposes. It is not recommended for programming, as it uses multiple bytes when one would do. It is deprecated and may not be supported by future products.

Specify the screen address to be used by Escape B. ESC A (uppercase A; 65 dec, 0x41 hex) x y where x is 0-119 (the width of the screen) and y is 0-3 (height of the screen/8 bits). Both x and y are sent as a byte set to 64+n, where n is the coordinate value.

There are few practical applications for writing individual bytes to the screen. With instruction overhead, it"s very slow. A much better way to put a bitmap on the screen is to download it to the display (Escape D G), store it in flash memory (Escape X n) and either recall the entire screen using Escape E n, or set it as a font (Escape F n) and display 6-byte chunks using regular ASCII characters.

Download a bitmap graphic to the screen. ESC D (uppercase D; 68 dec, 0x44 hex) G (uppercase G; 71 decimal, 0x47 hex) followed by 480 bytes of data. These bytes map to the screen left to right and top to bottom. Byte values are 0-255 (0x00-0xFF hex). See here for more information on downloading bitmaps.

The bitmaps that the SGX uses to draw individual characters are stored as a pair of full-screen images. Each character occupies a 6x8-pixel block. An SGX font can have up to 160 characters corresponding to ASCII codes 32 to 191 decimal (0x20 to 0xBF hex). The default font is in screen pages 0 and 1, but using Escape F you can instruct the SGX to use other stored bitmaps as the font source. These alternative fonts don"t have to be letters and numbers— you can use them as 6x8-pixel graphical icons (or larger graphics by tiling multiple characters). Here are the font-source values:

To change the font size and font source, add the values together. For example, to use tall (6x16-pixel characters) from stored bitmaps at pages 4 and 5, you would use the value 2 + 8 + 64 (where 2 sets the size, 8 sets the font pages, and 64 is the magic number that"s added to most escape-code arguments).

Set the mode for points and lines to n — OR (0) or XOR (1). ESC M (uppercase M; 77 dec, 0x4D hex) n. Add 64 to n. In OR mode, dark pixels always print dark; in XOR mode, dark pixels print dark on a light background and light on a dark background. Light pixels always print light regardless of this setting.

You can highlight multiple lines by adding together the values of n from the table; for example, to highlight the top and bottom lines n=1+8 (+64, as usual). To eliminate all highlights, use n=0 (+64).

Draw a line from the end of the last line drawn to the specified x y position. ESC T (uppercase T; 84 dec, 0x54 hex) x y where x is 0-119 and y is 0-31 (add 64 to x and y). Line-to is a handy shortcut for drawing simple connect-the-dots graphics (e.g., boxes) or graphs.

Set the vertical origin to the top or bottom of the screen. ESC V (uppercase V; 86 dec, 0x56 hex) n, where n is 0 (+64 for top of screen) or 1 (+64 for bottom).

Write configuration settings that automatically take effect when the display is powered up. ESC W (uppercase W; 87 dec, 0x57 hex) n where n specifies the startup options from the table. Add 64 to n. See here for a Windows software tool that automates the configuration process.

You can combine settings by adding values of n from the table; for example, to have the display start with the backlight on and the large (tall and wide) font in effect n=1+8+16 (+64, as usual). To turn off all startup options, use n=0 (+64). Note that ESC W works only when the Dsu (Display setup) jumper is uncut. When the display is set up the way that you want it for long-term operation, cut the jumper to prevent accidental configuration changes.

Options written by ESC W replace previous settings, they do not add to them. For instance, if the SGX is currently set to start up with the backlight on and you want it to also show the page 2 bitmap, you must send an ESC-W instruction with both options (27 87 67 dec, 0x1B 0x57 0x43 hex).

Store the current screen to the specified page of flash memory. ESC X (uppercase X; 88 dec, 0x58 hex) n where n is the screen page 0-16 (+64). Once a screen is stored, it can be recalled to the screen using ESC E. Note that screen pages 0 and 1 are the display"s default font--if you store a non-font bitmap to these locations text will print as blocks of that bitmap, not as recognizable letters an numbers. For this reason, the display ships with pages 0 and 1 write-protected. You can undo this safeguard (to alter the font) using ESC W above.

This is especially useful when using small resolution characters (say for instance a 4-wide by 6-tall 24 pixel character cell) and you need to tweak the characters to make them legible.

Here.... I"ll even give you a set of hand-crafted character sets....http://e2e.ti.com/cfs-file.ashx/__key/communityserver-discussions-components-files/166/4530.character_5F00_sets.zip I can no longer find the spreadsheet though... I believe each byte is a row in the character, and the bits are used left to right.

This topic details the font file format used by the lcd. object. The font file is a resource file that is added to your Tibbo BASIC/C project. Like all other resource files "attached" to your project, font files are accessible through the romfile. object. The use and interpretation of font file data, however, is the responsibility of the lcd.object; the romfile. object merely stores these files.

16-bit character sets usually have large "gaps" (i.e., areas of unused codes). The TRF format offers an efficient way to define which characters are included into the font file and allows for very efficient character searching within the file.

Support for fonts with anti-aliasing. Anti-aliasing is achieved by adjusting the "intensity" (brightness) of individual pixels. In an anti-aliased font, each pixel of a character bitmap is represented by 2 or more bits of data. Fonts without anti-aliasing just need 1 data bit/pixel because each pixel can only be ON or OFF. TiOS currently supports only fonts with 1 bit/pixel.

Support for vertical and horizontal character bitmap encoding. Displays with lcd.bitsperpixel = 1, 2, or 4 pack 8, 4, or 2 pixels into a single byte of display memory. Problem is, some displays combine the pixels vertically (see drawing A below) and some horizontally (drawing B). The text output on such displays is more efficient if character bitmaps of the TRF file use the same direction of packing.

Contains various information such as the total number of characters in this font, character height, etc. Also contains the number of code groups in the code groups table (see below).

Contains descriptors of "code groups." Each code group contains information about a range of codes that has no "gaps" (i.e., unused codes in the middle). The font file can have as many code groups as necessary.

Contains addresses (offsets) of all character bitmaps in the TRF file. In combination with the code groups table, provides a way to find the bitmap of any specific character.

Contains all bitmaps of each character included into the font file. The width of each bitmap is defined individually and is stored together with the bitmap.

This table has a variable number of entries. This number is stored in the num_of_groups field of the header. Each code group represents a range of codes that contains no gaps (no unused character codes in the middle). For example, suppose that we have a font that only contains the characters "0"~"9" and "A"~"Z"; this font file will contain two groups of codes: 0030H through 0039H ("0"~"9") and 0041H through 005AH ("A"~"Z").

Address (that falls within the bitmap offset table and is given with respect to the beginning of the file) at which the address of the bitmap of the first character in the code group is stored.

Here is how the above data was calculated. The start codes are obvious. Group one starts with code 0030H because this is the "0" character code. The second group starts with the "A" character code. It is also easy to fill out the number of codes in each group: 10 (000AH) for "0"~"9" and "A"~"Z" represented by 26 (001AH). The bitmap_addr_offset calculation is explained in the next section.

This table has the same number of entries as the total number of characters included in the font file. Each entry consists of one field — a 32-bit offset of a particular bitmap with respect to the beginning of the font file. Now you can see how we were able to calculate the data for the bitmap_addr_offset field of the code groups table. The header of the font file has a fixed length of 16 bytes. There are two code groups in our example, so the code groups table occupies 8 x 2 = 16 bytes. This means that the bitmap offset table starts from address 16 + 16 = 32 (0020H). Hence, the first entry in the code groups table points at address 0020H. The first code group contains 10 characters ("0"~"9"). These will "occupy" 10 entries in the bitmap offset table, which results in 10 x 4 = 40 bytes. Hence, the bitmap_addr_offset field for the second code group is set to 32 + 40 = 72 (0048H).

Each bitmap starts with a single byte that encodes the width of the bitmap in pixels, followed by the necessary number of bytes representing this bitmap. Depending on the pixels_per_byte field of the header, each byte of data may encode just one or several pixels. Additionally, when using more than 1 pixel-per-byte encoding, the orientation field of the header defines whether pixels are combined horizontally or vertically.

The drawings below illustrate how character bitmaps are stored in the font file. As an example, characters of 10x14 size (in pixels) are used. Drawing A is for one pixel/byte encoding, drawing B is for 8 pixels/byte with vertical orientation, and C is for 8 pixels/byte with horizontal orientation. Notice that for cases B and C, a portion of some bytes used to store the bitmaps is unused. Offsets of bytes relative to the beginning of the bitmap data are shown with a "+" sign.

Bitmap A takes 140 bytes. The first byte (+0) represents the pixel at the top left corner of the bitmap. Subsequent bytes represent all other pixels and the order is "left-to-right, top-to-bottom."

Bitmap B takes 20 bytes. The first byte encodes 8 vertically arranged pixels at the top left corner of the bitmap. Subsequent bytes represent all other pixel groups and the order is "left-to-right, top-to-bottom." There are two rows of bytes, and bits 6 and 7 of each byte in the second row are unused.

Bitmap C takes 28 bytes. The first byte encodes 8 horizontally arranged pixels at the top left corner of the bitmap. Subsequent bytes represent all other pixel groups and the order is "top-to-bottom, left-to-right." There are two columns of bytes, and bits 2~7 of each byte in the second column are unused.

Here is how a target character bitmap is found within the font file. Again, we are using the example of the font file that contains the characters "0"~"9" and "A"~"Z."

Suppose we need to find the bitmap of character "C" (code 0043H). First, we need to see to which code group code 004AH belongs. We read the num_of_groups field of the header to find out how many code groups are contained in the font file. The field tells us that there are two groups.

Next, we start reading the code groups table (located at file offset +00000010H), entry by entry, in order to determine to which code group the target character belongs. The first group starts from code 0030H and contains 10 characters. Therefore, the target character doesn"t belong to it. The second group starts from code 0041H and contains 26 characters. The target code is 0043H. Therefore, target character belongs to this second group.

At this file offset, the first byte will be the width of the bitmap in pixels. Based on this width and also the height, pixels_per_byte and orientation fields of the header, we can calculate the number of bytes in the bitmap. For example, suppose that height= 14, pixels_per_byte= 0 (8 pixels/byte), and orientation= 0 (pixels are grouped vertically). Also, let"s suppose that the width of the target character is 10 pixels. In this case, the bitmap will occupy 20 bytes, as shown in drawing B above. Two bits of each byte in the second byte row will be unused.

The Dot Factory is a small open source tool (MIT licensed) intended to generate the required C language information to store many fonts and images, as efficiently as possible, on a microcontroller. These fonts are then uploaded via the LCD driver (see the Drivers and Modules page for a few) to the actual dot matrix LCD. It is written in C# for Visual Studio 2008 and has been tested on Windows XP, 2003, Vista, 7 and Linux via Mono.

Working with dot matrix LCDs with microcontrollers, while not difficult, is tedious. The actual LCD controller allows us to upload simple visual data (dot on or dot off) into the LCD’s dot matrix, but not much else. It is up to our software to decide what to upload when we want to draw lines, circles and more importantly – text.

While there are software graphic libraries that allow us to generate a character “on the fly” using vector graphics (the character is described as a series of drawing commands that allow scaling and decoration) – these are much too complex and large to integrate in a microcontroller environment. Consequently, we must store the exact appearance of a character as a series of 1s and 0s, equivalent to a “dot on” “dot off” on the LCD, and upload this as a bitmap when we want to display text. While it is possible to generate this manually, it is desired to have a tool to do our grunt work by converting windows fonts (given a size and decoration) into a series of bitmaps.

TDF is comprised of two panes – the input pane on the left (what you want to generate) and the output pane on the right (the generated output, in C code). The input pane can accept either a font of your choice (for writing text to the LCD) or an image. When generating a font, you have the option of either generating all the available letters (by selecting “All” in the Insert Text box and clicking the plus button) or by typing in which letters, numbers or symbols you are actually using in your application (for example: 0123abcd). If you are writing a simple application that has only a few sentences, you can type them wholly in this box without fear of duplicating letters – TDF takes care of that by discarding any duplicates. This way only the letters you use will take up space.

Once you have completed setting up what it is you’d like to generate (be it an image or font), select the output method in the output pane. If you are using the LCD drivers on this website, you want it to generate an MSb first output, otherwise images will come out wrong. If you have a compiler that supports the “0b” binary specifier, you can select “binary” rather than “hex”. This will allow you to visually see the pixels you will set and allow for manual touch up by the user without having to calculate hex and experimentation. Click generate and your C code will be outputted to the text box below. Copy paste this into your application (it is recommended to put this in a separate module, not your LCD driver module, for organizational reasons).

Note that 5×7 and 5×8 fonts cannot be generated using this tool. While some TTF fonts can render characters this small they are usually distorted to the point of uselessness. You can download a ready made five by seven font here. I ripped this font from text file a while ago, so apologies to the uncredited author.

The character bitmap array: This holds the actual characters as a bitmap (only the characters selected in the input pane). Each byte represents a single vertical page sent to the LCD. All vertical padding is removed from the characters

The character descriptor array: Allows O(1) mapping between a character’s ASCII value and required meta information about the character – namely its width in bits and its offset into the character bitmap array. When the LCD driver needs to find where character X is located in the bitmap array, it will jump to index [X - font.startCharacter] in the descriptor array. The startCharacter is the first character (that is, the character with the lowest ASCII value) used for this font. By defining a startCharacter we can reduce the number of elements in the descriptor array.

The font information: This element is essentially the font descriptor for this font. It holds information regarding this font like the name of the character bitmap and descriptor arrays, the font start character and how many pixels wide a space character is for this font. The LCD driver will replace the space character with empty pixels (this saves both processing time, space in the character bitmap array and space in the character descriptor array – since the space is the first ASCII character and is commonly used).

The generated structures are generated with documentation, but you may want to see a sample bitmapDb header file for detailed info on the character descriptor array and font information structures. For image generation, only the image’s bitmap array and size descriptors are generated. Note that the height value is pixels (bits) and width values are in pages.

Version 0.1.2 (29may11): Fixed width/height being swapped. Added support for configuring image descriptor format (bits/bytes). Thanks geo for the heads up and suggestion

Version 0.1.1 (25may11): Added support for multiple descriptor arrays with a double lookup. Before this version TheDotFactory could generate Unicode characters but the lookup tables were usually too huge to be of any use. Using this feature, a double lookup is employed, allowing for fast lookups for characters residing at disparate ranges. See the video for an explanation (will be posted in the next few days). In addition to this, added support for specifying character ranges instead of inputing the actual characters. For example, <<100-120>> will generate characters for ASCII characters 100 to 120. Thanks a bunch to Archis Bhave for inputs and testing. Source is now distributed via github.

Version 0.1.0 (15dec10): Added support to format the generated variable names (thanks SpiralBrain), added end character indication to font information (thanks Nick Jensen), added the ability to save to clipboard from File menu and added the ability to save the source/header to file via file menu (don’t remember who, but someone wondered why this wasn’t in. I personally think all fonts should be in a single module and so I opted for copy/paste, but to each his own)

Version 0.0.7 (28may10): Added ability to select whether character descriptor array is to be created and which character will be used to visualize the font (thanks Christian Treczoks), syntax coloring automatically disabled when generating large amounts of text (will be fixed properly next version), properly handled bitmaps with no black pixels in them (displays error instead of a crash), some minor cosmetics

Version 0.0.6 (03mar10): Bug fix for image generation (tried to save a temporary file for debugging in a custom directory) – thanks to Nir Shemeshfor pointhing this out!

Version 0.0.5 (23dec09): Added support for rotation (90 degree increments), space character generation, width (bit/byte) selection of character width and font height, optional generation of character height/width and font height, structures are now generated with documention, input text and font is persisted throughout invokations of the application, persistent preset management – add, edit, delete output configuration presets

To run this executable, you must have the .NET framework installed. The stable binary has been in the wild for a month at least with no major bugs reported. Non stable binary contains new features and bug fixes (see revision history).

Current incarnations might be available for large LED displays, but those may work best for point LEDs rather than square filled pixels, and ideally these would be something recognizable by some as having historical aspects.

The application is a small 128x64 pixel OLED display. I currently use Python"s PIL which has a "default" font that is just too small for this display. I can also use it to read TrueType fonts, then I down-convert to gray scale then use a threshold to get 1-bit, but it looks ragged. See here and here but here I"m not asking for Chinese characters; even the original ASCII would be helpful.

Example of a 1-bit binary OLED display (128x64 pixels) cropped from this image from the AdaFruit Page Monochrome 0.96" 128x64 OLED graphic display, Product ID: 326.

These days even black-and-white fonts are displayed using grayscale or even color. Zoomed screenshots from my laptop showing that what looks black-and-white isn"t. Trying to post-process these back to binary by thresholding can lead to rough edges and strange looking characters.

This website is using a security service to protect itself from online attacks. The action you just performed triggered the security solution. There are several actions that could trigger this block including submitting a certain word or phrase, a SQL command or malformed data.

I am looking for a font to use on a small (75x55mm) LCD display. The display supports 5 bit grey scale, so anti-aliasing is possible. Unfortunately it is only about 80ppi and standard anti-aliasing like below doesn"t look very good:

I am using Paint.NET, perhaps another app would give me greater control over the anti-aliasing. There are some limitations to the font rendering I can do because it is an embedded system, so for example no per-character kerning or on-the-fly rendering/anti-aliasing.

I was hoping to find an anti-aliased bitmap font suited to industrial LCD displays. Something that is designed to look good at around 10-12 pixels high. Serif or sans-serif, either is fine. Back in the day when most operating systems used bitmap fonts there were some nice ones for the Amiga and Mac OS, but I can"t find them now.

Just to clarify, the font sample above looks bad because it doesn"t stick the pixel grid of the LCD. It is probably fine on an RGB LCD seem from a greater distance, but on industrial LCDs you can see that the vertical lines of the letters are blurred. The C looks okay, but the H, I, J, K, L, M and N all look a bit blurred.

My application involves printing some large bitmaps, enough to cover the whole screen. Problem is, bitmaps take up a lot of progmem space. I know I can store bitmaps on the SD card and print from there, but I"d rather use cbm80amiga"s RREfont bitmap solution because of the flexibility, speed, and scalability of the graphics. I already use the RREfont library for displaying text in an efficient way on the screen, and I was able to find the example in the video linked above. I need to be able to recreate that video with my own custom image, that"s the goal.

I understand how this example is working- a bunch of custom RREfonts were generated from a base bitmap (rre_mario0.h, rre_mario1.h, rre_mario2.h, etc). One of these fonts is generated per color on the original bitmap image. Those fonts are loaded in, and printing characters like " " or "!" print the bitmap as if they were text (text that happens to be shaped like Mario). I"m really impressed with the speed, and at how efficiently this entire mario bitmap image is stored in Progmem. Very ingenious solution- I just don"t know how to get my OWN bitmaps into RREfont formats.

When I open up one of the "fonts" (mario0.h for example), I see it mentioning "generated by RREfontgen". So I checked that out,here it is. Got it downloaded, and I figured out how to use cmd to navigate to that folder and execute commands listed in the github.

What I don"t know is- how do I use this rrefont software to go from my own bitmap image into files equivalent to the rre_mario0 font files used in his examples? Honestly, I need a bit of a step-by-step guidance for this stage. If I can properly generate those RREFont files, I think I can print them just fine. How did he go from a bitmap of our beloved Italian plumber into the rre_marioX.h files? Everything after that I"ve got a good understanding of.

What I"ve tried: I took a bitmap (some random 32x32 sprite), made it monochrome for sake of being simple. Then, I took a wild guess and converted .bmp to .pbm (because .pbm is mentioned in the rrefontgen github). Tried running the command "rrefontgen image.pbm 32 32 testfont" (following instructions for using rrefontgen in pbm mode). This didn"t work, error said I needed to specify "w and h in pbm file". I expected this, given that these were wild guesses. Thought I"d come ask a more experienced community what I need to be doing here.

I"m decently experienced using Arduinos, but not experienced with more in depth coding, like compiling .c files, using cmd to execute programs, and such. Took a while to learn how to convert a bitmap to a regular byte array for printing on the display the old fashion way. Got that done, but quickly realized that larger bitmaps would eat up my progmem.

This website is using a security service to protect itself from online attacks. The action you just performed triggered the security solution. There are several actions that could trigger this block including submitting a certain word or phrase, a SQL command or malformed data.

Here is a typical font table stored in CGROM memory that contains the character set. A two-dimensional array references the character within. The upper four bits of the byte select the column, and the lower four bits select the row. When you send a byte, consisting of four upper bits and four lower bits, to the WS0010 display RAM an automated function looks up the row and column in this font table and selects the character. Then another automated function called "Character Generator" reads the bitmap data and sets the dots on the physical LCD display according to the bitmap data.

If you want to display the character "A", you can see that the upper bits are LHLL, and the lower bits are LLLL, thus you would send the character code LHLLLLLL or binary "01000000" to the Display RAM. The great thing about this display is that you simply need to send it the character code byte, and the rest of the work of looking up the font table, reading the bitmap, and setting the dots on the display accordingly is performed automatically. This makes the programmers job much easier eliminating the task of manipulating the individual dots.

One of the reasons why people find this difficult to understand is because this is actually an array inside an array. The first array selects the desired character from the font table as shown above. The second array is the bitmap array describes the bitmap structure of the character. Once you have selected your desired character that you wish to display by sending the character code, an automated circuitry takes over and begins reading the second array, which is the bitmap array.

If you are using the factory installed character set in the CGROM, then it is no problem as you can see, however if you wish to use your own custom character set and fonts, then you will need to know the organisation of both arrays and how they link. This information helps to write the routines needed to load the CGRAM with your own custom font table. Luckily, the documentation shows a little of how that works, but very few understand.

I call this the Rosetta stone diagram :-) because there are three things happening here and if you can understand them then the whole thing will make sense. The column highlighted in red shows the contents of the DDRAM memory. As explained earlier, this memory stores only character codes. As explained earlier a character code consists of eight bits where the lower four bits indicate the row, and the upper four bits indicate the column of the font table.

As you can see, bit 3 is not used, which means there are only three bits for the lower part of the byte, and four bits for the upper. Hence, the lower three bits can address eight rows in the font table and upper four bits address 16 columns in the font table. Therefore, permitting 64 characters in a character set font table. This is why the datasheet states CGRAM memory to be organised as 64 × 8-bits.

For the second part of our Rosetta stone, this column describes the CGRAM address. The CGRAM stores the font table, and inside the font table there is the bitmap information of each character. The CGRAM addresses indicated in red are never stored anywhere because it is the same set of repeating numbers counted by the lower 3 bits. It acts like a counter mechanism for addressing purposes, and automated by internal circuitry. Hence, everything highlighted in red appears to be automatic.

The bitmap of each character in this example consists of eight rows, where row 8 is reserved space for the cursor. Since there are only eight rows, only three bits count them. The lower three bits are for the row counting / addressing. Bits 3, 4, 5 are not used at all and simply behave as an index. Each address value can therefore select a row of bit-mapped data. Hence, for example, binary address 000000 fetches the bitmap data for the first row for letter "R", which is "00011110". The address is automatically incremented to 000001, and then brings the second row of data and so forth up to row 7.

When displaying characters defined in the CGRAM, the addressing mechanism / counting is automatic just as it is was when using the CGROM memory; the programmer needs only to send the character code of the character he wishes to display. There is not much information available on how to load this part of the memory with a custom character set, or information on the data structure to use. Once you know the addressing and data are organisation, the same principle of addressing stores bitmap data within the CGRAM. I hope this was useful for anyone learning how to use a WS0010 based display panel.

The most versatile of our graphic displays can be programmed to display any font, in any size, and in any language. With graphic lcd displays you can easily add multi-language support to any application that uses a display. Allow your creativity to flourish with photos and graphics! We also have -1U displays which conveniently fit into any 1U application, allowing you add graphics to even a limited space.

Touch screen graphic lcd display graphic and text in any font, style, justification and language, all with the convenience of a touch screen. Beautiful, easy and fun to use interfaces, all without the need of a keypad. When the touch screen is pressed, you can have the X and Y location sent, or have the on-screen keyboard displayed and touched keys are sent through the serial port. A great looking user interface in no time at all

GTT series is a powerful and feature rich line of full colour UART Embedded  HMI TFT displays with an integrated restive and capacitive touch screens, crafted to become crisp, controllable canvases for creativity to creature fast and beautiful GUI interfaces for HMI systems. Utilizing an extended version of our widely used command library and industry standard communication protocols, the customizable GTT series boasts an intelligent displays that will quickly become the gorgeous face of your application.

Included features, 32MB of RAM, 2GB of onboard memory, piezo speaker and vibratory motor, provide tactile and audio feedback for a comfortable, confident user interaction. Additionally, the field updatable micro SD card stores font and bitmap files to liberate space and resources for use by the microcontroller, Arduino, or other HMI controller.

Pair the GTT series with our free software - GTT Designer - to design screens and user interactions quickly and easily. The software, which is compatible with all GTT displays, is a fully graphical, object-on, drag and drop suite with a library of built-in objects. Including: graphs, charts, buttons and animations. The interface was designed so no technical expertise is required to create a fully interactive user interface in minutes.

Intelligent Graphic OLED display designed to fit into 1U form factors. OLED technology improves readability by offering a high contrast display with wide viewing angles and requires significantly less power to operate than VFD or even LCD units. Engineered to quickly and easily add an elegant graphic HMI to any application. Multiple communication protocols such as Serial RS232, TTL, I2C, USB and RS422 communication models allow the GOK12832A-SM Graphic OLEDto be connected to a wide variety of host controllers. Our Graphic displays provides you with a cost-effective industrial HMI user interface solution for that great product/project you are developing. On board memory for Fonts and Bitmaps! This graphic display displays graphics and text in any font, style, justification and language, all with the convenience of a 25-key keypad matrix will allow fast development for any application.

Most of the languages use Left-to-Right (LTR for short) writing direction, however some languages (such as Hebrew, Persian or Arabic) uses Right-to-Left (RTL for short) direction.