This sounds like one of the two common font problems with VW on Linux.
Try "xset fp rehash" in a terminal (or add it to your VW startup
script). See below for more details.
> From: Rick Flower [mailto:
[hidden email]]
>
> Does anyone out there use VW w/ VNC? I recently upgraded my Unix
server
> from Fedora Core 3 (FC3) to FC6 and find that certain operations just
> aren't happy w/ VW in this configuation -- particularly with font
> loading.. Perhaps this is because when I originally loaded VW I was
> using a non-VNC connection (I think) and perhaps the fonts were
> different than what VNC offers? Anyway, with a VNC connection I find
> that I'm unable to use Store for any operations that require
installing
> a parcel (to put up the small dialog box showing parcel loading
status)
> and a few other things -- all of the rest work fine..
>
> Below is the name of the font its complaining about not having :
>
> -adobe-courier-medium-r-normal--*-94-100-100-m-*-iso8859-1
>
> Now, the thing that's screwing with me is the 94 which I believe is
the
> point size -- on all of my X-based machines (including my mac using
OSX
> and Reflection X on a PC I've got), the font point sizes are numbers
> such as 80,100,120,140,etc.. Not 94.. I've checked all 3 x11 servers I
> generally use and none have this font.. I'm sure some sort of font
> substitution is taking place for the non-vnc connections... Has anyone
> seen this? Below is the partial backtrace of a typical time when it
> fails (copied by hand -- don't ask!):
>
> Screen(Object)>>error:
> Screen(Object)>>primitiveFailed.
> Screen>>primAllocateFontNamed:
> Screen(HostGraphicsDevice)>>fontNamed:fromClass:encoding
> XFont class>>createFont:toResemble:on:
> FontPolicy>>findFont
Take a look at Cincom's bug report against Ubuntu / X / Gnome here:
https://launchpad.net/ubuntu/+bug/52163In order to reproduce the X portion of the problem, all you need is to
have both the scaled and unscaled paths to some bitmap font directory
(e.g., /usr/share/X11/fonts/100dpi) in the font path, and then execute a
bad XSetFontPath() request. E.g.:
#> xset +fp /usr/share/X11/fonts/100dpi:unscaled
#> xset fp+ /usr/share/X11/fonts/100dpi
#> xset fp rehash
#> xset +fp /a/bad/fontdir
Now try:
#> xlsfonts -fn
'-adobe-helvetica-medium-r-normal--*-*-100-100-p-*-iso8859-1'
=> returns the name of a scalable bitmap font
('-*-0-0-100-100-p-0-*')
#> xlsfonts -fn
'-adobe-helvetica-medium-r-normal--*-94-100-100-p-*-iso8859-1'
=> reports that a concrete instance of the font in a 13 point size
can be found
#> xlsfonts -l -fn
'-adobe-helvetica-medium-r-normal--*-94-100-100-p-*-iso8859-1'
=> asking for properties of that font, which requires actually
instantiating it, reports that no such font can be found
#> xset fp rehash
=> rebuilds the font path
#> xlsfonts -l -fn
'-adobe-helvetica-medium-r-normal--*-94-100-100-p-*-iso8859-1'
=> reports a matching concrete instance of the scalable font
In other words, X is simply lying to us: it says the font is there, but
when you ask for it, it says it doesn't exist.
Steve
PS the other VW font problem is that asking for a very small font (7
rather than 94) will give the same symptoms as above. A workaround is to
insert a "max: 8" into the font name building code in XFont, so 7 and
lower never get asked for. 94 is a 13pt font, so 7 is so small this
often doesn't really matter.
Locked
