Hi Keiron

Not enough to be of any help right now. But reading this the Flyweight
pattern from the Design Patterns book comes to my mind immediately. The
list of all font states is the consequence of this pattern which could
be very helpful for the renderers. The PS renderer still writes a list
of all registered (instead of used) fonts at the beginning so they are available
when necessary. You can't just register objects into the stream when
encountered like in PDF. Of course, the list grows over time during
layout while the renderer should already start writing out pages. But
that's another problem...

Sorry, if this a bit meager but on the other side.... In two weeks I'll
be starting my well-earned 7 weeks long holidays after really intensive
10 months. I'll be away during two weeks in August but I'll have 5 weeks
from which I'd like to spend at least a full week to help with the
redesign without having customers in my neck (read: I want to have some
fun). Let me know if there's a particular area I could help out. I was
thinking about the following areas: Avalon, Configuration, API,
renderers. But I'd be glad to help in other areas if I can.

While I'm at it, I'd like to apologize for my lack of participation
during the last weeks (especially with the API stuff). Too many things
buzzing around my head...

> Has anyone looked at the font state stuff.
> It appears we could make some changes to improve the way fonts are
> handled.
> - handle font information easily
> - handle font lists, resolving on a char basis
> - reduce number of FontState objects if information is the same (or
> similar?)
> - allow for serialization as part of area tree
> Do we need the FontInfo and FontMetric inside the FontState?
> Can we have a list of all font states so that it can be retrieved when
> needed for a particular layout of area?

Jeremias Märki

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to