STR #1328: configure --enable-xft breaks fl_xfont

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
Subsystem:	X11
Summary:	configure --enable-xft breaks fl_xfont
Version:	1.1-current
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:

#1	wilson.afn 09:32 Jun 16, 2006

foo.cxx
0k

Trouble Report Comments:

#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: http://keithp.com/~keithp/talks/xtc2001/paper/xft.html, 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

numer->number 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.