Path: utzoo!attcan!uunet!lll-winken!ames!mailrus!tut.cis.ohio-state.edu!bloom-beacon!EXPO.LCS.MIT.EDU!jim From: jim@EXPO.LCS.MIT.EDU (Jim Fulton) Newsgroups: comp.windows.x Subject: Re: X11R3 xlsfonts doesn't Message-ID: <8902272357.AA10155@expo.lcs.mit.edu> Date: 27 Feb 89 23:57:45 GMT References: <8902272324.AA21940@nav.icst.nbs.gov> Sender: daemon@bloom-beacon.MIT.EDU Organization: X Consortium, MIT Laboratory for Computer Science Lines: 44 > I also have a problem with xfd only being able to > display fonts in the misc directory, but not in the 75dpi (which is what > the Sun uses) or the 100dpi directorys. Do you mean that you tried: xfd -adobe-courier-bold-o-normal--10-100-75-75-m-60-iso8859-1 and it spat back a usage message because you forgot to give it the -fn flag to indicate that -ado... isn't an command line option: xfd -fn -adobe-courier-bold-o-normal--10-100-75-75-m-60-iso8859-1 Or that plain old xlsfonts didn't list any of the new fonts at all? Did xset q show that the 75dpi and 100dpi directories were in the font path? Also, perhaps unrelated, but some sites have reported problems with hostent structs not agreeing with their libraries. > Is the FontCompilerFlags definition > correct? I have heard varying things about whether it was needed or not. It is obsolete. > And finally, there > is only an explicit mention of SunOS 3.4; the Sun.macros file in this case > is robust, doing things like `#if ... OSMajorVersion >= 4', but I can > easily envision someone testing for equality somewhere deep in the code > and screwing things up. Am I just paranoid? The default of 3.4 is because that is what expo was running at the time of the release. The OSMajorVersion and OSMinorVersion are used by various Imakefiles to determine whether or not to do things like turn off the optimizer or use /usr/etc/getty instead of /etc/getty. We've heard folks who are running 4.0 claim that setting the version numbers worked for them.