9:13 a.m.
Now that /usr/X11R6 is obsolete, and all X files are moving to
the /usr hierarchy, it is time to determine where certain things
should live, and comply with the FHS.
By default, unless overridden, the X11R7 font packages install
all of the fonts into /usr/lib/X11/fonts/*. Since fonts are
architecture independent data files however, it is my opinion
that they belong under /usr/share somewhere, as this is the FHS
mandated location for architecture independent data files.
We currently package the rest of the fonts our OS supplies
under %{_datadir}/fonts, which translates to /usr/share/fonts,
and is FHS compliant.
I'm currently of the opinion that we should install the X.Org
fonts into "/usr/share/fonts/X11", to have them installed into
an FHS compliant location, but also in their own namespace, thus
avoiding conflicts with other packages.
Another possibility, is to install them into /usr/share/X11/fonts,
which would also be FHS compliant, and put more strength on the
namespacing aspect, but also grouping the X font files along with
other architecture independent data included with X.
Since upstream X.Org currently does not honour the FHS very well,
it is our job to figure out where best the files belong in a
Linux FHS compliant world.
As such, I'm seeking opinions from other Red Hat developers, and
Fedora community developers. I'd really like to solve this, and
get the packages built ASAP, so please reply ASAP.
Also, feel free to forward this email to any other relevant
mailing lists if you think it deserves a wider audience, as I'm
only on this list.
Thanks in advance.
9:31 a.m.
On Sunday 06 November 2005 10:13, Mike A. Harris wrote:
I'm currently of the opinion that we should install the X.Org
fonts into "/usr/share/fonts/X11", to have them installed into
an FHS compliant location, but also in their own namespace, thus
avoiding conflicts with other packages.
Another possibility, is to install them into /usr/share/X11/fonts,
which would also be FHS compliant, and put more strength on the
namespacing aspect, but also grouping the X font files along with
other architecture independent data included with X.
Either will work and I can live with either. However, I lean toward having
ALL fonts under /usr/share/fonts and, thus, /usr/share/fonts/X11 is my
preference.
Now to just get every other font packager to put their fonts
under /usr/share/fonts ;)
--
Gene
9:49 a.m.
On Sun, 2005-11-06 at 10:31 -0500, Gene C. wrote:
On Sunday 06 November 2005 10:13, Mike A. Harris wrote:
> I'm currently of the opinion that we should install the X.Org
> fonts into "/usr/share/fonts/X11", to have them installed into
> an FHS compliant location, but also in their own namespace, thus
> avoiding conflicts with other packages.
>
> Another possibility, is to install them into /usr/share/X11/fonts,
> which would also be FHS compliant, and put more strength on the
> namespacing aspect, but also grouping the X font files along with
> other architecture independent data included with X.
Either will work and I can live with either. However, I lean toward having
ALL fonts under /usr/share/fonts and, thus, /usr/share/fonts/X11 is my
preference.
Agreed
Jeremy
10:05 a.m.
On Sun, 2005-11-06 at 10:49 -0500, Jeremy Katz wrote:
On Sun, 2005-11-06 at 10:31 -0500, Gene C. wrote:
> On Sunday 06 November 2005 10:13, Mike A. Harris wrote:
> > I'm currently of the opinion that we should install the X.Org
> > fonts into "/usr/share/fonts/X11", to have them installed into
> > an FHS compliant location, but also in their own namespace, thus
> > avoiding conflicts with other packages.
> >
> > Another possibility, is to install them into /usr/share/X11/fonts,
> > which would also be FHS compliant, and put more strength on the
> > namespacing aspect, but also grouping the X font files along with
> > other architecture independent data included with X.
>
> Either will work and I can live with either. However, I lean toward having
> ALL fonts under /usr/share/fonts and, thus, /usr/share/fonts/X11 is my
> preference.
Agreed
Agreed here as well, /usr/share/fonts/X11(or whatever) seems right place
to me.
--
Mike Chambers
Madisonville, KY
"It's better to hurt a little now, than to hurt a lot later!"
9:57 a.m.
On Sun, Nov 06, 2005 at 10:13:06AM -0500, Mike A. Harris wrote:
I'm currently of the opinion that we should install the X.Org
fonts into "/usr/share/fonts/X11", to have them installed into
an FHS compliant location, but also in their own namespace, thus
avoiding conflicts with other packages.
I think this is nicest. I like it more than the /usr/share/X11/fonts
alternative, because if one is looking for "what's part of X"? I think one
is more likely to ask rpm; if one is looking for "where are all the various
the font files", it's handy for them to be under one obvious place.
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
10:28 a.m.
Matthew Miller wrote:
On Sun, Nov 06, 2005 at 10:13:06AM -0500, Mike A. Harris wrote:
>I'm currently of the opinion that we should install the X.Org
>fonts into "/usr/share/fonts/X11", to have them installed into
>an FHS compliant location, but also in their own namespace, thus
>avoiding conflicts with other packages.
I think this is nicest. I like it more than the /usr/share/X11/fonts
alternative, because if one is looking for "what's part of X"? I think one
is more likely to ask rpm; if one is looking for "where are all the various
the font files", it's handy for them to be under one obvious place.
I agree, however there's an additional complication involved that
I hadn't thought of before. In Fedora Core 4 and earlier, the
fontconfig subsystem was only preconfigured to use the following
font directories:
<dir>/usr/share/fonts</dir>
<dir>/usr/X11R6/lib/X11/fonts/Type1</dir>
<dir>/usr/X11R6/lib/X11/fonts/OTF</dir>
<dir>~/.fonts</dir>
Fontconfig is recursive, meaning it will find all fonts in all
subdirectories of what is listed in fonts.conf.
I believe Owen, or whoever set up our default fonts.conf configuration,
intentionally selected only the above specific /usr/X11R6 font
directories, in order to pick up the scaleable Type1 and OTF fonts
that come with X, intentionally excluding all of the ugly bitmap
fonts and other weirdo fonts from being seen by fontconfig.
If we put all of the fonts into /usr/share/fonts, then fontconfig
will see all of them now, and this might cause you to get a different
font than you expected for a given name, whereas fontconfig would
not have seen them all before.
Another possible problem, is that I'm not sure if fontconfig/Xft
support all of the font types that are supported by the core fonts
system.
Note that these are currently only theoretical problems. I don't
know if there should be a real concern for these issues or not, as
I haven't tested anything yet.
If someone is interested in testing it however, and seeing the effects,
you can do:
1) Make a backup of /etc/fonts/fonts.conf somewhere safe.
2) Edit /etc/fonts/fonts.conf and remove the 2 existing entries:
<dir>/usr/X11R6/lib/X11/fonts/Type1</dir>
<dir>/usr/X11R6/lib/X11/fonts/OTF</dir>
3) Put in a new entry: <dir>/usr/X11R6/lib/X11/fonts</dir>
4) Run: fc-cache /usr/share/fonts
fc-cache /usr/X11R6/lib/X11/fonts
5) Completely reboot your whole system, to ensure that all apps are
restarted, etc. like they would be after a normal reboot.
6) Log into X, and experiment with various GNOME/KDE applications,
and see if any fonts have changed, or if anything is now unexpectedly
ugly by default.
After testing this, please post a reply to this email back to the
list.
If it turns out that having *all* of the X11 supplied fonts visible
to fontconfig is a bad idea, then we can explore other options. Please
feel free to make suggestions also.
Thanks to everyone who responded so quickly!
10:39 a.m.
Le dimanche 06 novembre 2005 à 11:28 -0500, Mike A. Harris a écrit :
Another possible problem, is that I'm not sure if fontconfig/Xft
support all of the font types that are supported by the core fonts
system.
Well, I for one would appreciate if all the weirdo fonts were put in
fonts-xorg-x11-legacy, and only a minimal set needed for server startup
was installed by default.
In fact if we could have a legacy-free default config it would be even
better. The "can not find fixed" problems have been plaguing users which
had absolutely no need for fixed in the first place for years.
Regards,
--
Nicolas Mailhot
10:54 a.m.
Nicolas Mailhot wrote:
Le dimanche 06 novembre 2005 à 11:28 -0500, Mike A. Harris a écrit :
>Another possible problem, is that I'm not sure if fontconfig/Xft
>support all of the font types that are supported by the core fonts
>system.
Well, I for one would appreciate if all the weirdo fonts were put in
fonts-xorg-x11-legacy, and only a minimal set needed for server startup
was installed by default.
That is an orthagonal issue, unrelated to this problem however.
It also creates a font installation granularity problem, where
if you want a single ISO8859-1 set installed, you get all of the
ISO8859-* fonts and anything else all in the one large package.
Many people want to install only the fonts that they will be using,
which is why our X font packaging puts each font type/encoding in
it's own subpackage. I don't see any reason to stop doing this, at
least until the core fonts system is capable of on-the-fly transcoding
from the UCS masters. At that point, we only need to ship the
UCS fonts, and that would reduce both the number of font packages,
and the number of disk wastage.
Again however, that is an orthagonal issue, of which I'm not too
concerned about right now.
In fact if we could have a legacy-free default config it would be
even
better. The "can not find fixed" problems have been plaguing users which
had absolutely no need for fixed in the first place for years.
It's not very "better" when someone goes to run an application and
their fonts are not installed, and they complain loudly on mailing
lists, and file oodles of bug reports with cursing and swearing in
them.
Don't get me wrong - I'm all in favour of deprecating old technology
and eventually removing it sometime down the road. But if that causes
too large of an increase in user/customer support problems, bug reports,
support escalations, and hate mail, then I'm strongly opposed to it,
if I'm on the receiving end of it all.
How many people would be upset if we compiled the fixed and cursor font
directly into the X server, so you never see "Can't find font fixed"
again, and we did not install xfs by default, and did not install any
core fonts by default, and also left libXt and libXaw out of a default
OS install? Yes, this means xterm wont work by default too.
I'm sure people would not be very impressed. Heck, I still receive
angry email for removing xbiff.
Anyhow, back to the original problem...
1:13 p.m.
On Sun, 2005-11-06 at 17:39 +0100, Nicolas Mailhot wrote:
Le dimanche 06 novembre 2005 à 11:28 -0500, Mike A. Harris a écrit :
> Another possible problem, is that I'm not sure if fontconfig/Xft
> support all of the font types that are supported by the core fonts
> system.
Well, I for one would appreciate if all the weirdo fonts were put in
fonts-xorg-x11-legacy, and only a minimal set needed for server startup
was installed by default.
In fact if we could have a legacy-free default config it would be even
better. The "can not find fixed" problems have been plaguing users which
had absolutely no need for fixed in the first place for years.
'fixed' has an important role as the font that is *guaranteed* to be
there on X no matter what. The user probably has no need for any
X core font other than 'fixed', but having 'fixed' there is an
important safety net.
The obvious solution would be to compile fixed into the X server in
some fashion. It's been discussed at various points, but I don't
think anyone has ever looked into actually doing it.
Dropping XFS at this point might be a good idea .... most 'cannot find
fixed' problems are really XFS problems, and if we aren't using core
fonts for anything, we don't need a font server. But dropping XFS
would mean changing the chkfontpath system that we use for maintaining
the core X font path, and, well, that's very fragile stuff and
intertwined with the %pre/%post in a lot of packages.
So, I think it is better to leave XFS there until nobody needs any
bitmap fonts other than fixed.
Regards,
Owen
1:27 p.m.
Le dimanche 06 novembre 2005 à 14:13 -0500, Owen Taylor a écrit :
On Sun, 2005-11-06 at 17:39 +0100, Nicolas Mailhot wrote:
> In fact if we could have a legacy-free default config it would
be even
> better. The "can not find fixed" problems have been plaguing users which
> had absolutely no need for fixed in the first place for years.
'fixed' has an important role as the font that is *guaranteed* to be
there on X no matter what. The user probably has no need for any
X core font other than 'fixed', but having 'fixed' there is an
important safety net.
But will this safety net be used say in a fontconfig-enabled app if
fontconfig finds no fonts in /usr/share ? (ie in 90% of FC apps)
If not I don't see what the point of forcing every single user to check
he got this failsafe installed. Especially considering the failsafe
system has historically been brittle and broken for more years than I
care to remember (a ttf dropped in /usr/share will "just work". Fixed
needs lots of fragile black magic to exist at all)
Regards,
--
Nicolas Mailhot
1:55 p.m.
On Sun, Nov 06, 2005 at 02:13:05PM -0500, Owen Taylor wrote:
fonts for anything, we don't need a font server. But dropping
XFS
would mean changing the chkfontpath system that we use for maintaining
the core X font path, and, well, that's very fragile stuff and
intertwined with the %pre/%post in a lot of packages.
In the long run, I think that's an argument *for* changing it. :)
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
2:04 p.m.
Le dimanche 06 novembre 2005 à 14:55 -0500, Matthew Miller a écrit :
On Sun, Nov 06, 2005 at 02:13:05PM -0500, Owen Taylor wrote:
> fonts for anything, we don't need a font server. But dropping XFS
> would mean changing the chkfontpath system that we use for maintaining
> the core X font path, and, well, that's very fragile stuff and
> intertwined with the %pre/%post in a lot of packages.
In the long run, I think that's an argument *for* changing it. :)
Make core font system
1. optional installed by default in FC n
2. optional not installed by default in FC n+1
3. pushed to Fedora Extras in FC n+2
3-release roadmap. Surely that's not too ambitious ? The few apps that
don't use fontconfig today won't in 10 years unless someone provides
more incentives to change.
And I wouldn't mind so much if fixed and friends were not en endless
source of X startup crashes
--
Nicolas Mailhot
10:48 a.m.
On Sunday, November 06, 2005 8:28 am, Mike A. Harris wrote:
I believe Owen, or whoever set up our default fonts.conf
configuration, intentionally selected only the above specific
/usr/X11R6 font directories, in order to pick up the scaleable Type1
and OTF fonts that come with X, intentionally excluding all of the
ugly bitmap fonts and other weirdo fonts from being seen by
fontconfig.
But don't you *want* to see all your fonts? I.e. if you chose to
install xorg-ugly-fonts, you don't want them mysteriously missing from
your font listings, do you?
I think as long as the ugly fonts are in separate packages, putting them
all in /usr/share/fonts will be ok based on the principle of least
surprise (though you bring up a good point that this is a change in
behavior wrt current FC).
Jesse
1:16 p.m.
On Sun, 2005-11-06 at 08:48 -0800, Jesse Barnes wrote:
On Sunday, November 06, 2005 8:28 am, Mike A. Harris wrote:
> I believe Owen, or whoever set up our default fonts.conf
> configuration, intentionally selected only the above specific
> /usr/X11R6 font directories, in order to pick up the scaleable Type1
> and OTF fonts that come with X, intentionally excluding all of the
> ugly bitmap fonts and other weirdo fonts from being seen by
> fontconfig.
But don't you *want* to see all your fonts? I.e. if you chose to
install xorg-ugly-fonts, you don't want them mysteriously missing from
your font listings, do you?
I think as long as the ugly fonts are in separate packages, putting them
all in /usr/share/fonts will be ok based on the principle of least
surprise (though you bring up a good point that this is a change in
behavior wrt current FC).
I think there is a general principle that installing extra packages
shouldn't break things ... other than cluttering up your menus or
lists of fonts.
But if the -adobe-*-*-*-*--*-*-*-*-*-*-*-* bitmaps get into your
font path, things break. Fontconfig (correctly) thinks that
these are official versions of Times Roman, Helvetica, etc, and
thus prefers them to the URW clones. It has no real way of knowing
that they are ugly bitmap official versions.
Regards,
Owen
7:47 p.m.
Jesse Barnes wrote:
On Sunday, November 06, 2005 8:28 am, Mike A. Harris wrote:
>I believe Owen, or whoever set up our default fonts.conf
>configuration, intentionally selected only the above specific
>/usr/X11R6 font directories, in order to pick up the scaleable Type1
>and OTF fonts that come with X, intentionally excluding all of the
>ugly bitmap fonts and other weirdo fonts from being seen by
>fontconfig.
But don't you *want* to see all your fonts? I.e. if you chose to
install xorg-ugly-fonts, you don't want them mysteriously missing from
your font listings, do you?
There are 2 individual font subsystems in X:
1) server side "core fonts" via xfs or the X server
2) client side fonts via fontconfig/Xft
These two font systems are independent of each other, and individually
configured.
The "core fonts" system is for legacy X applications, in particular
applications that use the Xt, Xaw, and Motif toolkits, as well as other
legacy toolkits.
The majority of the fonts supplied by the X Window system are hideous
bitmap fonts, of which many of these "legacy" applications rely on being
installed and available. Many legacy X applications hard code specific
fonts as well, and wont even start if the font is not available. It is
for this reason, which many of the fonts are still supplied - more or
less for legacy compatibility.
However, while many of these "hideous" fonts are required for legacy
compatibility purposes with the core fonts subsystem, they are not
required by the modern fontconfig/Xft subsystem which modern
applications and GUI toolkits use.
It is intentional, that the "ugly" X fonts supplied for legacy
compatibility are installed and only configured to be used in the
"core" fonts subsystem. They are intentionally excluded from being
visible from the fontconfig subsystem.
Users are of course free to edit /etc/fonts/local.conf and configure
fontconfig to use all of the ugly bitmap fonts supplied by X, however
I can assure everyone that the results are greatly undesireable.
You do have that option however, but it definitely wont be the
default in Fedora Core.
I think as long as the ugly fonts are in separate packages, putting
them
all in /usr/share/fonts will be ok based on the principle of least
surprise (though you bring up a good point that this is a change in
behavior wrt current FC).
Except that there are 2 font systems in the system used by X
applications, and there are fonts we only want visible to one
of those 2 systems. fontconfig sees all fonts under
/usr/share/fonts unless you reconfigure fontconfig to blacklist
unwanted fonts.
I believe it is safe to say that the majority of fonts supplied by
X, can be considered to be fonts intended for use by X core fonts
only, rather than for general purpose use that /usr/share/fonts
is intended for. In other words, they can be considered application
specific data IMHO.
The new xorg-x11-fonts package installs all of the fonts into
/usr/share/X11/fonts currently, however this location is not
finalized yet.
Also, I want to avoid xfs config file skew, as that causes a lot of
mayhem on upgrades. We need to rip out old paths that are no longer
used.
I'll be providing updates on the Xorg modularization status page
soon: http://mharris.ca/xorg-modular/xorg-modularization.html
10:35 p.m.
On Wednesday, November 09, 2005 5:47 pm, Mike A. Harris wrote:
I believe it is safe to say that the majority of fonts supplied by
X, can be considered to be fonts intended for use by X core fonts
only, rather than for general purpose use that /usr/share/fonts
is intended for. In other words, they can be considered application
specific data IMHO.
I hadn't thought about it in the context of the two different font
systems. Put that way, what you say above makes a lot of sense and I'm
inclined to agree.
Are there any legacy applications required for a proper X installation?
If not, then on most systems the xorg-x11-fonts package may not be
needed (as long as the X server itself supplies the infamous 'fixed'
font I guess).
The new xorg-x11-fonts package installs all of the fonts into
/usr/share/X11/fonts currently, however this location is not
finalized yet.
Also, I want to avoid xfs config file skew, as that causes a lot of
mayhem on upgrades. We need to rip out old paths that are no longer
used.
I'll be providing updates on the Xorg modularization status page
soon: http://mharris.ca/xorg-modular/xorg-modularization.html
Cool, thanks.
Jesse
4:25 a.m.
Are there any legacy applications required for a proper X
installation?
If not, then on most systems the xorg-x11-fonts package may not be
needed (as long as the X server itself supplies the infamous 'fixed'
font I guess).
Well, one glaring example is xscreensaver. Even though xscreensaver has
been a core part of Gnome for a while now, it uses its own internal
password dialog, apparently due to paranoia about security. This
internal GUI uses core fonts. jwz has some talk about using a toolkit
like GTK via a seperate process here:
http://www.jwz.org/xscreensaver/toolkits.html
The other option is to just patch xscreensaver's internal dialog to use
xft, which will at least get rid of the dependency on the core font
system.
There's also vncviewer, I can't figure out what toolkit its using if
any, but it uses core fonts for its GUI. I find it annoying that vino is
a part of Gnome, but there's no Gnome VNC viewer. vncviewer's UI is
terrible.
3:51 a.m.
Le mercredi 09 novembre 2005 à 20:47 -0500, Mike A. Harris a écrit :
The "core fonts" system is for legacy X applications, in
particular
applications that use the Xt, Xaw, and Motif toolkits, as well as other
legacy toolkits.
And commercial JVMs.
Making core font support optional would probably be enough for Sun to
get a clue and port Java to fontconfig.
Oh well the future is gcj anyway. As soon as it's stable enough for use,
_many_ people will discover the shortcuts Sun took in its X11 reference
implementation and wonder why they had to live with them so long.
Regards,
--
Nicolas Mailhot
11:49 p.m.
Nicolas Mailhot wrote:
Le mercredi 09 novembre 2005 à 20:47 -0500, Mike A. Harris a écrit :
>The "core fonts" system is for legacy X applications, in particular
>applications that use the Xt, Xaw, and Motif toolkits, as well as other
>legacy toolkits.
And commercial JVMs.
Making core font support optional would probably be enough for Sun to
get a clue and port Java to fontconfig.
Things of this nature take a lot of time to transition. While we
want that transition to happen, moving too fast can end up just
upsetting users and customers unreasonably, which would just make
Fedora and thus future RHEL releases less attractive to many
deployments.
Proper timing is key.
5:27 a.m.
Le vendredi 11 novembre 2005 à 00:49 -0500, Mike A. Harris a écrit :
Nicolas Mailhot wrote:
> Le mercredi 09 novembre 2005 à 20:47 -0500, Mike A. Harris a écrit :
>
>
>>The "core fonts" system is for legacy X applications, in particular
>>applications that use the Xt, Xaw, and Motif toolkits, as well as other
>>legacy toolkits.
>
>
> And commercial JVMs.
> Making core font support optional would probably be enough for Sun to
> get a clue and port Java to fontconfig.
Things of this nature take a lot of time to transition. While we
want that transition to happen, moving too fast can end up just
upsetting users and customers unreasonably, which would just make
Fedora and thus future RHEL releases less attractive to many
deployments.
Proper timing is key.
In this case there it's more vendor cluelessness than timing issues. I
doubt Sun will even look at fontconfig before lack of support breaks
jvms on some distros. And they're not alone. If you want the transition
to happen you have to break stuff in FC else some people won't ever look
at the problem and let you happily bear the burden of dual font system
till hell freezes over.
And note I didn't write "remove core font support" but "make it
optional" ie things will still work after installing the optional part.
Which will hopefully annoy enough people they start looking at
fontconfig support.
Regards,
--
Nicolas Mailhot
11:07 a.m.
On Sun, 2005-11-06 at 11:28 -0500, Mike A. Harris wrote:
I believe Owen, or whoever set up our default fonts.conf configuration,
intentionally selected only the above specific /usr/X11R6 font
directories, in order to pick up the scaleable Type1 and OTF fonts
that come with X, intentionally excluding all of the ugly bitmap
fonts and other weirdo fonts from being seen by fontconfig.
bitmap fonts can be turned off in new fontconfig
If we put all of the fonts into /usr/share/fonts, then fontconfig
will see all of them now, and this might cause you to get a different
font than you expected for a given name, whereas fontconfig would
not have seen them all before.
They can also be blacklisted in new fontconfig
11:37 a.m.
Michael A. Peters wrote:
On Sun, 2005-11-06 at 11:28 -0500, Mike A. Harris wrote:
>I believe Owen, or whoever set up our default fonts.conf configuration,
>intentionally selected only the above specific /usr/X11R6 font
>directories, in order to pick up the scaleable Type1 and OTF fonts
>that come with X, intentionally excluding all of the ugly bitmap
>fonts and other weirdo fonts from being seen by fontconfig.
bitmap fonts can be turned off in new fontconfig
Some bitmap fonts are desired however. The ability to turn them
off, would mean we either include them all by default, giving users
some problems (someone has already confirmed that their fonts changed
when enabling fontconfig across all X fonts), or disable them all
by default, meaning bitmap fonts aren't available for terminals,
and terminal-like programs.
Not an optimal solution IMHO.
>If we put all of the fonts into /usr/share/fonts, then fontconfig
>will see all of them now, and this might cause you to get a different
>font than you expected for a given name, whereas fontconfig would
>not have seen them all before.
They can also be blacklisted in new fontconfig
Blacklisted on a directory by directory basis, or file by file?
How do the blacklists get maintained as new font files/dirs get
added?
2:45 p.m.
On Sun, November 6, 2005 12:37 pm, Mike A. Harris wrote:
Some bitmap fonts are desired however. The ability to turn them
off, would mean we either include them all by default, giving users some
problems (someone has already confirmed that their fonts changed when
enabling fontconfig across all X fonts), or disable them all by default,
meaning bitmap fonts aren't available for terminals, and terminal-like
programs.
Not an optimal solution IMHO.
What about patching fontconfig to give it priorities?
So that you can tell it to scan TTF, OTF, Type1 and then bitmap?
Or whatever order you choose? Granted, I've no idea how complex
that might be, but that, with the ability to exclude, would be
the likeliest optimal solution to being able to package all the
bitmap fonts.
3:47 p.m.
On 11/06/2005 12:37:42 PM, Mike A. Harris wrote:
Michael A. Peters wrote:
>
> They can also be blacklisted in new fontconfig
Blacklisted on a directory by directory basis, or file by file?
How do the blacklists get maintained as new font files/dirs get
added?
Is there a blacklist.d/ ? On the other hand, if only the legacy bitmaps need
blacklisting, would the blacklist ever change?
Regards, Willem Riede.
4:27 p.m.
On Sun, 2005-11-06 at 21:47 +0000, Willem Riede wrote:
On 11/06/2005 12:37:42 PM, Mike A. Harris wrote:
> Michael A. Peters wrote:
>>
>> They can also be blacklisted in new fontconfig
>
> Blacklisted on a directory by directory basis, or file by file?
>
> How do the blacklists get maintained as new font files/dirs get
> added?
Is there a blacklist.d/ ? On the other hand, if only the legacy bitmaps need
blacklisting, would the blacklist ever change?
Doesn't MacOS and MacOS X have a nice config tool that lets users select
what fonts the system loads? Could we do something like this (with some
well pick default enable, disable options).
It would be even better if it was done in such a way that font's that
are called, but not loaded get loaded so that that user doesn't need to
worry about apps that call for fonts that they've disabled.
R.
--
"It's a fine line between denial and faith.
It's much better on my side"
2:07 p.m.
Michael A. Peters wrote:
On Sun, 2005-11-06 at 11:28 -0500, Mike A. Harris wrote:
>I believe Owen, or whoever set up our default fonts.conf configuration,
>intentionally selected only the above specific /usr/X11R6 font
>directories, in order to pick up the scaleable Type1 and OTF fonts
>that come with X, intentionally excluding all of the ugly bitmap
>fonts and other weirdo fonts from being seen by fontconfig.
bitmap fonts can be turned off in new fontconfig
How would this effect the cases like Chinese, Japanese or Korean where
bitmap fonts are substituted at small sizes in order to have readable
tiny text?
Warren Togami
wtogami(a)redhat.com
1:05 p.m.
On Sun, 2005-11-06 at 11:28 -0500, Mike A. Harris wrote:
Matthew Miller wrote:
> On Sun, Nov 06, 2005 at 10:13:06AM -0500, Mike A. Harris wrote:
>
>>I'm currently of the opinion that we should install the X.Org
>>fonts into "/usr/share/fonts/X11", to have them installed into
>>an FHS compliant location, but also in their own namespace, thus
>>avoiding conflicts with other packages.
>
>
> I think this is nicest. I like it more than the /usr/share/X11/fonts
> alternative, because if one is looking for "what's part of X"? I think
one
> is more likely to ask rpm; if one is looking for "where are all the various
> the font files", it's handy for them to be under one obvious place.
I agree, however there's an additional complication involved that
I hadn't thought of before. In Fedora Core 4 and earlier, the
fontconfig subsystem was only preconfigured to use the following
font directories:
<dir>/usr/share/fonts</dir>
<dir>/usr/X11R6/lib/X11/fonts/Type1</dir>
<dir>/usr/X11R6/lib/X11/fonts/OTF</dir>
<dir>~/.fonts</dir>
Fontconfig is recursive, meaning it will find all fonts in all
subdirectories of what is listed in fonts.conf.
I believe Owen, or whoever set up our default fonts.conf configuration,
intentionally selected only the above specific /usr/X11R6 font
directories, in order to pick up the scaleable Type1 and OTF fonts
that come with X, intentionally excluding all of the ugly bitmap
fonts and other weirdo fonts from being seen by fontconfig.
Yes, that's the case. It's pretty much a disaster if a web page
configured to have Helvetica specifically as a font comes up with
the bitmap Helvetica rather than Nimbus Sans.
Keith has been promoting an alternate solution to the bitmap font
problem - configuring fontconfig to exclude *all* bitmap fonts , but
that doesn't really work for us -- we *want* the bitmap fonts in
bitmap-fonts. (At least a couple of years ago, there was a
passionate attachment to MiscFixed.)
A different way of going about excluding fonts would be to use
the <rejectfont> mechanism ... see the description of rejectfont
in /usr/share/doc/fontconfig-<version>/fontconfig-user.{txt,html}
and /etc/fonts/conf.d/40-blacklist-fonts.conf for an example
that where we are using it to reject certain of the the Hershey
fonts which were causing FreeType indigestion.
If we put all of the fonts into /usr/share/fonts, then fontconfig
will see all of them now, and this might cause you to get a different
font than you expected for a given name, whereas fontconfig would
not have seen them all before.
Another possible problem, is that I'm not sure if fontconfig/Xft
support all of the font types that are supported by the core fonts
system.
This shouldn't be a problem ... if fontconfig doesn't understand
something it will ignore it.
Note that these are currently only theoretical problems. I
don't
know if there should be a real concern for these issues or not, as
I haven't tested anything yet.
We definitely can't drop the full set of X11 fonts right into the
default configuration. The problems will be far from theoretical.
But they should be fixable.
Regards,
Owen
10:08 a.m.
Le dimanche 06 novembre 2005 à 10:13 -0500, Mike A. Harris a écrit :
I'm currently of the opinion that we should install the X.Org
fonts into "/usr/share/fonts/X11", to have them installed into
an FHS compliant location, but also in their own namespace, thus
avoiding conflicts with other packages.
Actually, I'd rather you used xorg-x11, since I doubt every single X11
implementation uses the same font set and avoiding useless patch
conflicts is nice.
PS
is server startup still failing when it doesn't find "fixed" ? On a
modern fontconfig desktop fixed is not used anywhere
PPS
I don't think any of your modular packages obsoletes xorg-x11 or
xorg-x11-libs, which may cause yum update problems
Regards,
--
Nicolas Mailhot
6730
days inactive
6745
days old
27 comments
14 participants
participants (14)
-
Callum Lerwick -
Gene C. -
Jeremy Katz -
Jesse Barnes -
Matthew Miller -
Michael A. Peters -
Mike A. Harris -
Mike Chambers -
Nicolas Mailhot -
Owen Taylor -
Rodd Clarkson -
vallimar＠sexorcisto.net -
Warren Togami -
Willem Riede