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

[Marc J. Driftmeyer]

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
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.
>
>
>