Im currently in a project that need custom high resolution fonts. Despite understanding simple fixed 8 bit fonts used in POVs etc, i cant seem to understand how the fonts generated by GLCD Font Maker are formatted.
Convert the hex values to binary. 0x06 = 0b001100. Now look at the picture. Compare the black and white squares in the top row to the 0 and 1 pattern. See a relationship?
PaulS:
Convert the hex values to binary. 0x06 = 0b001100. Now look at the picture. Compare the black and white squares in the top row to the 0 and 1 pattern. See a relationship?
Doesn't look like any sort of relationship to me other than both happen to have 2 consecutive "1" bits.
Compared on top of each other:
000XX000 - top row
00001100 - 0x06
To me, the 6 looks like some kind of font size indicator then the pixel data follows.
It looks to be stored vertically, where bit 0 is at the top
and the pixels are mapped from bottom to top and then left to right.
For non multiple of 8 sized fonts like this one, it looks like the pixel data
is adjusted down so the unused bits in the pixel data will be off the bottom
or will be the upper data bits of that data byte.
So skip over the 6. you will need to figure out what the byte is later by looking at different font sizes.
Then if you look at the data, it looks like each column moving from left to right is two bytes of data.
In the data pair, the first byte is the lower pixels, and next byte is upper pixels.
In the first byte, bits 6 and 7 are not used (the font size of 14 is not a multiple of 8 ),
then the bits lay down going up.
In the second byte, all 8 bits are used and go up from where the first byte stops
and is the upper 8 vertical pixels.
i.e. the bottom pixel will be bit 5 of first byte the pixel byte pair and the upper pixel will be bit 0
of the 2nd byte of the pixel byte pair.
GLCDs like the ks0108 vertically map their pixels like this. However, for speed you really
want to write the pixel data horizontally within the 8 bit pixel page.
This font format would require that you scramble your read accesses to get the pixel data in that order.
It can be a real challenge to do this along with taking into consideration arbitrary y pixel coordinate alignment.
My openGLCD library takes all this into consideration to minimize glcd data writes
when doing its rendering which is why the font rendering code is so complex.
btw, doesn't that tool let you alter how the font data is stored?
It's been several years since I've used it but I thought it had some options as to how to store the data.
like 16 bit vs 8 bit data elements, horizontal vs vertical, etc...
PaulS:
Convert the hex values to binary. 0x06 = 0b001100. Now look at the picture. Compare the black and white squares in the top row to the 0 and 1 pattern. See a relationship?
Doesn't look like any sort of relationship to me other than both happen to have 2 consecutive "1" bits.
Compared on top of each other:
000XX000 - top row
00001100 - 0x06
To me, the 6 looks like some kind of font size indicator then the pixel data follows.
It looks to be stored vertically, where bit 0 is at the top
and the pixels are mapped from bottom to top and then left to right.
For non multiple of 8 sized fonts like this one, it looks like the pixel data
is adjusted down so the unused bits in the pixel data will be off the bottom
or will be the upper data bits of that data byte.
So skip over the 6. you will need to figure out what the byte is later by looking at different font sizes.
Then if you look at the data, it looks like each column moving from left to right is two bytes of data.
In the data pair, the first byte is the lower pixels, and next byte is upper pixels.
In the first byte, bits 6 and 7 are not used (the font size of 14 is not a multiple of 8 ),
then the bits lay down going up.
In the second byte, all 8 bits are used and go up from where the first byte stops
and is the upper 8 vertical pixels.
i.e. the bottom pixel will be bit 5 of first byte the pixel byte pair and the upper pixel will be bit 0
of the 2nd byte of the pixel byte pair.
---
GLCDs like the ks0108 vertically map their pixels like this. However, for speed you really
want to write the pixel data horizontally within the 8 bit pixel page.
This font format would require that you scramble your read accesses to get the pixel data in that order.
It can be a real challenge to do this along with taking into consideration arbitrary y pixel coordinate alignment.
My openGLCD library takes all this into consideration to minimize glcd data writes
when doing its rendering which is why the font rendering code is so complex.
--- bill
Thanks, its making sense now! To give you a bit of background, im basically wanting to generate fonts for a high resolution thermal printer that prints much like a dot matrix, 384 dots horizontally then next line and so on. Is there a way/program that let me output simple fixed height and width fonts horizontally formatted? As i think parsing this format to work with my application is a slight overkill..Thanks again
Currently the thermal printer hack is working beautifully with Bitmap images! Im using LCD Assistant, that spits out a byte array, by dividing the image horizontally into bytes and then moving onto the next line. Its only font generation that is troubling me, and im hoping a simple process exists for fonts.
You might be able to use their s/w or at least could use use a base
as I'm guessing if it isn't the same, it wouldn't be that difficult to tweak it to work
with yours.
Not quite, i salvaged an old credit card machine, it has a very high resolution printer in it. Yes ive seen that printer, but that is driven serially and i cant find any actual font arrays in their library so i think the fonts are handled by a separate driver IC in the printer so the arduino doesnt have to worry about it. In my case im driving it bare, directly off its ribbon cable.
Ok. I understand.
Have you looked closely at your font tool for data format options?
Many of them have the ability to change how the data is saved
and have the ability to save the data horizontally in the bytes.
But even if you get the font data in the format you want,
the rendering is still going to be a bit of pain
since you have to grab each row of pixel data for each character that is being printed
on the text line as you fill in the pixels for each of the graphic lines.
Not sure which Arduino you are using but
the code could be easier/simpler on something like a teensy 3 where you have tons of memory
and no goofy proprietary AVR PROGMEM to deal with.
With that board, you could have a graphic pixel buffer where you could render multiple graphic lines at a time
that way you could render each full character across the full text line first.
Then send the pixel buffer out graphic line at a time to the printer.
Once you have a buffer, and don't have to deal with PROGMEM, things will get simpler
and whether the font data is horizontal or vertical doesn't matter as much and things
like font scaling (wide, tall, double size, etc..) becomes fairly easy to do.
Thanks for the nice overview, cleared things out :). However, i have thankfully managed all that, and my sketch can read bytes, print, move to next row of bytes etc. Just needed a font format that could integrate with the way my code works. It looks like i found one, its called Dot Factory, and is one of the best ive used till now!
