Adam M

Scratch that dependency comment - I added dependencies to our Makefile, and still got the same behavior - since I was running make clean / make each time I probably ended up with the same behavior to begin with. Still though, I could be compiling uGFX improperly (if you don't like the options I used). I copied the options used from a make run of uGFX through your own makefiles - so I assumed / assume they are right.

As a entry condition I ensured that UTF-8 encoding was enabled in my SublimeText instance: "default_encoding" : "utf-8", Here comes a list of things I tried and their results: # Shows ° for the degree symbol snprintf(temp_temp, 20, "%d°F", target_temp); gwinSetText(temp_label, temp_temp, TRUE); # Shows ° for the degree symbol snprintf(temp_temp, 20, "%d\u00B0F", target_temp); gwinSetText(temp_label, temp_temp, TRUE); # Shows ° for the degree symbol gwinSetText(temp_label, "°F", TRUE); # Shows ° for the degree symbol snprintf(temp_temp, 20, "%d%sF", target_temp, "°"); gwinSetText(temp_label, temp_temp, TRUE); # Shows ° for the degree symbol gdispDrawString(10, 10, "°", font1, Yellow); # I then included the cyrillic font implementation from your cyrillic demo and tried to print the demo text. # I got some "?"'s as well as 'not the characters' in the demo string. font_t large_font = gdispOpenFont("Archangelsk Regular 12"); gdispDrawString(10, 10, "привет мир", large_font, Yellow); A thought just occurred to me, perhaps I'm compiling uGFX incorrectly? I'm using this option set in my Makefile: -c -ggdb -O0 -march=armv7 -mfpu=vfp -mfloat-abi=hard -fomit-frame-pointer \ -Wall -Wextra -Wstrict-prototypes -fverbose-asm -ffunction-sections \ -fdata-sections -fno-common -flto -MMD -MP I haven't added dependency management yet - so the -MF that is added by default during "normal" compilation through your own makefiles isn't in use. Think that has anything to do with it?

@inmarket - Yeah, I have that enabled as: #define GDISP_NEED_TEXT TRUE #define GDISP_NEED_TEXT_UTF8 TRUE #define GDISP_NEED_ANTIALIAS TRUE #define GDISP_NEED_PIXELREAD TRUE #define GDISP_NEED_TEXT_KERNING TRUE #define GDISP_INCLUDE_USER_FONTS TRUE I'll try and grab the exact result of my various attempts to get these special characters to print sometime today.

Yeah - to give some more information to the discussion - I later discovered that I was just lucky that I was getting a degree symbol (in that I was actually truncating the first character of the result). This 'hack' didn't work when I attempted to enter the spanish character I mentioned in my original post. When using the UTF-8 code \u00B0 I get some garbage (I'll comment back later with exact garbage) and if I use the exact ASCII code - I also get some garbage. The editor I'm using is Sublime Text - if that helps. I've tried both typing the character and using the pure unicode '\u00B0' and get the same result, so I don't think the editor is to blame.

For others who might run into this... I found that the issue had to do with how I formatting the string. When I changed the code to: snprintf(temp_temp, 8, "%d%cF", left_target_temp, '°'); gwinSetText(ghLeftCommandedTemp, temp_temp, TRUE); I was able to get only the ° character displayed.

I have read up on the forum posts - and it sounds like other people have successfully gotten special characters to work, so I must be missing something. I went out and got this font (https://www.fontsquirrel.com/fonts/acme?filter[download]=local) which includes the special characters I want to use (° / ñ / é) and converted it to c using the uGFX font converted with anti-aliasing, and no filtering. When I type the ° symbol and use gwinSetText() on a label the ° symbol actually shows up without issue - but I also get a  character also appears just in front of the ° symbol. I have attempted the use of two distinct fonts that each have the special characters I need - when I used another font, named Alef - I also got the ° printed using that font, but a rogue ? showed up in front of the symbol. I was curious if anyone had any ideas as to why this is happening or suggestions on what I should try next? Example: snprintf(temp_temp, 8, "%d°F", left_target_temp); gwinSetText(ghLeftCommandedTemp, temp_temp, TRUE);

Thanks for the reply inmarket. Just finished building our make system from the ground up - and didn't consider switching compilers and then linking with g++. I modified our makefile to build uGFX with gcc and our own source with g++, then linked with g++ as you suggested and everything is up and running now.

Joel, Thanks for the tips - we ended up going through the online font converter, and it worked like a charm.

Fabien, It is working fine for me. Either it has been fixed or your input parameters are at fault.

Hello! Thanks for the effort you have put into uGFX! It has made setting up a UI from scratch MUCH simpler! CPU - armv7 OS - Ubuntu 16.04 On to the issue at hand - I would like to use the g++ compiler to build uGFX so that I can link in my own C++ source. I have my own Makefile that builds uGFX under gcc without issue, and I have linked in my own C code at this point. However, I now need C++ for some higher-level functionality code that we have. When I shift the compiler over to g++ I get a set of errors from within uGFX. Here is one set as an example: ui/resources/ugfx/src/gdisp/gdisp.c: In function ‘void gdispGControl(GDisplay*, unsigned int, void*)’: ui/resources/ugfx/src/gdisp/gdisp.c:2877:29: error: invalid cast from type ‘void*’ to type ‘orientation_t {aka orientation}’ switch ((orientation_t) value) { ^ ui/resources/ugfx/src/gdisp/gdisp.c: In function ‘bool mf_drawline_callback(mf_str, uint16_t, void*)’: ui/resources/ugfx/src/gdisp/gdisp.c:3352:105: error: cannot convert ‘justify_t {aka justify}’ to ‘mf_align_t’ for argument ‘4’ to ‘void mf_render_aligned(const mf_font_s*, int16_t, int16_t, mf_align_t, mf_str, uint16_t, mf_character_callback_t, void*)’ mf_render_aligned(GD->t.font, GD->t.wrapx, GD->t.wrapy, GD->t.lrj, line, count, drawcharglyph, state); ^ ui/resources/ugfx/src/gdisp/gdisp.c: In function ‘bool mf_fillline_callback(mf_str, uint16_t, void*)’: ui/resources/ugfx/src/gdisp/gdisp.c:3359:105: error: cannot convert ‘justify_t {aka justify}’ to ‘mf_align_t’ for argument ‘4’ to ‘void mf_render_aligned(const mf_font_s*, int16_t, int16_t, mf_align_t, mf_str, uint16_t, mf_character_callback_t, void*)’ mf_render_aligned(GD->t.font, GD->t.wrapx, GD->t.wrapy, GD->t.lrj, line, count, fillcharglyph, state); ^ I was getting ready to barrel into the source and get it running under g++ - but I thought I better ask if that effort has already been done - or if I'm missing something simple. Is uGFX already setup to work under g++? I should add - I am using uGFX v2.8

Hi, My company and I are investigating purchasing uGFX for a product deployment. However, I have been having difficulty trying to get uGFX to function in our production environment. Before giving up and moving to an alternative solution, I wanted to see if any had any ideas (or even expected that our use-case might be supported). Our Production Environment: Prototype Board: BeagleBone Black Wireless Architecture: armv71 OS: Debian Stretch 9.3 I figured we would use your SDL2 Linux Framebuffer support. However, your guide for Linux suggests that I must install the i386 SDL-dev package due to uGFX requiring a x32 bit compilation - as such it seems that I don't have a way to get this to work in our production environment. It appears there isn't an available installation of gcc-multilib that would work on our architecture either. Let me know your thoughts, and thanks in advance, Adam M.