Attempting to add a font server to the font path with XFree86 4.0.1, with a command such as: xset fp+ tcp/jupiter:7100/all gives the following error: X Error of failed request: 86 Major opcode of failed request: 51 (X_SetFontPath) Serial number of failed request: 10 Current serial number in output stream: 13
On a default install of XFree86, the font server should already be set up. Or are you trying to run a networked font server? Please show me your config files so I can try to reproduce the problem.
Here is the FontPath section of my XF86Config-4 file: Section "Files" FontPath "unix/:7100" EndSection
Please try loading the freetype and Type1 modules in your config. If that doesn't solve the problem, try the latest rwhide release (4.0.3) and do the same. It is recommnded to use xfs on the workstation itself though. Do any of these suggestions solve the problem for you?
Loading the freetype and type1 modules did not help. I will have to try XFree86 4.0.3, which may take me a bit longer to test. I will let you know what the result is.
Do you _have_ xfs running at boot time?
I installed XFree86-4.0.3 and tried the xset fp+ command above. I still get the same error.
Oops. I missed a question above. Yes, xfs is running at boot time. I suspect that if I opt not to run it and put the font paths in the Xserver's config file, it would probably allow me to add a font server.
why aren't the type1 modules in the Xserver loaded by default? In my config on rhl 7.1 the type1 font module in XF86Config-4 is commented out. Is there a good reason for doing this? programs like Mathematica retch at this. b/c they try to modify the fontpath via xset and if they try to load a fontpath of type1 fonts and do not have the type1 module loaded then it will error out with great death. ditto w/abiword if you've not added abiword's fonts to xfs
This smells like a duplicate of bug #28265.
The only thing is bug 28265's solution was to put the commented out modules into the X configuration. I'd say that the commented out modules shouldn't be commmented out.
This is a dupe of 28265. There is no easy way to rectify this. We use xfs by default for several very good reasons. It doesnt make a lot of sense to use both xfs and the X server together for serving fonts. The X server when rasterizing glyphs, can block for long periods of time, which shows up as jerky mouse movements, and sometimes can block for a long period of time appearing to just lock up completely. The problem is most noticeable with large glyph sets such as those used in Chinese, Japanese, and Korean. It is due partially to the fact the X server is not multi threaded. The solution to this problem is to reconfigure your system to have all font paths served by xfs, or to reconfigure it to not use xfs at all, and instead serv fonts with the X server. Many people claim that they do not ever see the aforementioned problem I have described, so it is always an option. In any case, xset talks to the X server, and not to xfs, so there is no way this will work with xfs. *** This bug has been marked as a duplicate of 28265 ***