Font substitution (Was: System fonts)

[Alexander Malmberg]

Since this seems to be a common request, I'll look at implementing this 
soon (I was going to say after the release, but with the delay, well, 
we'll see :).

The current basic plan is:

Do the font substitution in -fixFontAttributesInRange: (which gets run 
automagically on all text that is displayed).

Enabling/disabling will be controlled by a text storage flag (possibly 
tri-state for "substitute for all fonts"/"substitute for 'role' 
fonts"/"don't substitute). There won't be any explicit default for 
controlling the default, but it will be disabled in some efficient way 
if no fallback fonts are defined.

I haven't decided how to do the actual substitution. Could either change 
the actual font attribute, or set substitute fonts in a new attribute 
and have the layout manager use it. The advantage of the first 
alternative is that the substitution is visible to the user. The 
advantage of the second alternative is that the substitution is 
transparent to the user.

I'll probably implement both glyph-based and script-based substitution 
for testing before deciding which one to use.

Specifying fallback fonts will be done by extending the standard font 
defaults to handle arrays of names (in addition to the current names) 
and adding a new default, GSFallbackFonts (or something), a single font 
name or an array of names to be used as fallback fonts for all other fonts.

I'll send a mail to the list when there's something concrete in cvs to 
test. (And as always, if you want to test it early, #GNUstep is a good 
place to hang out in. :)


Some other semi-random notes:

* Font sets

Font sets, ie. a fake font made from several real fonts, could in theory 
be used to do glyph substitution at the backend level. fontconfig seems 
to supply this, so back-xlib _could_ use it; I don't know whether it 
actually works. The drawback is that, basically, you're lying to the 
upper layers about the fonts. As a consequence, font sets would really 
only work on-screen; it wouldn't be possible to print them (unless by 
some black magic, you configured your printer to have the same font 
set). The fact that the font set would need a postscript name is also a 
problem. In all, I'm skeptical about the usefulness of this when we can 
do it in -gui, but if someone wants to make it work in back-xlib, I 
wouldn't object.


* Performance
(for back-art, but most of it applies to back-xlib as well)

iconv isn't used at all for any layout, font, or rendering in the text 
system, so it isn't an issue. (-xlib: iirc, it does do some conversions 
at render time, which might be a problem; the solution would be to do 
the conversions at glyph generation time instead.)


Which characters you use in a text doesn't have any principle effect on 
the performance. However, there are a lot of caches involved, and that 
might have an effect. If you're only using latin1 text, you're probably 
just using 100 different characters, so you're pretty much guaranteed 
that any glyph metrics/bitmap/whatever you need will be in the cache. 
OTOH, if you're using chinese text, you might be using >1000 characters. 
This will either be slower (more cache misses and expensive 
recalculations), or use more memory (larger caches).

I don't know of any measurements of this, but I do know that getting 
glyph metrics used to be (before it was cached) a significant bottleneck 
in the layout process, so additional cache misses there will probably 
hurt a bit.


Whether font substitution will be a bottleneck depends on how quickly it 
can be done, and I don't know that yet. I don't expect any problems with 
text views; substitutions only happens on edits, and only for the edited 
range.

NSStringDrawing might be a problem. For those methods, attribute fixups 
and font substitution would get done from scratch every time a string is 
drawn. Benchmarks will let us know for sure once it's implemented.

((Slightly OT, and based on old profiling, but this probably still 
accurate.) Currently, short strings can be drawn using those methods in 
~35000-50000 clock cycles here. Of these, ~30000 are spent in the text 
storage methods that do attribute fixups and stuff like that, _even_if_ 
no attributes need to be fixed (and a large part of that is sending the 
two editing notifications, which is pointless for these methods).)


Ideas and suggestions about how to implement this are welcome, but they 
need to be in enough detail to be implementable. Knowing that another 
system does some form of substitution doesn't do me much good, but 
knowing how it does it would. :)

- Alexander Malmberg