Hi Keiron > If I understand it correctly we could have: > - multiple output targets for one rendering run > - targets with the same font metrics can layout to a common area tree > - targets with similar or substitute metrics could force layout to one area tree > - other targets can have different area trees from the same fo tree
Yep, though as Victor said, it remains to be seen if we will implement every feature from the beginning. It could be a lot of work. But I'd like to write down every idea so we have a reference for future work. > Would a rendering context make sense, which is created for each rendering > instance and used to determine what to do for layout, rendering. Yes, we need something like that. That's what's next on my todo list right after finishing the first version of the tutorial. But if one of you wants to start already please add a new Wiki page and add your thoughts. In short, that page should describe the following: - We've got various information holders/sources. We need to list them and place them in the architecture. Some information is hold over multiple rendering instances, some is only hold for one. - Putting FOUserAgent in the right context. It's something rather static though we will want the ability to have multiple instances per VM. This is configurable by config file and by subclassing. - the rendering context you just mentioned. Is this the right name for this? What information will it hold? etc. - We've got various caches. Where will we place each one? - How Avalon and the future API(s) will play into this. - add your ideas... Jeremias Maerki --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
