Re: Font sources

[Tim X]

"Dave Pawson" <dave.pawson@gmail.com> writes:

> On 14/09/2007, Tim X <timx@nospam.dev.null> wrote:
>
>> when running under X, emacs gets its fonts from the X server.
>
> $ service status-all
> ...
> xfs dead but pid file exists
>
> etc.
>
> [dpawson@marge ~]$ service xfs start
> Starting xfs: rm: cannot remove directory `/tmp/.font-unix': Operation
> not permitted
> mkdir: cannot create directory `/tmp/.font-unix': File exists
> chown: changing ownership of `/tmp/.font-unix': Operation not permitted
> chmod: changing permissions of `/tmp/.font-unix': Operation not permitted
> touch: cannot touch `/var/lock/subsys/xfs': Permission denied OK  ]
>

Generally, services that are run from /etc/init.d need to be
started/stopped as root. Try starting that service again as root and see
what happens. Note however that this still may not be your main
problem. sometimes font servers are installed, but never used by the X
server - it all depends if the X server is configured to use the font
server. The fact you have a pid file indicates that at least it was running
at some point. Also, this service should have started when you booted - you
may have to look into how ubuntu manages runlevels. The basic scheme is
pretty straight forward, but many distros have added scripts and gui tools
to make managing runlevels and controling what services are started
'easier'. Personally, I don't bother which those tools and prefer to manage
it myself, but that can bite me in the ass from time to time as the distros
expect it is being managed by whatever mechanism they have implemented.

The services which are started at boot time are controlled by 'rc'
scripts. Depending on your runlevel (probably rnlevel 3). For example, if
you have a look in /etc, you will see directories like rc1.d, rc2.d, rc3.d
and so on. These directories contain symbolic links to files in
/etc/init.d, which are the start/stop scripts for various services. The
symbolic links have names starting with s or k (start or kill) and numbers
at the start. When your system changes runlevels, it first looks in the
directory corresponding to the current runlevel for scripts starting with k
and executes them with an argument of 'stop'. The order of execution is
determined by the numbers in the name. then it goes to the rc directory
corresponding to the runlevel you are changing to and executes all the
scripts starting with an s (start). You can find out more about runlevels
in the /etc/inittab file and the init and inittab man pages.


>
> Interesting.
> From (warning, long url)
> http://fedoraproject.org/wiki/FWN/Issue91#head-19ec5321d5ef52030bdd6910bd5b9a3bf97d5cb3
>
> quote.
>
> Olivier's comment and bravely plunged on[5], arguing that Emacs was
> "going the way of the dodo because it targets 1995-ish desktops". A
> swarm of questioners including AndrewHaley sought clarification from
> Nicolas, to which he responded[6] that Emacs didn't use the desktop
> font infrastructure, i18n, a11y, one of the main GUI toolkits, or
> integrate with the printing infrastructure.
>
>
> Seems like xfs is going out of fashion on Fedora.
> Wonder if other OS's will follow this direction.
>

It is possible font servers will decline in use. Actually, I didn't run a
font server until it became a sort of default configuration (which I think
was back when I was running Red Hat). Before then, I hust had font paths
hard coded into my X config file. At some levels a font server is overkill
for a stand alone Linux box. 

At one time, using a font server was the only way to get true type fonts to
work under X. In fact, I think you had to have a modified font server to do
this and its probably why some distros started installing and configuring a
font server as part of the X setup. I think some of those limitations with
the X server have been removed in later versions and you can use true type
fonts directly without the need of a font server, but I'm not ceratin about
that. Its not my area of expertise and I could be very wrong or only
partially correct (or is that partially wrong?)/ I think many of the issues
here relate to historical and legacy concerns combined with portability and
cross platform objectives. I think the X Windows architecture was very much
before its time and for years was a very powerful and reliable
architecture. I still remember using a windows environment on Unix when the
most graphical environment you could get from a PC running MS was Norton's
Midnigh Commander. The Apple was pretty good for its time, but it borrowed
most of its ideas from Unix and Xerox anyway. I still find X reliable and
still think that if you need to run a lab of thin client type machines, X
makes life much easier than the MS equivalent. At the same time, there have
been significant developments in user interfaces, widget libraries, etc.
The realisation that the whole planet doesn't use the same alphabet with
the same number of characters has exposed flaws in the early english
centric design of many programs and the underlying architecture it
uses. some software will catch up quickly, some has the 'green fields'
advantage of being new and not having legacy/backwards compatibility
concerns , while other packages will require considerable work and
resources to keep up with the evolving expectations of a wider user base.

Given the fact Emacs has now adopted the GTK+ widget set and given
the fact that the latest developments have been improving font support so
that Emacs supports antialiased, multibyte etc fonts, I think the quoted
comment just shows ignorance of what is going on. The printing integration
has never been an issue for me (though I would have to say I don't feel
CUPS has made it that much easier than 'lpr' and in fact hate the way it
tries to 'guess' what I want and usually gets it wrong. The comments also
totally overlook all the other spects of Emacs and fails to suggest
anything else that covers the same level of functionality we already have
an which does fit with his criteria (re fonts, desktop widgets, printing
and i18n).

I'm not at all interested in religious wars over editors, but would argue
emacs is no closer to going the way of the Dodo than VI (and all its
clones) and that while things like GNOME have certainly created desktop
environments closer to what Windows uses are familiar with, I've not seen
any GNOME based editor that has any more functionality than 'notepad'. When
there is an editor that has all the flashy desktop widgets, full
integration with font services, full integration with the printing
infrastructure etc and has the extensibility of emacs and support for all
the programming modes Emacs already has, I'll reconsider the argument, but
until then.....

Tim


-- 
tcross (at) rapttech dot com dot au