Trouble implementing GLCD Fonts

Testing/Troubleshooting
1

hi, i´m currently trying to implement an alternative glcd font (12x16), but it won´t work. the letters are not complete, kind of shifted, etc.

if i want to print “button” the display shows half a “p”, half a “w”, some curves which look like "s"s and so on.

 

what i did: i created a bitmap (192x128 px), exported it to *.xpm, converted it with convpix_c.pl to *.inc, added the header bytes (width, height,…) and renamed the file to *.c.

 

i managed to implement the additional font into the mb_ng firmware and into the glcd driver, “&1” and “&2” now activate the additional fonts i created, everything peachy so far. so i think the problem must be with the fonts. 

 

which font sizes are supported? i know the height must be devidable by 8 (so 8,16,24,…), is this also the case for the width? is there something wrong with the *.xpm i created? i attached it if someone wants to take a look. is there something else i am missing?

 

thanks

[mb_font_12x16.rar](< base_url >/applications/core/interface/file/attachment.php?id=10422)

2

There are no constraints for the width… unfortunately you forgot to pass the most important part: the .inc file with the header definitions.

Probably only the header values are wrongly set.

 

Best Regards, Thorsten.

 

P.S.: please don’t distribute .rar files, they are hard to use on operating systems != Windows

3

Hi Thorsten, thanks for the reply.

 

here is what i wrote into the *.inc file

 

// converted with 'convpix mb_font_12x16.xpm'

#include <mios32.h>

const u8 MB_FONT_12x16[] = {
12, 2*8, 0, 12, // width, height, X0 offset, char offset

0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,.... };

after that i renamed it to “mb_font_12x16.c” and compiled the mb_ng firmware.

 

Today I tried it with a 16x16 font, but i had the same result.

 

P.S. Sorry about the RAR, i will remember that.

 

 

EDIT: i just went over the whole procedure again just to make sure:

 

  1. created the *.xpm file

  2. converted it with convpix_c.pl to *.inc

  3. added the header bytes above

  4. renamed the *.inc file to *.c

  5. compiled mb_ng firmware

 

-> same result

 

i attached the font file i created.

[mb_font_12x16.c](< base_url >/applications/core/interface/file/attachment.php?id=10423)

4

EUREKA!!! i got it!

 

i looked into the original font files again and i noticed, that i forgot to pass the additional parameters " -icons 16 -height 16" on to the cmd terminal while converting the *.xpm file to *.inc.

many thanks for the help.

 

greetings

5

I came across another problem i don´t get my head around. i experimented with an inverted font and there are strange artifacts appearing on other glcds.

 

<___base_url___>/gallery/image/1786-john-e-finster-strange-artifacts-on-glcd/?do=embed

 

i attached both font files i used. other fonts (non-inverted) i created are displayed without problems.

[mb_font_6x8_inv.c](< base_url >/applications/core/interface/file/attachment.php?id=10454)

[mb_font_12x16_inv.c](< base_url >/applications/core/interface/file/attachment.php?id=10455)

6

The mystery of the artifacts continues… :o

 

Seriously, i did some additional testing on this matter and a general pattern is starting to reveal itself.

After some experimening with different sizes and characters it seems that the artifacts only appear if the first vertical pixel line of a character has a 0xff byte in it and some special conditions are true.

I will try to explain what I mean by reffering to the <font>.c file:

 

If a character starts with

 

0xff,…    (font height 8px)

 

or 

 

0xff,…    (font height 16px)

0xff,…

 

then the artifacts are always there.

If a character (font height 16px) starts with

 

0xff,…  

0x7f,… (e.g.)

 

then the artifacts are only there if the character is placed on an even line (like “lcd_pos=1:1:2”)

If a character (font height 16px) starts with

 

0xfe,…  (e.g.)

oxff,…

 

then the artifacts are only there if the character is placed on an uneven line (like “lcd_pos=1:1:3”)

 

That´s it so far. I can work my way around this, i just have to avoid characters that start with a 0xff byte. This limits my design ideas a little but I can work with this. At least I have a pattern now, that I can take into account when I´m designing more fonts.

7

Needs more analysis at my side, need your files (and some time)

 

Best Regards, Thorsten.

8

Hi Thorsten, thanks for stepping in.

 

I attached the files i modified and all the <font>.c and <font>.xpm files I created. For better overview over my little font project I put the fonts in dedicated folders. You will see if you open the glcd_font.mk.

 

Greetings

 

P.S. Sorry, I forgot. Are *.Zip files ok?

[fonts project.zip](< base_url >/applications/core/interface/file/attachment.php?id=10481)

9

Ok, now I only need the time to analyze this…  :unsure:

(I’m on a business trip next week, and on holiday thereafter… if I don’t feel boring it could be that I can’t check this before april)

 

Best Regards, Thorsten.

10

Take your time, I´m not in a rush. I have some work coming up, too.

Even with this current font behaviour I can work on some ideas, so no need for a quick fix here.

 

Thanks for the effort and have a nice holiday.

 

Greetings

 

John

11

Thanks for your understanding!

Please keep this thread updated whenever you find new infos - because from my point of view there is no reason why this shouldn’t work (beside of .xpm conversion issues with a script that I wrote 18 years ago - take it as it is, and try to workaround any conversion issues)

 

Best Regards, Thorsten.