Re: font substitution

[Fred Kiefer]

Hi Rob,

there was a reason why Alexander was reluctant at that time to add this
patch to the main branch of GNUstep. This is a very expensive operation
that we are doing for every change of a string and it isn't even optimised.
I would kindly ask you to measure the time it take to perform text
operations on a reasonable large file with and without this patch in
place (Where all the characters are available in the assigned font).
Only when we are sure this change wont slow GNUstep down too much,
should we apply it. There are already some people complaining about the
slowness of GNUstep and I don't want to make things harder for them.

What would be even better is to come up with a highly optimized version
of this patch. For example cache for all substitution fonts the
supported character set and check that instead of creating each font in
turn for each character that gets checked. Also the substitutions fonts
should not come from a separate user setting instead we should take he
preferred fonts first and if that fails check all available fonts (This
can be really slow without a cache!). Another small optimisation could
be to remember the last match and to try that font first the next time
we are missing a character. And in the fixFontAttributeInRange: method
we could get the characters more efficiently and reuse the same font for
its effective range.
The method used here to check if a font is valid for a character
glyphForCharacter: is an extension that only exists for the art backend.
We would need to replace it with coveredCharacterSet and implement that
method for all backends.

I really would love to integrate this patch and as you can see I spend
some time thinking about it.

Cheers
Fred

foobix@comcast.net wrote:
> Quite some time ago Alexander Malmberg created a patch that gave
> GNUstep font substitution capabilities. It has worked quite well.
> Though, recent changes in GNUstep svn meant that the patch can no
> longer be applied. I've manually applied his patch to svn (from a few
> weeks ago), and created a new patch (attached). I was hoping this
> could be commited to svn, so as to not become out of date again.
>