I have a bunch of code related to producing output to framebuffer devices, which is useful on lower power models which don't work too well with a desktop environment because of limited resources.
Using this code, I have been able to render various graphics shapes, all based around being able to set individual pixels to specific colours, which is essentially what a frame buffer gives you.
This includes being able to render text, from various fonts at different sizes, which in the bad old days was done using bitmap tables, requiring that the font be compiled into the code.
Using Freetype, I developed code that dealt (more or less) with dynamically loading a TrueType font, and then producing output from the bitmaps I was able to derive from that.
Essentially, to draw a single character at a specific position, I use something along these lines:
This will render at the character code chr at x,y on the screen.
Now, for fonts such as FreeMono.ttf and many others, this works well
However, for the Font Awesome 6 OTF, or the Font Awesome 5 TTF files, it doesn't. If I ask for characters outside the normal ASCII range, it gives me an invalid glyph.
I know that the characters are 32 bit, such as 0xf003, so outside the normal ASCII range, and in the live code, chr is typed as uint32_t.
Can anyone give me any clues as to how to start working out what is wrong? I know the font files contain a single face, and multiple charmaps, and I can successfully enumerate the available characters and identify that the characters I want are actually there, but I wonder whether I need to do something different when loading the glyphs?
Another thing that puzzles me is that if I use the font from within a python3/tkinter app, when I display text using the font, it works, including both lowercase and uppercase letters, but the character to glyph mapping seems to suggest that character 'A' and character 'a' both map to glyph#24. This confirms what I see within the ASCII range. How come python can display normal text?
Using this code, I have been able to render various graphics shapes, all based around being able to set individual pixels to specific colours, which is essentially what a frame buffer gives you.
This includes being able to render text, from various fonts at different sizes, which in the bad old days was done using bitmap tables, requiring that the font be compiled into the code.
Using Freetype, I developed code that dealt (more or less) with dynamically loading a TrueType font, and then producing output from the bitmaps I was able to derive from that.
Essentially, to draw a single character at a specific position, I use something along these lines:
Code:
FT_Int idx = FT_Get_Char_Index( f, chr);FT_Load_Glyph( f, idx, FT_LOAD_TARGET_MONO|FT_LOAD_RENDER);FT_Bitmap* pBM = &(f->glyph->bitmap);unsigned char*p = pBM->buffer;int bl = y - f->glyph->bitmap_top;int col = x + f->glyph->bitmap_left;for(int bi = 0; bi < pBM->rows*pBM->pitch; ){ int w = 0; for(int c = 0; c < pBM->pitch; c++) { for(int px = 7; px >=0 && w < pBM->width; px--, w++) { if (p[bi+c] & (1<<px)) setPixel(col+w, bl); } } bi += pBM->pitch; bl++;}Now, for fonts such as FreeMono.ttf and many others, this works well
However, for the Font Awesome 6 OTF, or the Font Awesome 5 TTF files, it doesn't. If I ask for characters outside the normal ASCII range, it gives me an invalid glyph.
I know that the characters are 32 bit, such as 0xf003, so outside the normal ASCII range, and in the live code, chr is typed as uint32_t.
Can anyone give me any clues as to how to start working out what is wrong? I know the font files contain a single face, and multiple charmaps, and I can successfully enumerate the available characters and identify that the characters I want are actually there, but I wonder whether I need to do something different when loading the glyphs?
Another thing that puzzles me is that if I use the font from within a python3/tkinter app, when I display text using the font, it works, including both lowercase and uppercase letters, but the character to glyph mapping seems to suggest that character 'A' and character 'a' both map to glyph#24. This confirms what I see within the ASCII range. How come python can display normal text?
Statistics: Posted by SteveSpencer — Sat Jul 13, 2024 9:36 am