Bernardo Innocenti wrote:
Mike A. Harris wrote:
It'd be an interesting test for someone to disable xfs, and
to configure the X server to have only the "misc" font dir
as a configured font path in xorg.conf, and then see what
all apps no longer work.
I've been running my X server with xfs disabled for over one
year, but I've added back core fonts in my xorg.conf.
This seems to be a good compromise that would keep all legacy
toolkits happy for a few more years.
If the core fonts are properly configured in the X server config,
then I'd more or less agree. To do that effectively though,
would require changing the way fonts are installed and configured,
or to simply require users to manually configure the fontpaths
they desire (which is a bit ugly IMHO).
IIRC, delegating font rendering to xfs was just a workaround
to avoid hanging X for too long while loading fonts with lots
of glyphs (e.g. kanji fonts).
That was more or less one of the primary reasons, however several
people for years now claim that it is no longer a real issue.
Today, this is largely useless because:
- Very few apps use the core fonts
I'm not so sure that is true. I'd like to see a definition of
"very few" really. Every app ever written for the X Window system
which has not been ported to Xft/fontconfig, or to GTK/Qt stack
that is fontconfig/Xft enabled uses core fonts still. Since I have
posted this thread, it has surfaced that emacs, nedit, mplayer all
use core fonts. I can't guess how many users use nedit, but emacs
and mplayer have a massive userbase.
There are likely to be a large number of applications out there which
are very highly popular still, which still rely on core fonts. So
ignoring core fonts, or making it a total 3rd class citizen that
causes user pain is IMHO not viable.
Any changes we make, must leave the common general case usage
scenario still a useable system IMHO, or we will receive nothing
but harsh words from the community, and perhaps even a wake of
users ditching our distribution for one that their apps work with
out of the box.
- most of them are not even localized or unable to use non-western fonts
- Today's CPUs are much faster
- Unless I've misunderstood something, X should now be able
to load and render single character glyphs at a time.
The reasons that xfs was decided upon a long time ago may or may
not be relevent today. The main reason xfs continues to be used
in Fedora/RHEL in 2006 is because of the "if it is not broken,
don't fix it" principle. The core fonts system "just works" with
our current xfs setup. Font rpms drop into place and configure
themselves to work with xfs simply, and users generally do not
need to do any hand editing of config files or other futzing
around.
Every time someone has previously proposed to get rid of xfs, it
has been suggested in a way that hinted that we can simply disable
xfs from being started by default, and core fonts magically continues
to work for everyone without any further engineering effort.
In reality, if we are to not use xfs by default, and still have core
fonts remain to be useable out of the box without user intervention,
we need to change every single font package which currently configures
itself to integrate into the core fonts system with chkfontpath.
chkfontpath in theory could be rewritten to configure the X server,
which would work for fresh OS installs, but would more or less
totally break on OS upgrades, or yum upgrades that migrate from one
OS release to the next.
If we are to migrate the OS from using xfs by default to using the
X server directly by default for core fonts, then we need to clearly
determine what level of compatibility we require, and determine
every single part of the OS which will need to be updated to work
with the new way of doing things properly. In the past, all of this
effort has been determined to be a lot of work to allocate resources
to, to remove a dependency on xfs, but to otherwise give no new
functionality. In other words, to spend some unknown amount of
manpower to engineer a solution that hopefully results in giving us
the same level of functionality for core font using apps as we have
right now already if we do nothing. ;o)
So, what I'm trying to determine right now is - if we do decide to
do this, what actual work needs to be done, so we can scope out how
much resources need to be committed to doing it, or alternatively
to find an alternative solution to the OLPC problem.
The one alternative that has come up, is to remove the xfs dep from
the X server packaging, and replace it with a virtual dep on the
required core fonts, then add the virtual provides to the xfs package,
and also to a new package that just provides fixed+cursor for OLPC.
Another alternative, is to build the fixed+cursor fonts into the
X server binary, and not have any external dependency, thereby making
any further core fonts optional, either provided by xfs, or by manual
configuration.
Feedback/thoughts/etc. appreciated! Thanks guys!
--
Mike A. Harris * Open Source Advocate * http://mharris.ca
Proud Canadian.
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
