[V3dot10] Status?

[Ralph Johnson]

On 9/24/07, Andreas Raab <andreas.raab at gmx.de> wrote:
> There is an easy conceptual answer to the problem of fallback fonts:
> Don't use them. Rip 'em out and require anyone who needs to use multiple
> fonts together to implement a CompositeFont which holds a collection of
> fonts and dispatches among them by whatever strategy necessary. This
> will also simplify a bit of font-related code since various properties
> are computed dynamically just because of the existence of fallback fonts.

I agree.  The current design has recurisive classes but the base case
and the recursive case are mixed together.  It would be a lot better
if they were kept apart.  Composite would do that.

One drawback of Composite is that fallbackFonts are often created
lazily.  This would be harder with Composite.  It would require
looking ahead, which might be a good thing in the long run, but can be
hard in the short run.

Do you know the purpose of TTCFontSet and StrikeFontSet?  They are
also subclasses of AbstractFont, and are "composity", but I think they
are something else.  i think they are used to hold a set of related
fonts for bold, italics, underlined, etc.  So, why are they a subclass
of AbstractFont?

One thing that scares me about working on fonts is that if I do
anything wrong, I will kill the image.  It is pretty hard to test
changes.  I suppose I should make sure that the image only used
StrikeFonts and then give myself a safe place to work on TTCFonts.
Some of the tests switch the default font to TTCFont, which makes the
image look better, but is what makes the TTCFont bugs show up.  I
would get rid of them until I was done.  Any suggestions on how to
work on fonts without crashing the system and restarting every five
minutes?

I have lots of questions about TTCFont.  For example, if you ask a
TTCFont for its fallbackFont and it doesn't have one (i.e. it is nil)
then it will make one.  But in other places, it checks if fallbackFont
is nil.  So, is it possible for a TTCFont to not have a fallbackFont?
I suppose the anser is "yes", and the lazy creation of a fallbackFont
is just a mistake.  That should be done explicitly (by putting it in a
composite).

-Ralph