[Special Character Usage]

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.

[Special Character Usage]

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?

[Special Character Usage]

@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.

[Special Character Usage]

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.

[Special Character Usage]

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.

[Special Character Usage]

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);

 

[uGFX - Linux - g++]

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.

[Font Size]

Joel,

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

[Online font converter]

Fabien,

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

[uGFX - Linux - g++]

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

[Prototype Effort - Will uGFX work for us?]

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.