STR #1328

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]

Return to Bugs & Features | Roadmap 1.1 ]

STR #1328

Application:FLTK Library
Status:1 - Closed w/Resolution
Priority:4 - High, e.g. key functionality not working
Scope:2 - Specific to an operating system
Summary:configure --enable-xft breaks fl_xfont
Created By:wilson.afn
Assigned To:mike
Fix Version:1.1-current (SVN: v5262)
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:

Name/Time/Date Filename/Size top right image
#1 wilson.afn
09:32 Jun 16, 2006
bottom left image   bottom right image

Trouble Report Comments:

Name/Time/Date Text top right image
#1 wilson.afn
09:32 Jun 16, 2006
FC5, GCC 4.1.1 on P3

Make FLTK with xft enabled (--enable-xft, whatever the heck that is).  Then, compile attached example: "fltk-configure --compile foo.cxx".  Foo asks for some font or another, but comes up empty.  Seems to work OK without xft.

Fedora's "yum install fltk fltk-devel" retrieves a version built with this option, and that's why flwm wouldn't work on my laptop.
#2 wilson.afn
10:23 Jun 16, 2006
I'd like to withdraw this STR.  My experiment is not repeatable on either of two other FC5 boxes.  There must be something hosed with Xft on the laptop.  
#3 matt
11:18 Jun 16, 2006
In the corresponding source code, I found these lines (src/fl_font_xft.cxx):

#if XFT_MAJOR < 2
  fl_xfont    = f->font->u.core.font;
#endif // XFT_MAJOR < 2

IIRC, the direct interface to the xfont struct was abandoned at version XFT2 and later. If you happen to know how to get from XftFontOpen to the xfont structure, I am sure we will be able to add this in for you.
#4 wilson.afn
13:00 Jun 16, 2006
I'm really not sure this is worth fixing; I got FLWM working again on the laptop.  Only Bill would go poking around in an XFontStruct for his sideways title bars :-D.

But now it is much clearer.

I saw the "#if XFT_MAJOR < 2", but in a dyslexic moment read it as "#if XFT_MAJOR >= 2", checked my laptop's <Xft.h>, found I was running Xft 2.1.8, and immediately dismissed it.

On the other FC5 boxes, libXft-devel wasn't even installed!  In this case, "--enable-xft" is apparently impotent and silently generates "#define USE_XFT 0".

I have resarched Xft, and I'm now informed it is the "freetype extension" for X.  As I understand it, this makes your text look all fuzzy and sends you in search of your glasses. You put them on, but it doesn't help.

From:, you can get only get an XFontStruct for fl_xfont if you happen to select a "core font".  In this limited case, you might be able to:

  if (f->font->core) fl_xfont = f->font->u.core.font; // See URL
  else               fl_xfont = 0;                    // ??? See below

But what if you're not using a "core font"?  I suppose you could "new" one and fill it in from the data in the corresponding XftFontStruct, but just trying to discover a correspondence makes my head hurt.

I would rather withdraw my STR and sweep this thing under the rug!
#5 matt
23:27 Jun 21, 2006
RFC: I propose that we remove fl_xfont if FLTK is compiled with xft (or xft>=2.0). fl_xfont is never set to anything but NULL, so its existence is misleading, and software that depends on it will fail. Instead I suggest we introduce fl_xftfont to hold the corresponding xft font pointer.

In a less drastic move, we could have both varaibles coexist and an application writer could determine if xft is linked in by checking if either fl_xfont or fl_xftfont is NULL.
#6 wilson.afn
13:19 Jun 22, 2006
Will removing fl_xfont produce a better error message than "segfault ..."?  I'm not sure it will.  With the "shared object" hack, I might not have learned of an "undefined reference to ZFLSiPF6fl_xfontNotUsedInUSA347xyzzy" until I tried to run FLWM.  Even then, I probably still would have broken out GDB and spewed forth same numer of swear words.

If I'm the only one bitten by this problem, it is not a serious bug.  I propose the less-drastic alternative of changing the documentation to mention that "fl_xorg isn't valid when FLTK is using Xft".  If I had seen a statement to this effect, I would have cursed my own stupidity and not filed an STR at all.

+1 for changing the documentation only
+0 for nuking fl_xorg when Xft is in use (and documenting the change)
-1 for making things more complicated by adding yet another variable.
#7 wilson.afn
13:22 Jun 22, 2006
fl_xorg->fl_xfont :P
#8 matt
04:26 Jul 18, 2006
Fixed in Subversion repository.

I did add "fl_xftfont" to give X11 developers access to the selected font. The rule is simple and it is explained in the docs: if fl_xftfont is NULL, thene the font pointer is in fl_xfont. If fl_xftfont is not NULL, the FLTK was compiled using Xft and fl_xfont is most likely NULL (unless an equvalent xfont exists and Xft is older than version 2).

Since I am not on an X11 machine, I did this change blindly. Please, someone test if I put a typo in the source or documentation. Thanks.
bottom left image   bottom right image

Return to Bugs & Features ]


Comments are owned by the poster. All other content is copyright 1998-2022 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to ''.