[Tutorial] How to use non-ASCII characters in VTFT and VGLCD

[aCkO]

This is an update to the post I made here: http://www.mikroe.com/forum/viewtopic.p ... 59#p220759

The application from the above post was written just as a "proof of concept" on how to use non-ASCII characters in Visual TFT. It relied on GLCD Font Creator which did all the "heavy lifting".

I had some spare time and decided to create a standalone application which does the same thing as GLCD Font Creator along with some other features which I considered useful. The result can be found here: http://www.libstock.com/projects/view/7 ... -generator

cpFontGenerator.jpg (160.74 KiB) Viewed 18737 times

The application does just what the name suggests: it exports system font for character set (code page). The above screenshot shows the export of Serbian Cyrillic script.

Compared to Visual TFT and GLCD Font Creator it has the following advantages:
- support for code pages
- support for non-sequential character export (which dramatically reduces the size of the generated code for larger font sizes)
- optimization of fonts, i.e. removal of unused rows and columns is done implicitly (and much faster)
- space character width is calculated based on font size (Visual TFT uses fixed width of 3 pixels for every font size. See the screenshot below)

space_width.jpg (155.13 KiB) Viewed 18737 times

I intentionally reduced the recommended width of space char to 25% width of the widest character in the set. There are some other features I started to work on but didn't have time to finish (such as editing the generated characters. You can double click the selected char and do the editing just like in GLCD Font Creator but don't expect it to be saved I will correct this in the next version).

To use the characters from other code pages in mE software (compilers, VisualTFT and Visual GLCD) you need to change the system locale to the one that matches the character set you wish to use. Instructions on how to do that can be found here.

mC_Cyrillic.png (15.76 KiB) Viewed 18691 times

The code from the above screenshot will compile correctly.

If you are interested in the font format used by Visual TFT uses, you can take a look at the Microchip AN1182 for details (http://ww1.microchip.com/downloads/en/A ... 01182c.pdf). I think there are much better ways to store and search the font table than the one described in this application note but I will leave that for some other topic

Regards

[aCkO]

The application has been updated to v1.01. Fixed a run-time error that was caused by some code lines used for debugging on a local system which I forgot to remove in the release version. Sorry guys, it was 4 AM

You can download it from Libstock: http://www.libstock.com/projects/view/7 ... -generator

Regards

[marko.ziv]

Hello,

topic is now a sticky. aCkO thank you for this very useful tutorial and app.

Best Regards

[prakob]

Hello aCkO,

Thanks so much to develop such a great app. I will absolutely try with THAI font and will post the result back.

Best Regards.

[aCkO]

Hi prakob,

Based on the information I found at Wikipedia, it seems that Thai script is a writing system in which consonant-vowel sequences are written as one glyph, i.e. one over another. As far as I know, TFT Library functions use Normal Glyph Format described in AN1182 (I think there is no support for Extended Format). You will have to create your own function for displaying sequence of characters (strings) one by one. If you keep track of the cursor you will be able to position them one over another, i.e. use the TFT_Write char at the same or slightly adjusted position. To do that you will first need to obtain character width from the font table. You can use these functions for that:

Code: Select all

char TFT_Char_Width(char c, const char *font) {
   unsigned int MinID = *(unsigned int *)&font[2];
   unsigned int MaxID = *(unsigned int *)&font[4];
   
   if (MinID <= c && c <= MaxID)
      return font[8 + 4 * (c - MinID)];
   else
      return 0;
}


unsigned int TFT_Text_Width(char *txt, const char *font) {
   unsigned int width = 0;
   
   while (*txt)
      width += TFT_Char_Width(*txt++, font) + 1;

   return width;
}

But first I must add editing capabilities to the application because you will need to remove the dotted circles shown in the vowel bitmaps (screenshot below) which represent other characters.

Thai.jpg (196.68 KiB) Viewed 18657 times

It will be done in the next version.

Regards

[prakob]

Hi, aCkO,

I am not sure i will explain you clearly because my english is not so good.

In thai, if there are vowel or consonant behind character, it's position will be top and overlap with normal character .

As my previous simple solution, I just use mikroe GLCD font creater to import thai font and i particularly shift vowel or consonant's position to the left by half of character width so it can be simply show thai font but it will complicate if i change font size.

I think your application will help this process easily and efficiently.

Best Regards

[aCkO]

Version 1.03 is out.

Added:
- Option to edit characters prior to exporting
- Support for compressed font format (up to 50% smaller code size)

Regards

[Megahurts]

Hi Aleksandar,

You're the man, another great addition to your tools for PICs for us lowly users .

I do have a problem with the package for PIC32 mBasic I downloaded from LibStock last night though, it appears to be empty, no files in the package.
When I launched manager to install the library, it was in the state of creating the package and wanting files to be added and package saved
before installation could be done, but no files or devices are selected, so it errors out.

Can you check the status of the archive on LibStock to see if it indeed does contain the package material for mBasic please.

Or let me (everyone), know the proper way to implement (/install) the tool.
What file size should I expect for the mBasic package?

The 793_bitpack_font_library_v1.0.0.0.zip I got this morning is 162K. (seems small compared to other packages I have.)
The 1379475222_bitpack_font_lib_mikrobasic_pic32.mpkg is @ 510 Bytes??

Thanks again for your shared efforts regardless, Robert.

[MaGiK]

Thank you so much for your amazing work aCkO!
I can certainly make use of your application in a project of mine.
Now I just need the motivation to keep it going

[aCkO]

Hi guys,

Thank you for positive comments. I am glad you find it useful.

I have just uploaded complete examples and help files for mikroBasic and mikroPascal for PIC32.

http://www.libstock.com/projects/view/7 ... nt-library

@Megahurts
Make sure you use Package Manager v3.5.0.0 for installation: http://www.mikroe.com/downloads/get/127 ... r_v350.zip

Regards

[aCkO]

Version 1.04 is out.

Added:
- support for anti-aliased fonts (2 bpp, 3 bpp and 4 bpp)
- TFT_BP_GetPixel function for reading pixel color from TFT controller GRAM



Regards

[aCkO]

v1.06 is out

Added:
- Support for FT800 fonts
- Export of fonts as resource data

Regards

[vt23]

Hello aCkO,
I'm glad you're still available to give answers and continue working on the projects like BitPack library.
I wrote to LibStock comments lately:

... I think the anti-aliasing works good only for Black or White background (I have white text and black screen background) because edges of characters have dark grey pixels when I draw the BP text (e.g. 3bpp) over colored (green, yellow, ..) button (area).
It is done intentionally? Would it take far more memory space or processor time if the anti-aliasing worked with colors or also colored text on the uniform colored or patchy colored background?
I also found that if BP font is used together with Button (in Visual TFT), the alignment options have not right behavior. I think the problem is in spaces (white characters) at the beginning of a String, they are maybe trimmed in ordinary V-TFT TFT_Write_Text function.

You answered:

The library works well for any kind of background. That's why it requires GetPixel function to be defined by the user. I can post some screenshots in the forum if you want.
The only reason why alignment wouldn't work is if the width of the string isn't properly calculated (check DrawButton function in the generated driver file). I suspect the reason is because mE chose that spaces always have 1 pixel width. Very strange decision, but that's how it is. You can check it for yourself if you compare the generated code with Microchip's AN1182 (http://ww1.microchip.com/downloads/en/A ... 01182a.pdf).

I attached some pictures to better understanding - you can see dark pixels around the characters. Excuse the quality. Background colors are the same on similar pictures but it doesn't look like (mobile phone ). In Enter buttons' captions there are white short dashes (-) and text "Enter" is drawn over that.
Do you think I have bad read pixel function (but I don't have problem to read 16-bit color number of any pixel)? Here is my code.

About the alignment (edited):
I found I have to Ltrim() my String before using in the Button object. Or TFT_Write_Text_Return_Pos() function doesn't have the same effect on the BP font text compared to the default V-TFT text. I assume TFT_Write_Text_Return_Pos() determines position offset of a caption (text).
I found that TFT_Write_Text_Return_Pos(...) can be replaced by direct assigning of 2 global variables

Code: Select all

    caption_length = TFT_BP_Text_Width(Abutton->Caption);
    caption_height = TFT_BP_Font_Height();

and now the alignment of anti-aliased caption inside the Button object is perfect.

Small note: Did you notice, there is written in the CP font generator v1.04 or v1.06 in Output format frame "Microchip AN1882" instead of "Microchip AN1182"?
Regards
Vitek

[aCkO]

Do you think I have bad read pixel function (but I don't have problem to read 16-bit color number of any pixel)?

Most likely. The best way to test it is to put some graphic content on one half of the screen and use GetPixel and TFT_Dot functions to paint the other half at run time. Also, check the timing of PMP interface. Unfortunately, I don't have a display with ILI9341 controller to test your GetPixel function. I tried to reproduce the problem on my mikroMMB for PIC32 with HX8347D and here's the result:

bitpack.jpg (58.5 KiB) Viewed 15078 times

As you can see, the font bitmaps are blended with background. Your last screenshot definitely indicates that GetPixel function is the cause of the problem. The library renders bitmaps so that the transparency level of font pixel is combined with the background pixel at the same location. For example, for pixel transparency level 40% the resulting color for each channel at (x, y) is calculated as: 0.4 * font_color + 0.6 * GetPixel_Color. In case of green text on green background, 0.4 * green + 0.6 * green = 100% of green.

I assume TFT_Write_Text_Return_Pos() determines position offset of a caption (text).
I found that TFT_Write_Text_Return_Pos(...) can be replaced by direct assigning of 2 global variables

That's how the text is rendered inside DrawButton function in the driver file:

Code: Select all

void DrawButton(TButton *Abutton) {
    ...
    if (Abutton->TextAlign == _taLeft)
      TFT_Write_Text(Abutton->Caption, Abutton->Left + 4, (Abutton->Top + ((Abutton->Height - caption_height) / 2)));
    else if (Abutton->TextAlign == _taCenter)
      TFT_Write_Text(Abutton->Caption, (Abutton->Left + (Abutton->Width - caption_length) / 2), (Abutton->Top + ((Abutton->Height - caption_height) / 2)));
    else if (Abutton->TextAlign == _taRight)
      TFT_Write_Text(Abutton->Caption, Abutton->Left + (Abutton->Width - caption_length - 4), (Abutton->Top + (Abutton->Height - caption_height) / 2));
  }
}

Small note: Did you notice, there is written in the CP font generator v1.04 or v1.06 in Output format frame "Microchip AN1882" instead of "Microchip AN1182"?

That was a typo I already uploaded the corrected file to Libstock.

Regards

[vt23]

Hello,

it was too much effort and many letters to solve this stupid problem.

Also, check the timing of PMP interface.

Even every less-experienced guy could solve it, but thanks aCkO. Maybe some moderator (or you?) can delete my comment on BitPack library on LibStock site.
The crux of problem was the Wait state (WAITM). You can see I had all settings correctly sooner - here. But again the ...driver.c file was overwritten (as usually) and WAITM value returned to default. But the bad blending is not problem if you have black background (because GetPixel_Color is almost zero with short wait state) so I didn't notice the problem sooner.

I know DrawButton() function and it works fine now - problem was TFT_Write_Text_Return_Pos(), which is not friendly with BitPack's TFT_BP_Text_... functions.
Maybe other issue is: I have to replace all the fonts and text functions by BitPack's text somehow or to make some conditions like e.g.

Code: Select all

if(Abutton->FontName == Tahoma_Bold_30x41_3bpp_cp) {        // BitPack's font
  TFT_BP_Set_Font(Abutton->FontName,0, Abutton->Font_Color, FO_HORIZONTAL);
...}
else {
  TFT_Set_Font(Abutton->FontName, Abutton->Font_Color, FO_HORIZONTAL);
...}

Regards
Vitek