I'm all for Defoma making a unified, system-wide approach to Font
management for Debian, but I'm more in favor of Freetype working with
fontconfig and making these fonts 'just work' ala NeXTSTEP/Openstep
[Display Postscript was a godsend working at NeXT] but I'd really be
interested in all these fonts working with LaTeX/XeTeX/TeX via the
projects currently being done at Google SoC on XeTeX and Unicode font
support directly into such a pain-in-the-ass but we love it's final
product font-handling that is TeX.
As I've stated, I'm unaware of the design.
I do know we have the backend of freetype and the xml based
fontconfig, then we have type1/opentype/truetype all managed by
freetype but not system managed I'm to ascertain by fontconfig for
GNUstep and therefore we use Defoma for this?
What is the order? Could you show a diagram ala the basefoundation
being freetype and above the various components in a pseudo-object
model?
- 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.
