Problem with truetype fonts caused by not building FreeType module?
Harold L Hunt II
Thu Apr 8 17:28:00 GMT 2004
Lev S Bishop wrote:
> Harold wrote:
>>Now you are getting somewhere... the implication of "BuildFreeType NO"
>>is that you are going to use the installed version since we set
>>"HasFreeType YES", but this does not appear to be the case. We'll either
>>have to fix the build rules or just set BuildFreeType to YES but not
>>actually include it in our distribution, just as we do for Xft.
> I think you have the wrong idea about FreeType backend. My understanding
> is that this is one of the modules which implement server-side truetype
> (the other being X-TrueType, the "xtt" module - only one of the two is
> allowed, and X-TrueType is scheduled for demolition in the next release).
> It's built *around* the FreeType library (which is what we say we have by
> asserting "HasFreeType YES"...) but it's not the same thing as having the
> library. I think all we need to do is set BuildFreeType to yes
Hmm... I was thinking we were setting BuildFreetype to NO and
BuildFontconfig to NO in cygwin.cf to prevent these already installed
libraries from being compiled, when in fact we were not doing so. You
are correct that no longer including xorg.cf (or xfree86.cf) caused the
default for BuildFreetype and BuildFontconfig to flip from YES to NO and
you are correct that these signal if programs should link against these
libraries. There are separate flags call BuildFreetype2Library and
BuildFontconfigLibrary that we need to set to NO to prevent just the
library from being built, but those should actually pickup the correct
defaults from X11.tmpl since we set HasFreetype2 and HasFontconfig to YES.
> - the
> resulting module gets statically linked into libXfont.a (rather than being
> a loadable module, as it would be in many other X servers, since we don't
> do loadable modules on cygwin/x), and from there gets linked into XWin.exe
> and xfs.exe (I understand xfs.exe is currently non-functional, though),
> and perhaps some other places?
Regarding the static linking, that is not correct. I had noticed
recently that XWin.exe was no longer linked to cygfreetype-6.dll (do a
'cygcheck XWin.exe' to find out what DLLs are being linked to) and was
wondering what happened.
> I could be wrong about all this but the release notes seem to back me up:
No, you're not wrong, you helped me find the correct flags we need to
set and you helped find the reason why the defaults for some of these
flags has changed. Yay, now I can do a complete rebuild. :)
More information about the Cygwin-xfree