[Debian GNUstep maintainers] Bug#494933: Bug#494933: charmap.app: the range switching is terribly slow

[Marc J. Driftmeyer]

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
mjd at reanimality.com
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.
>
>
>