[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Font substitution (Was: System fonts)

From: Alexander Malmberg
Subject: Font substitution (Was: System fonts)
Date: Sat, 28 Aug 2004 21:16:16 +0200
User-agent: Mozilla Thunderbird 0.5 (X11/20040306)

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]