Re: Problem with truetype fonts caused by not building FreeType module?
Lev S Bishop wrote: (Replying to my own message) I messed about with the host.def.in and got it to sort of work. My host.def.in is: #define BuildFreeType YES #define BuildServersOnlyYES #define XnestServer NO #define XVirtualFramebufferServer NO #define BuildXWinMultiWindowExtWM NO #define EtcX11Directory @sysconfdir@ #define ProjectRoot @prefix@ I also had to grab xc/lib/font/FreeType from the freedesktop cvs (tag CYGWIN if that's relevant). (Using the latest src packages from setup for the other sources). 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. Harold
Re: Problem with truetype fonts caused by not building FreeType module?
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 - 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? I could be wrong about all this but the release notes seem to back me up: http://freedesktop.org/~xorg/X11R6.7.0/doc/RELNOTES6.html#41 Lev
Re: Problem with truetype fonts caused by not building FreeType module?
Lev, 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: http://freedesktop.org/~xorg/X11R6.7.0/doc/RELNOTES6.html#41 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. :) Harold
Re: Problem with truetype fonts caused by not building FreeType module?
Harold wrote: Lev S Bishop wrote: - 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. No, I am sure that I am correct about the static linking, but I was not very clear what I was saying. There are *two* things called freetype under discussion. There is the freetype library (the thing that is available from www.freetype.org, is independent of X, and is contained in cygfreetype-6.dll from the package libfreetype26-2.1.5-1) and there is the freetype module (aka FreeType backend, formerly known as xfsft, this is the thing that's part of the x server). From now on I'll call the former freetype the freetype2 library and the latter the freetype backend. The freetype backend deals with making truetype fonts look and feel to the rest of the x server like all other x core fonts, XLFDs, fonts.dir, fonts.alias, etc) but to do the actual rendering it calls upon the freetype2 library. You can think of it as a wrapper for the freetype2 library. There is a version of the freetype2 library in the xc source tree, but we don't want to use it because we prefer to use a seperately installed (more up to date) version, so we set HasFreeType2 YES (typo in my earlier email, missed off the 2 on HasFreeType2). The freetype2 library can be dynamically linked (its cygfreetype6.dll). Following me so far? Now, here's what I was really getting at: the server architecture is such that certain parts of the X server are loadable modules -- whether or not they get loaded into the server is configured *at runtime* by looking in the Module section of the config file (xorg.conf), for lines like 'Load type1' to load the type 1 font rasterizer, etc (this is as opposed to load time dynamic linking, which is what cygcheck tells you about). See: http://freedesktop.org/~xorg/X11R6.7.0/doc/xorg.conf.5.html#sect5 However, cygwin/x doesn't support loadable modules like that (we don't set DoLoadableServer YES, and we don't have a config file to read even if we did) so the freetype backend gets built statically into libXfont.a, and libXfont.a is linked into XWin.exe. So the path is like this for cygwin/x: XWin.exe is linked to libXfont.a, which includes the freetype backend, which depends on the freetype2 library. So the ultimate situation is that XWin.exe is statically linked to the freetype backend but dynamically linked to the freetype2 library. (With recent builds, the situation was: XWin.exe is linked to libXfont.a, which doesn't include the freetype backend, so nothing in XWin.exe depends on the freetype2 library, so cygcheck on XWin.exe doesn't report cygfreetype6.dll). Whether or not we use the freetype backend is controlled by the build switch: BuildFreeType (note capitalization). The freetype2 library is controlled by the switch HasFreetype2. We already have HasFreetype2 YES, but we need to add BuildFreeType YES. The switches control the building of completely orthogonal branches of the source tree. I hope that was clear? Harold: you mentioned something about BuildFontconfig. There is no such switch. There is only a switch BuildFontconfigLibrary. This gets its default (correctly) due to our setting HasFontconfig YES. You don't need to change anything here. Anyway, we're talking about server-side fonts here, which don't use fontconfig. The client-side font mechanism does use fontconfig, and that side of things is working perfectly right now -- no need to mess about with that. Lev
Re: Problem with truetype fonts caused by not building FreeType module?
Lev S Bishop wrote: Harold wrote: Lev S Bishop wrote: - 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. No, I am sure that I am correct about the static linking, but I was not very clear what I was saying. There are *two* things called freetype under discussion. There is the freetype library (the thing that is available from www.freetype.org, is independent of X, and is contained in cygfreetype-6.dll from the package libfreetype26-2.1.5-1) and there is the freetype module (aka FreeType backend, formerly known as xfsft, this is the thing that's part of the x server). From now on I'll call the former freetype the freetype2 library and the latter the freetype backend. Uhh... you could have just called it the freetype backend in the font library. Yes, the font library is always statically linked into the server due to a limitation in the way it was implemented. I don't disagree that there is a freetype portion of the font library and that it was not being built. The freetype backend deals with making truetype fonts look and feel to the rest of the x server like all other x core fonts, XLFDs, fonts.dir, fonts.alias, etc) but to do the actual rendering it calls upon the freetype2 library. You can think of it as a wrapper for the freetype2 library. There is a version of the freetype2 library in the xc source tree, but we don't want to use it because we prefer to use a seperately installed (more up to date) version, so we set HasFreeType2 YES (typo in my earlier email, missed off the 2 on HasFreeType2). The freetype2 library can be dynamically linked (its cygfreetype6.dll). Yup. Now, here's what I was really getting at: the server architecture is such that certain parts of the X server are loadable modules -- whether or not they get loaded into the server is configured *at runtime* by looking in the Module section of the config file (xorg.conf), for lines like 'Load type1' to load the type 1 font rasterizer, etc (this is as opposed to load time dynamic linking, which is what cygcheck tells you about). See: http://freedesktop.org/~xorg/X11R6.7.0/doc/xorg.conf.5.html#sect5 However, cygwin/x doesn't support loadable modules like that (we don't set DoLoadableServer YES, and we don't have a config file to read even if we did) so the freetype backend gets built statically into libXfont.a, and libXfont.a is linked into XWin.exe. Right, I don't dispute that, but your earlier message was really confusing the names of things and we were not talking about the same thing. Whether or not we use the freetype backend is controlled by the build switch: BuildFreeType (note capitalization). The freetype2 library is controlled by the switch HasFreetype2. We already have HasFreetype2 YES, but we need to add BuildFreeType YES. The switches control the building of completely orthogonal branches of the source tree. Right, that is what I said. I said that no longer including xorg.cf some time ago caused the BuildFreeType flag to start defaulting to NO instead of its previous YES. And I also credited you with discovering that the flag doesn't control building the library but instead controls whether the other clients and libraries in the tree use freetype and whether or not any code dependent upon freetype is built. What more do you want? You must not have read the end of my last message very clearly. Harold: you mentioned something about BuildFontconfig. There is no such switch. I don't care, you know what I meant. I don't have time to read ten files for each sentence I write in these really long and trying emails. That is why I would prefer that we just converse in IRC about this... it is a lot easier on me. Harold
Re: Problem with truetype fonts caused by not building FreeType module?
Harold wrote: What more do you want? You must not have read the end of my last message very clearly. I just didn't want you to do a complete rebuild with the wrong flags and break something that worked before or waste your time any more than needed. Just trying to spell everything out as precisely and clearly as I can, because I find it very confusing and I have to be really careful what I say or I end up tripping over myself with multiple meanings for freetype. I find build systems confusing at the best of times, and whoever decided to change the name from xfsft to freetype has a twisted sense of humour :-) Sorry if it came accross as pedantic or patronizing. I can tell you if I tried to discuss this in real time on IRC I'd be utterly incomprehensible. Lev
