J.Pietschmann wrote: > Could you outline your API ideas on the Wiki?
Sure (give me a couple of days). Again, my point is not to push for a particular API or framework, but only to show that the control concepts (PDF encryption was the example given IIRC) can be added to the appropriate classes as needed. > > I think we are in agreement here, except that it looks like you > are thinking > > single Document, and I have added a mechanism (the Document > class) that will > > allow multiple Documents to be queued up and/or multithreaded. > > I think processing multiple documents is a layer above processing > a single source document. Right. So, if you are only processing one document in a Session, you don't need a Document class to keep track of and control the differences between documents. The information can be static-ish or singleton-ish. > > > I assume you are talking about trunk here. If so, my reasoning > for trying to > > get API resolved (or really Control, from my perspective) is so > that I can > > continue with getting the layout cleanly separated and pluggable, > > Not a chance, pal. The interface between layout and rendering is > much too complex, for example it includes the whole area tree mess. If we are talking about redesign/trunk here, that is precisely what we are trying to fix. Layout shouldn't need to know anything about rendering *directly*. The concept of RenderContext is built around knowing what the RenderType *capabilities* are, and managing layout accordingly, so there is indirect (abstract is probably the better term) knowledge. If you can convince me that it is not possible for layout and rendering to be refactored into distinct tasks or "services", then my interest in FOP diminishes to zero, and I'll stop making so much noise. I don't see why that should be true. > If it would be possible to plug the old layout into it, I would have > done this a long time ago (rather: backporting the renderers to the > maintenance branch). Don't forget that SVG plays a role too, and you > can't have this feature broken because it's almost the only advantage > we have over other FO processors now. I agree that "would be possible" isn't there in the current design, but again, I see no inherent reason why it can't be added. I would agree with you if layout could not be cleanly separated from both FOTree building and Rendering. I don't follow your point about SVG. From a big-picture, abstract standpoint, why do we need to think of SVG any differently than any other graphic type? We need to lay it out with the proper dimensions, and we need to render it properly. Can't those be distinct? Victor Mote --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
