Xvnc searches fonts on the wrong directory

Bug #69397 reported by Alessandro Morgantini
This bug report is a duplicate of:  Bug #3593: vnc4server uses wrong font path. Edit Remove
4
Affects Status Importance Assigned to Milestone
vnc4 (Ubuntu)
New
Undecided
Unassigned

Bug Description

Binary package hint: vnc4server

After an upgrade from Dapper, Xvnc continues to search the fonts directories under /usr/share/X11/fonts, despite that on Edgy they are under /usr/share/fonts/X11. This is the output of Xvnc:

Xvnc Free Edition 4.1.1
Copyright (C) 2002-2005 RealVNC Ltd.
See http://www.realvnc.com for information on VNC.
Underlying X server release 70000000, The X.Org Foundation

Mon Oct 30 23:35:40 2006
 vncext: VNC extension running!
 vncext: Listening for VNC connections on port 5902
 vncext: created VNC server for screen 0
Could not init font path element /usr/share/X11/fonts/misc/, removing from list!
Could not init font path element /usr/share/X11/fonts/TTF/, removing from list!
Could not init font path element /usr/share/X11/fonts/OTF, removing from list!
Could not init font path element /usr/share/X11/fonts/Type1/, removing from list!
Could not init font path element /usr/share/X11/fonts/CID/, removing from list!
Could not init font path element /usr/share/X11/fonts/100dpi/, removing from list!
Could not init font path element /usr/share/X11/fonts/75dpi/, removing from list!

Fatal server error:
could not open default font 'fixed'

Then Xvnc exits.
Doing a symbolic link to the right path solves for me.

description: updated
Revision history for this message
Jerome Lacoste (jerome-lacoste) wrote :

This problem is the same as #3593, which was already present in Breezy. The -fp option works for me (but isn't documented in the man page...).

Revision history for this message
Jerome Lacoste (jerome-lacoste) wrote :

When I mean it's the same as in Breezy, only the root of the problem is the same.

The font paths to be searched are different in Breezy and Edgy. But in both cases, vnc4server search them in the wrong place and fails in the same way.

Revision history for this message
Alessandro Morgantini (gpz500) wrote :

Ok.
I made a "Backport fix to releases" on the bug #3593, to signal that the problem is present in Edgy also: it was clear by the comments, not by the header.

Revision history for this message
Nicola Ferralis (feranick) wrote :

This seems a duplicate of bug Bug #3593.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.