Problems with UTF-8 / Unicode

[Jack Huffman]

I'm having problems using UTF-8 / Unicode characters. They work fine for the 'Fl_Window' class; however, I can't get Unicode characters above 'U+00ff' to work with 'Fl_Button' (and other classes).

In the code below, all of the Unicode characters of 'myStr' (yellow) display properly in the  'myWindow' label; see included image. The green 'cout' statement also logs them properly to the console. However; the Unicode characters above 'U+00ff' do not display on the 'Fl_Button' class. The degree symbol (°) is 'U+00B0' and other symbols up-to 'U+00FF' appear to work OK. However the Greek sigma (σ) 'U+03c3' and the Asian  characters don't display on the 'Fl_Button' class (an other sub-classes).

I just started using FLTK yesterday and Unicode today so I'm a newbie on this.

#include <iostream>

#include <FL/Fl.H>

#include <FL/Fl_Window.H>

#include <FL/Fl_Button.H>

using namespace std;

int main()

{

    if (!setlocale(LC_CTYPE, ""))

    {

        cerr << "Error: Can't 'setlocale()' failed\n";

        return 1;

    }

    // test string for all window and button

    const char *myStr = "MyStr \u00b0C °C σ 日本国 end";

    cout << myStr << "\n";

    Fl_Window myWindow(400, 50, myStr);

    myWindow.begin();

        Fl_Button myButton(10, 10, 300, 20, myStr);

    myWindow.end();

    myWindow.show();

    return Fl::run();

}

[MacArthur, Ian (Selex ES, UK)]

> I'm having problems using UTF-8 / Unicode characters. They work fine for
> the 'Fl_Window' class; however, I can't get Unicode characters above
> 'U+00ff' to work with 'Fl_Button' (and other classes).

> In the code below, all of the Unicode characters of 'myStr' (yellow)
> display properly in the 'myWindow' label; see included image. The green
> 'cout' statement also logs them properly to the console. However; the
> Unicode characters above 'U+00ff' do not display on the 'Fl_Button'
> class. The degree symbol (°) is 'U+00B0' and other symbols up-to
> 'U+00FF' appear to work OK. However the Greek sigma (σ) 'U+03c3' and the
> Asian characters don't display on the 'Fl_Button' class (an other
> sub-classes).

You don't say what platform you are on, but I'm guessing it is some *nix/X11 combination.

Your code is fine (I just tested it on Win7 and it works perfectly) but what is at issue is font handling.

Now, on OSX and Win7 (well, anything since Vista, or XP with the extensions I think) the OS font service makes a fairly good stab at glyph substitution, so that if the glyph you need is missing from the selected font, it will try to find the correct glyph in some fallback font.

Add to that the fact that MS make considerable efforts to ship at least a few "pan" fonts (i.e. fonts that cover as many language groups as possible) and it all pretty much Just Works, for most people, most of the time.

However, the situation under X11 and XFT is much trickier; there is no "automatic" glyph substitution provided by the OS, so if the selected font does not have the necessary glyph, you just get the "substitution character" for the font, which in your case (as is often the case) seems to be a "?" glyph.

So...

Q) Why then does your string appear correctly in the window title, but not on the button?

A) Because fltk does not draw the window title bar, the window manager does, and it will be using its own font choices and mechanisms. I'm guessing you are on some sort of gnome desktop, and it is probably using PanGo "under the covers" to get the strings rendered with missing glyphs suitably substituted.

You button, however, is just rendered by fltk using it's default font (whatever the system maps for FL_HELVETICA I assume) and that is likely to be a "Latin" compatible font, or possibly LGC (Latin, Greek, Cyrillic though note that Greek in this case means modern Greek, not classical...) though in that case I'm a bit surprised your sigma glyph did not appear.

The choice with fltk has always been to emphasise "Fast and Light" so building in a complex text rendering engine (ICU, PanGo, etc.) has been something we resisted.

What to do about this...

Well, you can use ICU or PanGo, in your own code, and it will work with fltk, though that's a lot to take on.

Or you can find a decent, reasonably "pan" font on your system and set that as the labelfont for your button.

myButton.labelfont(" NameOfAFontYouLike");

Michael Baeuerle and I were working through some issues with this, about this time last year, to see if we could create a sort of "low cost" glyph substitution engine for fltk/XFT/X11, and it mainly works; the discussion and some hack patches are here:

http://www.fltk.org/str.php?U1903


However, in the short term, your easiest option is just to pick a font face that has the glyphs you need, I'm afraid.

(As an aside, setting the locale in a utf8 fltk program is probably not all that critical, I'm not sure that I ever bother!)




Selex ES Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL
A company registered in England & Wales. Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

[Jack Huffman]

Ian,

I appreciate your response; it  explained several things; however, I now believe I have a basic font problem with my platform which is Ubuntu-Linux. I believe the image I'm using is stripped down a bit.

I tired myButton.labelfont(FL_TIMES) with the standard FLTK fonts and noticed that the font displayed doesn't change regardless of which font I pick. FL_HELVETICA, FL_COURIER, FL_TIMES, FL_SYMBOL, FL_SCREEN, FL_ZAPF_DINGBATS all display just as in the image I posted earlier. This is true for the 'window title' as well as the button. This is why I believe I have a basic problem with fonts.

Of course fonts work fine with other applications; especially my browser. I'm guessing FLTK (which uses X11) gets its fonts from a different mechanism than the browser. Is this a case where the fonts FLTK uses aren't installed? The file /etc/fonts/fonts.conf includes the following:

<dir>/usr/share/fonts</dir>

<dir>/usr/X11R6/lib/X11/fonts</dir> <dir>/usr/local/share/fonts</dir>

<dir>~/.fonts</dir>

Also, your response implied I could but a string in myButton.labelfont("NameOfAFontYouLike") but that doesn't compile for me. Can I use other fonts besides the standard FLTK fonts?

[Ian MacArthur]

On Fri May 01 2015 16:59:52, Jack Huffman wrote:
>
> I appreciate your response; it explained several things; however, I now believe I have a basic font problem with my platform which is Ubuntu-Linux. I believe the image I'm using is stripped down a bit.

If you have built fltk form the tarball, there should be two font test programs in the test folder, “fonts” and “utf8”. Try running those and see what fonts they find.

Apart from the dozen or so “default” fonts that fltk uses, you should be able to use any other font that your Xserver delivers. The “utf8" test will list those fonts and show their names, and allows you (to some extent) to explore what glyphs they can deliver.

>
> I tired myButton.labelfont(FL_TIMES) with the standard FLTK fonts and noticed that the font displayed doesn't change regardless of which font I pick. FL_HELVETICA, FL_COURIER, FL_TIMES, FL_SYMBOL, FL_SCREEN, FL_ZAPF_DINGBATS all display just as in the image I posted earlier. This is true for the 'window title' as well as the button. This is why I believe I have a basic problem with fonts.

That’s odd.

Do you know if your system is using the older X11 Xlib core fonts, or the more recent XFT (TrueTYpe, OPenType, etc.) font system?

Fltk can use either, but must be set at configure/build time for which you prefer, so if you asked for XFT (which is the default now) and you don’t actually have any scalable anti-aliased fonts, then you likely get some fallback Xlib font delivered by the server (which would be consistent with what you describe, I suspect.)

If the utf8 test code shows more than the default fltk fonts, then this is not the case...

>
> Of course fonts work fine with other applications; especially my browser. I'm guessing FLTK (which uses X11) gets its fonts from a different mechanism than the browser. Is this a case where the fonts FLTK uses aren't installed? The file /etc/fonts/fonts.conf includes the following:
> <dir>/usr/share/fonts</dir>
> <dir>/usr/X11R6/lib/X11/fonts</dir> <dir>/usr/local/share/fonts</dir>
> <dir>~/.fonts</dir>

Again, try the test code, see how many fonts they see, that’s the easiest way... Let us know what you find.

>
> Also, your response implied I could but a string in myButton.labelfont("NameOfAFontYouLike") but that doesn't compile for me. Can I use other fonts besides the standard FLTK fonts?

You can ask for any font by name, assuming you know its name (and it exists on your system...)

If you run the utf8 demo from a shell, and you see a font face you like the look of (click the “Self” checkbox to see each font in its own face) then clicking on the “Select” button will dump the “Fltk name” of the font to the console.

If you put that name in the myButton.labelfont() string, all should be well...

e.g. I get this in the console:


idx 387
User name :Palatino:
FLTK name :Palatino-Roman:
size 16


So I set:

myButton.labelfont(“ Palatino-Roman”);

And that pretty much Just Works...

[Albrecht Schlosser]

On 01.05.2015 18:57 Ian MacArthur wrote:
> On Fri May 01 2015 16:59:52, Jack Huffman wrote:

>> Also, your response implied I could but a string in myButton.labelfont("NameOfAFontYouLike") but that doesn't compile for me. Can I use other fonts besides the standard FLTK fonts?
>
> You can ask for any font by name, assuming you know its name (and it exists on your system...)

.. but not in labelfont(). See below for a solution.

> If you run the utf8 demo from a shell, and you see a font face you like the look of (click the “Self” checkbox to see each font in its own face) then clicking on the “Select” button will dump the “Fltk name” of the font to the console.
>
> If you put that name in the myButton.labelfont() string, all should be well...
>
> e.g. I get this in the console:
>
>
> idx 387
> User name :Palatino:
> FLTK name :Palatino-Roman:
> size 16
>
>
> So I set:
>
> myButton.labelfont(“ Palatino-Roman”);
>
> And that pretty much Just Works...

I don't think so. It doesn't compile with my version of FLTK either.

You can set any font by name to any internal font number, so this should
work:

Fl::set_font(FL_HELVETICA," Palatino-Roman");
myButton.labelfont(FL_HELVETICA);

Note the leading space in the font name for the default font face.
Replace the space with 'I' for italic, 'B' for bold, or 'P' for bold+italic.

Substitute FL_HELVETICA with any other known font name (number) or e.g.
FL_FREE_FONT, FL_FREE_FONT+1, etc.. to assign your fonts to different
(free) font "slots" for your own use.

[Greg Ercolano]

On 05/01/15 08:59, Jack Huffman wrote:
> I [tried] myButton.labelfont(FL_TIMES) with the standard FLTK fonts

> and noticed that the font displayed doesn't change regardless of
> which font I pick.

Try running the 'fonts' fltk test program (in test/fonts)..
do different fonts show up in the list, and when you click them
do the fonts change?

I'm not sure, but I think the first 15 or so fonts are the ones
that map to the FLTK macro names like FL_HELVETICA. So see what
names show up in the first few entries of the 'fonts' test program.
On my linux system, the first few names are:

sans
sans bold
sans italic
sans bold italic
..etc..

..which means FLTK is built with Xft, as those are Xft font names.
If I'd built FLTK with Xft disabled, I'd have gotten the standard
X fonts instead, where the names would look more like:

"helvetica"
"helvetica bold"
"helvetica italic"
"helvetica bold italic"
..etc..

Some nerdy details about FLTK fonts under X windows:

FLTK FONTS ON X WINDOWS
FLTK defines macros like FL_COURIER, FL_TIMES, etc. as
integers. The definition is in FL/Enumerations.H:

FL_HELVETICA = 0
FL_HELVETICA_BOLD = 1
FL_HELVETICA_ITALIC = 2
FL_HELVETICA_BOLD_ITALIC = 3
[etc..]

FLTK applications use these names to refer to fonts so that
their app will work on all platforms easily.

So depending on the platform you build your app on,
FL_HELVETICA will map to different font names.

For instance under linux, depending on if FLTK was built
to use Xft (antialiased fonts) or standard X windows fonts,
FL_HELVETICA might map to the Xft font name "sans",
or the standard X font name "-*-helvetica-medium-r-normal--*".

Under Windows and OSX FL_HELVETICA maps to other names.

This saves the application from having to have #ifdef's
in the code for each platform.. FLTK handles it for you.

To see what font names FLTK is mapping e.g. FL_HELVETICA to,
the test/fonts program should show you that in its first entry.

For instance on my system the first entry is "sans", which
means I'm using Xft.

The integers that FL_HELVETICA and such are mapped to are used
as an index into a list of strings that are the actual native
font names used by the platform you're running on.

In the case of Linux XFT, the list of font names can be found
in the src/fl_font_xft.cxx file:

XFT FONT NAME FLTK FONT MACRO NAME
------------- ---------------------
{" sans"}, <-- FL_HELVETICA
{"Bsans"}, <-- FL_HELVETICA_BOLD
{"Isans"}, <-- FL_HELVETICA_ITALIC
{"Psans"}, <-- FL_HELVETICA_BOLD_ITALIC
{" mono"}, <-- FL_COURIER
{"Bmono"}, <-- FL_COURIER_BOLD
{"Imono"}, <-- FL_COURIER_ITALIC
{"Pmono"}, <-- FL_COURIER_BOLD_ITALIC
{" serif"}, <-- FL_TIMES
{"Bserif"}, <-- FL_TIMES_BOLD
{"Iserif"}, <-- FL_TIMES_ITALIC
{"Pserif"}, <-- FL_TIMES_BOLD_ITALIC
{" symbol"}, <-- FL_SYMBOL
{" screen"}, <-- FL_SCREEN
{"Bscreen"}, <-- FL_SCREEN_BOLD
{" zapf dingbats"} <-- FL_ZAPF_DINGBATS

So if you're setting FL_TIMES and it's falling back to some non-times font,
that means the Xft font " serif" is not on the system. (I forget the significance
of the leading space in the font names above -- Ian can probably answer that one)

You can use the linux command line tools like 'fc-list' to list all the Xft
fonts installed on your system, e.g.

fc-list | sort | uniq

How those names map to " sans" and "Bserif" I don't know exactly,
Ian may be of help there.

If, however, you built FLTK with Xft *disabled*, then FLTK will use the
standard X font names from the table defined in the src/fl_font_x.cxx file:

{"-*-helvetica-medium-r-normal--*"}, <-- FL_HELVETICA
{"-*-helvetica-bold-r-normal--*"}, <-- FL_HELVETICA_BOLD
{"-*-helvetica-medium-o-normal--*"}, <-- ..etc..
{"-*-helvetica-bold-o-normal--*"},
{"-*-courier-medium-r-normal--*"},
{"-*-courier-bold-r-normal--*"},
{"-*-courier-medium-o-normal--*"},
{"-*-courier-bold-o-normal--*"},
{"-*-times-medium-r-normal--*"},
{"-*-times-bold-r-normal--*"},
{"-*-times-medium-i-normal--*"},
{"-*-times-bold-i-normal--*"},
{"-*-symbol-*"},
{"-*-lucidatypewriter-medium-r-normal-sans-*"},
{"-*-lucidatypewriter-bold-r-normal-sans-*"},
{"-*-*zapf dingbats-*"}

You can use the command line tools 'xfontsel' and 'xlsfonts' to view
the X windows fonts installed.

For instance, in xfontsel, click "fmly" and choose 'Times'. If the font
doesn't draw or that isn't found, then it's not on your system
(it should be..!).

> This is why I believe I have a basic problem with fonts.

Could be.

> Also, your [Ian's] response implied I could [put] a string in

> myButton.labelfont("NameOfAFontYouLike") but that doesn't compile for me.

Yes, that's not right.

Maybe Ian meant to say:

Fl::set_font(FL_HELVETICA, "NameOfSomeFontYouLike");

..which lets you map the FLTK font macros to one of the native
operating system font names.

So if you're using Xft, you can use one of the font names from fc-list.

Or if using standard X windows fonts, one of the names from xlsfonts
or xfontsel would work.

(Once you find a bunch of settings you like in xfontsel, hit the
'select' button, which copies the name into the clipboard so that
you can then paste it into your app. Let's just say xfontsel is an
ancient X windows program, written way before there were standards
for how to deal with copy/paste. That's what gui applications looked
like in the 1980's..!)

[Greg Ercolano]

> So I set:
>
> myButton.labelfont(“ Palatino-Roman”);
>
> And that pretty much Just Works...

Hmm, Ian, doesn't labelfont() only expect an Fl_Font as an argument?
(e.g. FL_HELVETICA etc)

I can only think you maybe mean Fl::set_font(), as I think that's
the only public interface that allows specifying a native font name..

Maybe I'm missing something?

[Jack Huffman]

...

>If you have built fltk form the tarball, there should be two font test programs in the test folder, “fonts” and “utf8”. Try running those and see what fonts they find. 

'fonts' generates the image below. Note that the the 1st sixteen fonts generate the same output; these are the same fonts that generated the same output in my program. The font 'bitstream charter'  and below appear to work. I don't see the old standbys like Aria, Helvetian etc.

 

'utf8' generates the image below. These fonts seem to work but its a sparse list. The 'Select' button produces strange names on the console. 'Select' 'fixed' produces:

idx 29

User name :fixed:

FLTK name :-*-fixed-medium-r-normal--*:

size 16

 

Never the less '-*-fixed-medium-r-normal--*' works if I use Albrecht's suggestion.

 

 ...

>Do you know if your system is using the older X11 Xlib core fonts, or the more recent XFT (TrueTYpe, OPenType, etc.) font system? 

I don't know the answer to this. How can a figure this out?

>Fltk can use either, but must be set at configure/build time for which you prefer, so if you asked for XFT (which is the default now) and you don’t actually have any scalable anti-aliased fonts, then you likely get some fallback Xlib font delivered by the server (which would be consistent with what you describe, I suspect.) 

Maybe this is my problem. I just enter 'make' so I'm sure I have the default. How do I build it the other way?

...

>So I set: 
    
   myButton.labelfont(“ Palatino-Roman”); 

>And that pretty much Just Works...  

This doesn't compile for me. 'lablefont()' wants an integer argument. I wonder if you have an enhancement that allows a string argument.

Following 'Albrecht's' susuggestion the following works for me. 

       Fl::set_font(FL_TIMES, "-*-fixed-medium-r-normal--*");

       but.labelfont(FL_TIMES);

[Greg Ercolano]

On 05/01/15 11:51, Jack Huffman wrote:
> 'fonts' generates the image below. Note that the the 1st sixteen fonts
> generate the same output; these are the same fonts that generated the
> same output in my program.

By the looks of that output, I'd say FLTK was built to use standard X fonts
instead of Xft, which is why the fonts look ugly (un-anti aliased).

At the risk of too many cooks in the kitchen..

I'd suggest downloading the latest source code from fltk.org and
run:

./configure && make

..being sure it detects Xft being enabled.

If Xft isn't detected, that must mean you're missing the Xft development
stuff.. make sure that's installed in whatever way Ubuntu packages it.

[Greg Ercolano]

On 05/01/15 12:10, Greg Ercolano wrote:
>[..]

> If Xft isn't detected, that must mean you're missing the Xft development
> stuff.. make sure that's installed in whatever way Ubuntu packages it.

Oh, and if it's actually /intentional/ that you're using X fonts,
then I guess sniff around for a more robust X windows font environment
that includes e.g. helvetica and times.

In that second utf8 example image, seems like it's also showing un-anti-aliased
standard X fonts.

I'm thinking it's a sparse list because probably Ubuntu doesn't include
much in the way of X fonts, because most apps use Xft for nicer looking
fonts.

So perhaps it's not a problem that there aren't many standard X windows
fonts on your system.. the problem is probably more that your FLTK
was built to use standard X fonts instead of Xft.

So try building FLTK yourself from source, and make sure it picks up
Xft. Then your fonts should look better in FLTK, and there'll probably
be a better font selection.

[Jack Huffman]

I just rebuilt/installed once with '-enable-xft' and another time with '-enable-x11' and I didn't see any difference in ../test/fonts or ../test/utf8. The build sequence I used is below:

./configure -enable-xft
make
sudo make install

...

./configure -enable-x11
make
sudo make install

I don't know if there is any 'uninstall' necessary.

[Greg Ercolano]

On 05/01/15 12:46, Jack Huffman wrote:
> I just rebuilt/installed once with '-enable-xft' and another time with '-enable-x11' and I didn't see any difference in ../test/fonts or ../test/utf8. The build sequence I used is below:
> |
> ./configure -enable-xft

Note: according to the --help output for configure, the flags is "--enable-xft"
(and not "-enable-xft"), though it's possible it understands both.

Check if 'configure' gave the following 'yes' answers for the Xft related tests:
:
checking X11/Xft/Xft.h usability... yes
checking X11/Xft/Xft.h presence... yes
checking for X11/Xft/Xft.h... yes
checking for XftDrawCreate in -lXft... yes

Sounds like it maybe didn't if you're still seeing X fonts in the actual
build.

> make
> sudo make install

The 'make install' is optional; you can use the libs and test programs
right out of the directory you built the source in.

I don't usually ever do 'make install', just so I don't have an issue
with my apps building against the "wrong" FLTK.

I point my apps at a particular build of FLTK just to be sure it
doesn't pick up some other install of FLTK by accident.

And by building with FLTK's static libs, people who run my FLTK apps
don't need to have FLTK installed on the systems they run the apps on.

[Ian MacArthur]

On Fri May 01 2015 18:23:21, Albrecht Schlosser wrote:
>
> On 01.05.2015 18:57 Ian MacArthur wrote:
>> On Fri May 01 2015 16:59:52, Jack Huffman wrote:
>
>>> Also, your response implied I could but a string in myButton.labelfont("NameOfAFontYouLike") but that doesn't compile for me. Can I use other fonts besides the standard FLTK fonts?
>>
>> You can ask for any font by name, assuming you know its name (and it exists on your system...)
>
> .. but not in labelfont(). See below for a solution.

Doh!

Yes, sorry, I’m an idiot.

I’ve been messing about with some font experiments, and utterly forgot that wasn’t normal fltk coding...

Yes, you need to set a font, like...

Fl_Font my_font = FL_FREE_FONT + 1;
Fl::set_font(my_font," Palatino-Roman”);
myButton.labelfont(my_font);

> Note the leading space in the font name for the default font face. Replace the space with 'I' for italic, 'B' for bold, or 'P' for bold+italic.

Yes, that’s a very good point.

Usually it doesn’t much matter, but in this case, because Palatino-Roman begins with one of fltk’s “special font characters” (the P in this case) a leading space is a good idea. Also using a lower-case p can work too (I don’t believe font name matching is case sensitive, but fltk special font characters are always upper-case.)
Or I could be taking rot again.

[Jack Huffman]

On Friday, May 1, 2015 at 4:14:04 PM UTC-4, Greg Ercolano wrote:

On 05/01/15 12:46, Jack Huffman wrote:
> I just rebuilt/installed once with '-enable-xft' and another time with '-enable-x11' and I didn't see any difference in ../test/fonts or ../test/utf8. The build sequence I used is below:
> |
> ./configure -enable-xft

        Note: according to the --help output for configure, the flags is "--enable-xft"
        (and not "-enable-xft"), though it's possible it understands both.

        Check if 'configure' gave the following 'yes' answers for the Xft related tests:
:
checking X11/Xft/Xft.h usability... yes
checking X11/Xft/Xft.h presence... yes
checking for X11/Xft/Xft.h... yes
checking for XftDrawCreate in -lXft... yes 

I don't get any of these console outputs from 'configure' with either one or two dashes. I do get the same console output with one or two dashes. I sent the std-output to files and compared the results; they were the same with one or two dashes. If I grep the 'configure' std-output for 'xft' I get the following: Note there is a warning I didn't notice before; I think its going to stderr.

 

username@NextGen:~/Downloads/fltk-1.3.3$ ./configure --enable-xft | grep -i xft

configure: WARNING: Ignoring libraries " -lSM -lICE" requested by configure.

       Graphics: X11+Xft+Xdbe+Xinerama

username@NextGen:~/Downloads/fltk-1.3.3$ 

 

[Ian MacArthur]

On Fri May 01 2015 21:51:31, Jack Huffman wrote:
> Note: according to the --help output for configure, the flags is "--enable-xft"
> (and not "-enable-xft"), though it's possible it understands both.
>
> Check if 'configure' gave the following 'yes' answers for the Xft related tests:
> :
> checking X11/Xft/Xft.h usability... yes
> checking X11/Xft/Xft.h presence... yes
> checking for X11/Xft/Xft.h... yes
> checking for XftDrawCreate in -lXft... yes
> I don't get any of these console outputs from 'configure' with either one or two dashes. I do get the same console output with one or two dashes. I sent the std-output to files and compared the results; they were the same with one or two dashes. If I grep the 'configure' std-output for 'xft' I get the following: Note there is a warning I didn't notice before; I think its going to stderr.
>
> username@NextGen:~/Downloads/fltk-1.3.3$ ./configure --enable-xft | grep -i xft
> configure: WARNING: Ignoring libraries " -lSM -lICE" requested by configure.
> Graphics: X11+Xft+Xdbe+Xinerama
> username@NextGen:~/Downloads/fltk-1.3.3$

Hmm, that’s very curious.

On a clean checkout on a 32-bit F17 system, I get... (from ./configure --enable-xft , though that is the default now anyway...)

checking for freetype-config... /usr/bin/freetype-config
checking for FcPatternCreate in -lfontconfig... yes

checking X11/Xft/Xft.h usability... yes
checking X11/Xft/Xft.h presence... yes
checking for X11/Xft/Xft.h... yes
checking for XftDrawCreate in -lXft... yes

and then later on...

Graphics: X11+Xft+Xdbe+Xinerama

Which is what I’d expect.

Note that for XFT to work you need to have both XFT and Fontconfig working normally; they are inextricably interdependent...

So you need to ensure your system has the dev packages for both FC and XFT, and then it ought to work as expected.

From the screenshots you posted, that is certainly the old bitmapped fonts from the Xlib font engine you are getting, which is not the preferred option these days (though there are still cases where it is the better bet, general desktop use is not one of them!)

[Greg Ercolano]

On 05/01/15 13:51, Jack Huffman wrote:
> On Friday, May 1, 2015 at 4:14:04 PM UTC-4, Greg Ercolano wrote:
> Check if 'configure' gave the following 'yes' answers for the Xft related tests:
> :
> checking X11/Xft/Xft.h usability... yes
> checking X11/Xft/Xft.h presence... yes
> checking for X11/Xft/Xft.h... yes
> checking for XftDrawCreate in -lXft... yes
>
> I don't get any of these console outputs from 'configure' with either one or two dashes.

Then sounds like Xft development stuff isn't installed on this system.

Try installing it; look around for "xft" related packages using
apt-get or apt-cache (or whatever the package manager search tool
is under Ubuntu.. e.g. 'apt-cache search xft' maybe? And 'grep -i dev')

Here's some apt-get commands I used to run when I set up an
Ubuntu system some years ago.. not sure if the package names
are the same, but FWIW:

apt-get install g++
apt-get install manpages-dev -- for making man pages (troff/nroff/etc)
apt-get install subversion -- aka svn
apt-get install libx11-dev
apt-get install libxt-dev
apt-get install libxft-dev <-- YOU'RE MAYBE MISSING THIS
apt-get install valgrind
apt-get install libglut3-dev -- gets opengl, glut, etc
apt-get install doc-linux-html -- /usr/share/doc/HOWTO

[Greg Ercolano]

On 05/01/15 14:21, Ian MacArthur wrote:
>> username@NextGen:~/Downloads/fltk-1.3.3$ ./configure --enable-xft | grep -i xft
>> configure: WARNING: Ignoring libraries " -lSM -lICE" requested by configure.
>> Graphics: X11+Xft+Xdbe+Xinerama
>> username@NextGen:~/Downloads/fltk-1.3.3$
>
> Hmm, that’s very curious.

Ya, configure isn't good about reporting errors if you request
something like this, as it seems to just fallback.

I'm surprised it doesn't say 'no' for the tests, but it's probably
failing on a different check, e.g. the freetype-config or FcPatternCreate
check. I imagine if it fails one of those first, it won't even get
to the *Xft* tests.