where can I find lang_demo example for Stellaris EKL-LM4F232 Evaluation Kit?

Per my earlier reply (LM4F232 Graphic Lib) - the existing lang_demo code should be quickly/easily adaptable for use by your new M4F MCU.  You should survey past board/demo code for pin/port usage - it may be possible to leave much of the code intact - or you'll have to "tweak" ports to the comfort of your 4F232 Eval board.

hi cb1_mobile,

thanks for the info.. it might be a very good starting code for me.

do you happen to know where to find the graphics Lib sample code for M3 devices?

thanks,

Sherwin Tiongson

TI site has latest/greatest - search for Stellaris Latest Updates.  (I'm on road - don't have all resources)  You can download just the latest Graphic Library there.

Here's the link: http://www.ti.com/mcu/docs/mcuorphantoolsw.tsp?sectionId=632&orphantabId=4

hi cb1_mobile,

I downloaded the latest SW-GRL (StellarisWare® Graphics Library Standalone Package,  02/01/201 )but still I cannot find the lang_demo sample code for Stellaris EKL-LM4F232 Evaluation Kit. Right now Im gearing towards porting an old(dk-lm3s9d96) lang_demo sample codes to Stellaris EKL-LM4F232 Eval Kit.

thanks again for the support!!

regards,

sherwin tiongson

The lang_demo example isn't included in the ek-lm4f232 but that shouldn't be taken as an indication that the features can't be used there. I suspect the main reason it wasn't included is that it's a widget-based application that uses the touchscreen available on the dk-lm3s9b96 and IDM modules. To have it work on the ek-lm4f232 board would have required a brand new user interface and I suspect we just didn't have time to do that before the board was released.

The CM3/CM4 difference is irrelevant here since GrLib is provided for both. The source is identical and the only difference is the compiler options used to determine which floating point support is included. GrLib doesn't use floating point so this just ensures that the library can link against other code that does.

  To get a version of lang_demo running on the ek-lm4f232, your best bet would be to download the dk-lm3s9b96 or dk-lm3s9d96 release and pull the lang_demo source from that. You will then need to rework the user interface to remove the widgets and use something else that accepts user input from the buttons. This is non-trivial but not particularly difficult.

Hi Dave Wilson,

Got it working, but the lang_demo is not really a good example to work with as a starting code. the best is the font_view demo. and the hello world demo.

thanks,

sherwin

Sherwin,

  If you need to use multiple languages, lang_demo is the place to start since it's the only example we ship which shows how to use string tables, custom codepages and custom fonts. If you are only supporting a single language, font_view is helpful since it shows you how to set up grlib for the text codepage(s) you intend using. If you have no interest in anything other than ASCII and just want a very basic, widget-based example, hello_widget is your best starting point and if you don't care about widgets, string tables and codepages other than ASCII, start with hello_world which gives you the bare bones setup needed to use the grlib graphics primitive calls.

hi Dave,

Good day!!

What I did was I downloaded a korean true type font file and I converted it into a .C file using a tool called "ftrasterize". Then I link this .C file to my application and used the strutures in that .C file using a function shown below  in that display korean characters in my OLED. I am curuios if there are other ways of doing it... Can please you advice me on this? You mentioned about string stables? I haven't yet fully understand the capabilities of graphics library yet.

GrContextFontSet(&sContext, g_pFontKoreantimesssk14);
GrStringDraw(&sContext,
                        "Good Evening",
                        (strlen("Good Evening")),
                        10,
                        0,
                        0);

Thanks,

Sherwin

If your application only needs to support one language and doesn't offer the user the opportunity to select between various languages, the approach you have used is perfectly fine. The real test is whether or not your application can display the Korean characters in addition to the ASCII ones. If you find that you can display the ASCII characters correctly but can't get the Hangul characters to display, this suggests you have not set up the correct codepage mappings before calling GrStringDraw. Make sure that you have called GrLibInit() and set the correct default codepage (in the usCodepage field) and that you have an entry in the pCodePointMapTable that maps from your source codepage to the font codepage you  use.

If you want to offer support for multiple languages, you can set up all the strings for each library in a single file then encode this as a string table using the mkstringtable tool. You then access these strings by ID using the GrStringGet() and set the language you want using GrStringLanguageSet(). You can see this in the lang_demo example application.

Hi Dave,

Good morning!!

I was able to display English and Korean characters using my current approach but I still have problem in displaying Korean characters because it displays a different korean character when I display... let say, I want to display letter 'H' it displays a different character. I tried to investigate and see if there is an offset problem and it seems to me that its not the case. When I display english (i.e; Latin) it works perfectly. I think I have problems on the mapping of the korean characters. Can you please advice me on this?

I have attached the .ttf file and the .C file I have created using ftrasterize.exe.

7041.KoreanTimesSSK.rar

thanks,

Sherwin Tiongson

Sherwin,

  I first took a look at the C file you provided and noticed that it was encoded as a tFont structure. This is only capable of holding characters with codepoints from 0x20 - 0x7E (the ASCII set) so can't be used for Korean or any non-ASCII font. You should use the "-r" switch to generate a tFontWide structure that will allow you to encode characters outside the 0x20 - 0x7E range. You will also normally use "-u" to tell ftrasterize to use Unicode character mapping and, to tell it which actual character glyphs to include, you will need to provide a character map file (since fonts can contain a huge number of different glyphs especially when using Asian character sets). Do this by creating a separate text file containing the Unicode values for the characters you want to include. Each line of the file can be either a single hex character code or, to encode a contiguous block of characters, two hex codes separated by a comma. Pass this to ftrasterize using the "-c <filename>" switch. If you leave this out, the font generated will default to encoding characters 0x20 to 0x7E only so will, once again, contain only ASCII characters. To find out which characters are included in a font, use "ftrasterize -d -v <font name>.ttf" and it will show the Unicode codepoints available.

  Looking at the font you provide, however, I'm confused since it says it contains a Unicode character mapping but obviously doesn't. Unicode would have Latin characters in the codepoints from 0x20 - 0xFF whereas this font places Korean characters there instead. I would expect to see Korean jamo at codepoints from U+1100 to U+11FF or Hangul syllables from U+AC00 to U+D7A3. Do you know what codepage is actually being used here? Is there another common Korean codepage that uses character codes in the 0x20-0x7E (or 0x20-0xFF) range that could be involved? If so, you would have to tell ftrasterize to use a specific codepage ID to describe this (you can choose one from 0x8000 and above or, if this is a common Korean text encoding that I just don't know about, let me know where it is defined and I'll make sure I add specific support for it in a future release) and then pass this same codepage ID to GrLib when you call GrLibInit().

  Sorry if this post asks more questions than it answers! When implementing this support, I assumed that UTF-8 and UTF-16 would be the most common text encodings for Korean, Chinese and Japanese and I had a hard time finding fonts and sample text using other codepages so, if you can offer any insight into the codepages you most commonly use in Korea, I would love to hear it so that I can make sure that support is added. Even if GrLib doesn't support those codepages directly today, the architecture is designed to allow others to very easily add new codepages through the use of the codepage map table so you should still be able to get this working once we figure out what codepages are actually being used.

Hi Dave,

Good evening!!

Looking at your instructions it seems to me that I have a multiple sources of errors in my implementation. Let me discussed this per paragraph.

first paragraph: When I created the .c file using the ftrasterize.exe tool is i just used the most simple  command parameters w/c is "ftrasterize -f test -s 24 test.ttf". Obviously I got an error here. In addtion to that regarding, the "character mapping", can you please send me some examples on what this file look like and how to interpret it so that I can patter my char map from it? this would help me a lot if you can provide me with this info. 

2nd paragraph: I think you are correct. Just this afternoon I received addtional korean .ttf files from our counterpart from Korea and I open it using a FontCreator tool. I have seen the big difference. The one that I've used before is a bad .ttf file, it was given to me by my collegue and I think he just downloaded it online. Unfortunately I am already at home right now and I dont have access on the new .ttf file. Hopefully it would help if i will send you samples of it tommorrow morning so that you can review its content and give me some feedbacks and see if the content is what you expected. Please bear with me on this... this is my first time working on fonts/ttf files.

3rd paragraph: i am the one who should be thankful on this help from you. :)  I think I can send you samples of the new .ttf files i recieved from Korea so that you can evaluate on what encoding it used and see if its already supported.

On another thought.. do you think this is the best way to implement support on multiple languages? I have seen the lang_demo samples and it used a different approach it uses mkstringtable.exe utility to create .c files. But my understanding on using string table is that we will have a limitations because the string is already pre-defined and we will not be able to support  such as contact list editors because the contact names will be variable. Please correct me if I'm wrong on this. 

Thanks again for your great support!!

Best regards,

Sherwin Tiongson

sherwin tiongson said:

first paragraph: When I created the .c file using the ftrasterize.exe tool is i just used the most simple  command parameters w/c is "ftrasterize -f test -s 24 test.ttf". Obviously I got an error here. In addtion to that regarding, the "character mapping", can you please send me some examples on what this file look like and how to interpret it so that I can patter my char map from it? this would help me a lot if you can provide me with this info. 

You can find documentation that explains all the options in ftrasterize in the "Utilities" chapter of the Stellaris Graphics Library User's Guide. Look for the file SW-GRL-UG-xxxx.pdf in C:\StellarisWare\docs (assuming you installed your StellarisWare in the default directory). This should help explain how to use the tool. Since the original tool was written when we only supported ASCII fonts, the basic command line will generate an ASCII font and this is definitely not what you want to display Korean text.

sherwin tiongson said:

2nd paragraph: I think you are correct. Just this afternoon I received addtional korean .ttf files from our counterpart from Korea and I open it using a FontCreator tool. I have seen the big difference. The one that I've used before is a bad .ttf file, it was given to me by my collegue and I think he just downloaded it online. Unfortunately I am already at home right now and I dont have access on the new .ttf file. Hopefully it would help if i will send you samples of it tommorrow morning so that you can review its content and give me some feedbacks and see if the content is what you expected. Please bear with me on this... this is my first time working on fonts/ttf files.

To understand where particular character sets are encoded in Unicode, I use this page which contains PDF files of every character found in the standard. For an introduction to Unicode itself, the Wikipedia entry here is very helpful.

sherwin tiongson said:

3rd paragraph: i am the one who should be thankful on this help from you. :)  I think I can send you samples of the new .ttf files i recieved from Korea so that you can evaluate on what encoding it used and see if its already supported.

I still have questions about the codepages and fonts people typically use when typing local language text in Korea, Japan and China. Although I've read, for example, that ShiftJIS codepage is popular in Japan and GB18030 is the new standard codepage in China, I don't have either example text or fonts using these mappings. GrLib should be able to handle them assuming appropriate fonts exist but I would love to try them out and make sure that they do work as expected. For now, though, I can tell you that Unicode, ISO8859-x and the various Windows125x codepages should work fine without having to use user-defined codepage IDs. For Korean, Chinese and Japanese this means you are most likely to have success when using Unicode and UTF-8 encoded text since this combination is tested here and known to work.

On your question of string tables, they are designed to allow you to change the user interface between multiple languages without having to change the code for each language you want to support. They are an ideal solution even if you also need to allow freeform text entry in the application. In this case, using a custom font (one which includes only the characters in the string table) and codepage (which only contains character codes for the characters your string table uses) would not be helpful. If you are allowing text entry or you need to display arbitrary text, you need to be very careful of the size of the fonts you will need. If you are developing an application that supports, for example Korean, Japanese and Simplified Chinese, your font could easily take up over a megabyte of memory and, obviously, this won't fit in the flash of any Stellaris device. If you need to do this, you will have to look at some other way of storing your font on the board. This could be on an SDCard or in some serial memory. With both of these approaches, you would create a binary font (using the -y option for ftrasterize) and a tFontWrapper structure to allow GrLib to access the font data from non-local memory. You will find an example of how to do this for a FAT file system on an SDCard in the fontview example application.

Hi Dave,

I have attached the .ttf file I received from Korea.. Hopefully you can review it..see if its format is already supported. This time, the korean guys are pretty confident about this .ttf file that they sent. Please let me know on your feedback regarding this file.

Thanks,

Sherwin

Hi David,

I think I already got a .ttf file with UTF-8 text encoding. I opened it using Fontlab Studio and I do see the Hangul syllables from U+AC00 to U+D7A3 code points. Can you please review this file and see if its really in a UTF-8 encoding format? 

thanks a lot for your support.4186.NGULIM.rar

regards,

Sherwin

Sherwin,

  As you note, this font does include glyphs in the Unicode ranges that are intended for Hangul. It also contains a total of 49284 characters which is definitely more like the size I would expect for a CJK font. The font says that it includes a Unicode character map and I believe it this time :-)

You mention UTF-8. Please remember that UTF-8 is a text encoding format and not a codepage. It's a way to represent the Unicode codepage while maintaining backwards compatibility with ASCII. UTF-8 and Unicode do go hand-in-hand but you can't use the terms interchangeably since they mean different things.

Hi Dave,

Good day!!

I did try all possible things converting ttf files into .C using ftrasterize.exe but it seems not working there are too many variables and I'm running out of time.

I found some .C fonts in  C:\StellarisWare\third_party\fonts\ofl\fonts. I tried using this .c files but it did not display korean characters in fact it display an english alphabet. I'm pretty sure that I link it properly because I tried other font files in that directory "fonthandwriting16.c" and I was able to display handwriting text in the display.Below is the my code, can you please give me feedback if I did something wrong? Or do I need to upgrade something to support other languages? Is it correct if I used ISO8859-1 codepage if I will used the files from C:\StellarisWare\third_party\fonts\ofl\fonts? I also observed that the files in C:\StellarisWare\third_party\fonts\ofl\fonts contains tfont type. 

#include "hello/inc/ofl_fonts.h"


//*****************************************************************************
//
// Change the following to set the font whose characters you want to view if
// no "font.bin" is found in the root directory of the SDCard.
//
//*****************************************************************************
#define FONT_TO_USE g_pFontHangulgothic22pt

//*****************************************************************************
//
// codepage mapping functions.
//
//*****************************************************************************
tCodePointMap g_psCodepointMappings[] =
{
    {CODEPAGE_ISO8859_1, CODEPAGE_UNICODE, GrMapISO8859_1_Unicode},        //usSrcCodepage;
    //{CODEPAGE_UTF_8,     CODEPAGE_UNICODE, GrMapUTF8_Unicode},            //usFontCodepage;
    //{CODEPAGE_UNICODE,   CODEPAGE_UNICODE, GrMapUnicode_Unicode}        //*pfnMapChar
};

#define NUM_CHAR_MAPPINGS (sizeof(g_psCodepointMappings)/sizeof(tCodePointMap))


//*****************************************************************************
//
// Default text rendering parameters.  The only real difference between the
// grlib defaults and this set is the addition of a mapping function to allow
// 32 bit Unicode source.
//
//*****************************************************************************
tGrLibDefaults g_psGrLibSettingDefaults =
{
    GrDefaultStringRenderer,                //*pfnStringRenderer
    g_psCodepointMappings,                    //tCodePointMap *pCodePointMapTable;
    CODEPAGE_ISO8859_1,                        //usCodepage
    NUM_CHAR_MAPPINGS,                        //ucNumCodePointMaps;
    0                                        //ucReserved
};


int display_korean_font(tContext sContext, char* string_to_display)
{
    UARTprintf("\nDisplaying string = %s...in korean laguage..", string_to_display);

    //
    // Set graphics library text rendering defaults.
    //
    GrLibInit(&g_psGrLibSettingDefaults);

    //GrStringCodepageSet(&sContext, CODEPAGE_UTF_8);

    GrContextFontSet(&sContext, FONT_TO_USE);

    GrStringDraw(&sContext,
                    string_to_display,
                    (strlen(string_to_display)),
                    5,
                    30,
                    true);

  GrFlush(&sContext);

return 0;

}

Thanks,

Sherwin

Sherwin,

  Perhaps if you told me what command line options you used on ftrasterize and what particular Unicode blocks you are trying to encode, I could offer some help on generating a Stellarisware-compatible font. Here's how I would do it. This is taken from the example in the Graphics Library User's Guide which shows how to create a font containing Japanese character sets.

I created a character map file as follows and called it korean.txt:

#############################################################################
#
# ftrasterize character map file containing all ASCII and Korean characters
#
#############################################################################

# ASCII characters
0x20, 0x7E

# Hangul Jamo
0x1100, 0x11FF

#Hangul Syllables
0xAC00, 0xD7A3

I put this in the same directory as the NGULIM.ttf font you sent and executed ftrasterize as folllows:

ftrasterize -f korean -s F4 -c korean.txt -r -u NGULIM.TTF

This generated a C file containing every Korean syllable and alphabet character and also all the ASCII characters. The command line switches mean the following:

• "-f korean" sets the name of the output file and base name of the tFontWide structure created by ftrasterize.
• "-s F4" tells ftrasterize to use the fixed character size with index 4. This font contains 15 fixed character size encodings as you will see if you executre "ftrasterize -d" to show details of the font. F4 represents the 8x15 character cell size.
• "-r" tells ftrasterize to generate a relocatable (wide) font using the tFontWide structure type. This is required when dealing with any character set which contains more than 256 characters.
• "-u" tells ftrasterize to use the Unicode character mapping when looking up characters in the font. Again, "ftrasterize -d" shows me that this font contains a Unicode character map.

The file generated by this process is enormous (2.45MB) so you definitely can't use this in a Stellaris application. If you need the whole character set, you would need to use the binary version of the font. Generate this using the same command line but add "-y". This will generate fontkorean8x15.bin which is 370KB for me. You could store this on an SDCard or in a serial memory and access it using the font wrapper system. See fontview for an example of how to access a font stored on an SDCard.

Looking at the code you provided, you biggest problem is that you are not using the right codepage. ISO8859-1 is an 8 bit codepage which describes 256 characters used in Western Europe. It cannot encode Korean. You should use UTF-8 instead. Your g_psCodepointMappings table should include only one entry:

{CODEPAGE_UTF_8,     CODEPAGE_UNICODE, GrMapUTF8_Unicode},

and you should change references to CODEPAGE_ISO8859_1 to CODEPAGE_UTF_8. You will need to make sure that the strings you pass to GrStringDraw are encoded in UTF-8 or else you will still see the wrong things on the display. Most text editors I've used allow you to save files in UTF-8 format.

If you want to try using one of the fonts we ship, the fonts in third_party/fonts/ofl_fonts/fonts/fonthangul*.c or third_party/fonts/ofl_fonts/binfonts/fonthangul*.bin are encoded as tFontWide types (though they are defined as const unsigned char arrays, the first byte tells you it's a wide font - FONT_FMT_WIDE_PIXEL_RLE).

Hi Dave,

thanks a lot for your patience..

1.) I've already done (change to UTF-8) what you said in my code to used the files in third_party/fonts/ofl_fonts/fonts/fonthangul*.c. Below is my edited code. I tried to run but it still display an english character not koreans. 

//user's files
#include "hello/inc/ara_grlib.h"
#include "hello/inc/ofl_fonts.h"


//*****************************************************************************
//
// Change the following to set the font whose characters you want to view if
// no "font.bin" is found in the root directory of the SDCard.
//
//*****************************************************************************
#define FONT_TO_USE g_pFontHangulgothic18pt

//*****************************************************************************
//
// Text codepage mapping functions.
//
//*****************************************************************************
tCodePointMap g_psCodepointMappings[] =
{
        {CODEPAGE_UTF_8,     CODEPAGE_UNICODE, GrMapUTF8_Unicode},
};

#define NUM_CHAR_MAPPINGS (sizeof(g_psCodepointMappings)/sizeof(tCodePointMap))


//*****************************************************************************
//
// Default text rendering parameters.  The only real difference between the
// grlib defaults and this set is the addition of a mapping function to allow
// 32 bit Unicode source.
//
//*****************************************************************************
tGrLibDefaults g_psGrLibSettingDefaults =
{
        GrDefaultStringRenderer,
        g_psCodepointMappings,
        CODEPAGE_UTF_8,
        NUM_CHAR_MAPPINGS,
        0
};


int display_korean_font(tContext sContext, char* string_to_display)
{
    UARTprintf("\nDisplaying string = %s...in korean laguage..", string_to_display);

    //
    // Set graphics library text rendering defaults.
    //
    GrLibInit(&g_psGrLibSettingDefaults);

    //GrStringCodepageSet(&sContext, CODEPAGE_UTF_8);

    GrContextFontSet(&sContext, FONT_TO_USE);

    GrStringDraw(&sContext,
                    string_to_display,
                    (strlen(string_to_display)),
                    5,
                    30,
                    true);

    GrFlush(&sContext);
    //string_to_display = NULL;
    //free(string_to_display);
return 0;
}

2.) In your last two paragraphs? What do you mean by  "make sure that the strings you pass to GrStringDraw are encoded in UTF-8" does this mean that the korean charcters will not be displayed as Hangul characters as I have experiencing right now? Do I still need to convert the strings somehow?

    GrStringDraw(&sContext,
                    "string to display",
                    (strlen("string to display")),
                    5,
                    30,
                    true);

thnaks,

Shrwin

When handling text strings, it is absolutely vital that you know which codepage the strings are encoded using. The codepage defines the characters that are displayed for particular bytes or groups of bytes in your stored C string. Your text editor will use some encoding by default but you need to make sure you know what that is so that you can be sure that the byte values you have in "string_to_display" are going to be interpreted correctly by GrLib. I can't tell how you have your text editor set up or which codepage it is using, though. You will have to search your editor's documentation to find out. If your main source code editor can't generate UTF-8 text, you may have to put your strings into some other file that you generate using a different editor and reference them by pointer since it is vital that you don't change the codepage of the file with the strings in it (or you will end up seeing a mess of ASCII and gaps when you try to display the string rather than the Korean text you expect).

You should probably spend a few minutes reading about UTF-8, Unicode and codepages in general so that you understand the basic problem. There are many different ways to store text! These links may help:

http://en.wikipedia.org/wiki/Codepage

http://en.wikipedia.org/wiki/Unicode

http://en.wikipedia.org/wiki/UTF-8

Another vital thing to note when using UTF-8 text is that you can't use functions like strlen on UTF-8 strings any more since the number of bytes in the string is NOT necessarily the same as the number of characters it represents. In the example here, it will probably work since GrStringDraw's parameter is the number of bytes in the buffer you pass rather than the number of characters but, if you want to know the number of characters that will be printed, strlen won't work. Similarly UARTprintf may not display the correct characters for anything that isn't ASCII unless the terminal emulator you are using to receive the serial output can parse UTF-8 correctly.

Hi Dave,

I thought that this things are already being handled by ftrasterize.exe utility. It seems like I need to do lots of reading after all.

Thanks,

Sherwin

Ftrasterize only generates the font data that GrLib uses to look up and display characters on the screen. It has no control over your source code or the data you end up passing to GrStringDraw as text. It's up to you to make sure you pass GrLib valid data in the format that you have told it to expect (UTF-8 in this case).

Hi Dave,

Got it working. I was able to display Hangul characters. Instead of GrStringDraw(characters_ to_display), i used its corresponind UTF-8 hex values of that charcters.

Thanks a lot for your help.

Sheriwn Tiongson

Hi dave,

You are exactly correct. I still need to create a UTF-8 hex values  to hangul-jamo-syllables for this code to be fully usable in our application or some kind of Korean IME(Input Method Editor). Do you have any idea on how to better implement this?

Thanks,

Sherwin

I'm afraid I've been asking this question for a while. How do people normally type Korean and what codepage is commonly used in that country? So far, I've been unable to find anyone who can provide the answer. Although UTF-8 can provide a universal solution, I understand that other codepages are commonly used in Korea, Japan and China and the GrLib architecture is designed to allow them to be accommodated pretty easily but there is not built-in support for them since, frankly, I don't know which ones are actually used on a day-to-day basis! If you (or anyone reading this) can help me out with this, that would be great.