| [ Return to Bugs & Features | Roadmap 1.1 | SVN ⇄ GIT ]
STR #1809
Application: | FLTK Library |
Status: | 1 - Closed w/Resolution |
Priority: | 2 - Low, e.g. a documentation error or undocumented side-effect |
Scope: | 2 - Specific to an operating system |
Subsystem: | Multiple |
Summary: | fltk-1.1.8 XFT font support for GL and xft_font enahancements |
Version: | 1.1-current |
Created By: | ianmacarthur |
Assigned To: | mike |
Fix Version: | 1.1-current (SVN: v5999) |
Update Notification: | |
Trouble Report Files:
Trouble Report Comments:
|
#1 | ianmacarthur 08:54 Oct 12, 2007 |
| The current implementation of fltk with XFT-2 support for the 1.1.x series (and also the fltk2.x series, I believe) always returns the same default font for gl_font() calls, regardless of the face or size requested by the user. This differs from the behaviour on other platforms, or under X with non-XFT support (or even with XFT-1 support!) and is not very useful.
There are a number of other weaknesses in the XFT font loading that can also be addressed.
Attached are a series of patches, designed to be applied incrementally, each adding a little additional functionality to the core build. Please consider these for addition to the 1.1.8 core.
patch1: Adds better support to allow gl_font() to load fonts with selected face and size when fltk is built against XFT-2 or later. I think this is pretty much a "must have" addition.
patch2: Builds on patch1, improving the basic XFT fontopen() code to gracefully handle being passed XLFD style font names, as often happens when porting code from a previous, non-XFT build standard. The default XFT fontopen code will fail to open a reasonable font in that case, this revised code should generally do the "Right Thing" if passed an adequately well-formed XLFD name. I think this is a "very useful" addition.
patch3: Builds on patch2 to allow a comma separated list of XFT font names to be passed to fontopen(), and forms a fontmatch pattern that finds the best available match from the list. This is intended to ease porting code to other platforms where the list of available fonts may not be known in advance (several "likely candidates" can be passed in this case, increasing the likelihood of getting a valid font match.) I think this is a "nice to have" addition.
Thanks, -- Ian | |
|
#2 | ucko.debian 17:16 Oct 31, 2007 |
| For the most part, these work quite well; thanks for putting them together! However, patch3 always forces XFT_RENDER off with Xft 2, whereas the original (somewhat obscure) logic did so only with fontopen's "core" argument set to true. A patch4 fixing that is on its way. | |
|
#3 | ianmacarthur 11:52 Nov 01, 2007 |
| On 1 Nov 2007, at 0:16, Aaron M. Ucko wrote:
> For the most part, these work quite well; thanks for putting them together! > However, patch3 always forces XFT_RENDER off with Xft 2, whereas the > original (somewhat obscure) logic did so only with fontopen's "core" > argument set to true. A patch4 fixing that is on its way.
This is intended. XFT-2 doesn't support "core" fonts. Only XFT-1 did. You can make a patch for this, but I suspect it won't actually work!
Cheers, -- Ian | |
|
#4 | ianmacarthur 09:50 Nov 02, 2007 |
| OK, I've tried Aaron's patch4 and it does work. I think it is conceivably "more right" than what I had, although both seem to work OK in practice. I'd suggest we include patch4 along with patch3. -- Ian | |
|
#5 | mike 09:55 Dec 15, 2007 |
| Fixed in Subversion repository. | |
[ Return to Bugs & Features ]
|
| |