haozhou@ACSU.BUFFALO.EDU (hao zhou) (08/10/90)
I have compiled xtex on our SunCluster machines (sun4 and sparcs). It works fine with tfm fonts. However, it prints some error messages as follows whenever it starts. Missing cmcsc10.122 ( -mag 1000 -scaled 1440 cmcsc10 ) Missing cmcsc10.147 ( -mag 1000 -scaled 1728 cmcsc10 ) Missing cmtt10.147 ( -mag 1000 -scaled 1728 cmtt10 ) .... We have X11/R4 fonts and tex85 fonts on our machines but I couldn't find a way to tell xtex the path for. I tried to change xtex resource Xtex.ad and add in *.xFontPath. But that doesn't help at all. All X11 fonts and tex85 fonts have the extension .snf but all the missing font don't have such extension. Actually xtex works fine without the fonts which are missing. I wonder if we can ignore the error messages. Thanks. Hao Zhou reply to : haozhou@acsu.buffalo.edu
grunwald@FOOBAR.COLORADO.EDU (Dirk Grunwald) (08/11/90)
if your fonts (e.g., cmr10.85.snf.Z) live in directory /some/path/fonts, then say: % cd /some/path/fonts % mkfontdir [ only do this once ] % xset +fp /some/path/fonts % xset fp rehash % xlsfonts | grep cmr10 If you don't get a list of cmr10 fonts with more numbers after them, make certain you build the font directory file. Sadly, you need to do this each time you start your X server, unless you put the fonts in a ``default'' location or change the X startup script to indicate the new font directory. A future change to xtex will automatically install the path, but that's not done yet.
grunwald@foobar.colorado.edu (Dirk Grunwald) (08/11/90)
On the subject of 'xtex', several people have told me that it fails when hitting the quit-page button in the page popup (e.g., when the xtex-page-quit() is taken). This action deletes a widget tree in which an InstallAccelerators has been done. The core dump traces back to a call to RemoveAccelerators or somesuch; I'm not making that call, it's a consequence of the widget tree deletion. Now, allegedly, this only occurs with X fixes 13,14 installed. fixes 1-12 work fine (that's what I use), but 13,14 break it. Fixed 13,14 introduced shared accelerator tables or translation tables. Does some Wise Person know if these problems have any semantic affect on programs? Likewise, are there fixes-in-the-wings that would be helpful? I've added code to insure that I only InstallAccelerator the accelerators once, thinking it was a resource maintaince problem, but that doesn't seem to help.
swick@ATHENA.MIT.EDU (Ralph Swick) (08/15/90)
... deletes a widget tree in which
an InstallAccelerators has been done.
The core dump traces back to a call to RemoveAccelerators or somesuch;
...allegedly, this only occurs with X fixes 13,14
installed.
Right. This is a recently-discovered problem with fixes 13,14.
Does some Wise Person know if these problems have any semantic affect
on programs?
(Not that I necessarily claim to qualify, but...:-)
The patch changed the manner in which translation tables
containing installed accelerators are stored. The bug
is triggered when multiple accelerator tables are installed
on the same destination widget and any of the accelerator
source widgets are subsequently destroyed.
One additional side-effect of {13,14} is that repeated
calls to XtGetValues for XtNtranslations will not necessarily
return the same value each time. It's not clear from the
specification whether or not applications should be surprised
by this behavior. I'd be happy to discuss this separately
if there is interest.
At present there is no work-around for the accelerator source
widget destruction bug. Fix 15 is in the works. Sorry for
the aggravation; we were hustling to get things out that various
people were depending upon and made too many testing shortcuts.
(It was supposedly tested by 3 independent groups, too!:-(
You might want to temporarily back out {13,14} until 15 is
published.
-Ralph