It's the main reason I installed gnustep with the cairo backend so
that I have something to work with and not deal with this anymore.
My approach is a workaround, due to cairo, but this then addresses
whether art is broken by it's design limitations or just outstanding
issues that have grandfathered over and people put up with it for too
long.
- Marc
Marc J. Driftmeyer
[EMAIL PROTECTED]
http://www.reanimality.com
(509)435-5212
On Aug 15, 2008, at 1:32 PM, Yavor Doganov wrote:
Marc J. Driftmeyer wrote:
I've seen the same behaviour across GNUstep and it's very apparent
with such applications like GNUmail.app and Developer tools.
Well, the embarrassing thing is that I've seen it too, long time ago,
but nearly that time I decided to switch to the cairo backend on all
machines so I stopped seeing the nefarious effects, and forgot to
report it.
This may not be the best solution but I blew away gnustep-nfont.d/
recursively and most applications behaved so there is definitely
something incompatible with defoma and how GNUstep generates
compatible FontInfo.plists for it's applications to access.
If you delete recursively that directory, you should not be able to
start any GNUstep app with the art backend (on Debian), it would abort
with "No font found" or something like that. It is easy to recover it
with `defoma-reconfigure', `defoma-app update gnustep-nfont' or
`aptitude reinstall gnustep-back-common'.
I know nothing about the backend for GNUstep on how it leverages
freetype 2.3.7-1 but it's clear that GNUstep's cairo and art
backends aren't current with handling the freetype font system.
Cairo most definitely is, and so is art. It's just that on Debian,
art font handling goes through defoma (simply because we want to make
all system fonts available to GNUstep -- a valid goal), and we have
this odd `Files' section in many .plist font files. I'll have to take
a close look at Defoma to see why it happens.
BTW, the problem is the same with GNUstep on Etch -- e.g. DejaVu Sans
Mono can't be set as a font, but Charmap doesn't wait for a whole
eternity when you switch to Cheorokee. Apparently GNUstep Back
changed a bit so these library calls cause extensive CPU usage and the
issue the OP described. There were quite a few -back fixes and
improvements since then, and some of them might be regressions, or
real fixes that just expose an old problem.
