[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Font substitution (Was: System fonts)
Font substitution (Was: System fonts)
Sat, 28 Aug 2004 21:16:16 +0200
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
(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
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
RE: System fonts, Vaisburd, Haim, 2004/08/24
Re: System fonts, Yen-Ju Chen, 2004/08/25
Re: System fonts, MJ Ray, 2004/08/25
System fonts, Dmitry S. Kulyabov, 2004/08/25
- Re: System fonts, (continued)
Re: System fonts, Yen-Ju Chen, 2004/08/26
- Font substitution (Was: System fonts),
Alexander Malmberg <=
- Message not available