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? Cheers, Jeremias Märki --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
