Glen Mazza wrote: > Are you sure? Please read > http://marc.theaimsgroup.com/?l=fop-dev&m=105455951226310&w=2 > (Peter, Jeremias' writing)--they appear to indicate > that the area tree is dependent upon the specific > renderer being used, because of the fonts.
Answer 1: I interpreted these comments to relate to the differences between PostScript/PDF and AWT/Print layout. Answer 2: If we do have layout/AreaTree/rendering differences between PostScript and PDF, then it seems (??!!) to me to be an anomaly that should be fixed. Off the top of my head, I can't think of a good reason for it. Same with differences between AWT and Print. Answer 3: If the differences do exist & need to exist, then the fix to the Section/Document, etc. approach is to remove the concept of RenderContext, and place all of that data/logic into RenderType instead. > one)--based again on the render_type. The business > logic for this would be in FOTreeBuilder. Sorry, man, but I cringe every time you say this. > Your idea is (non-graphical, I'm getting tired ;): > > <document class> > foTree = foTreeBuilder.createFOTree(); > areaTree = areaTree.createAreaTree(foTree); Close. The AreaTree creation would be done from the RenderContext. Document controls FOTree creation (if any), RenderContext controls AreaTree creation (if any), and RenderType controls rendering. > You are correct--this is *very* elegant--problem is, > from Keiron's writing, we just can't separate the > FOTree from the area tree because of an unacceptable > performance hit. > > See: > http://marc.theaimsgroup.com/?l=fop-dev&m=105270887501490&w=2 I don't think that is the link you wanted -- it doesn't seem to be relevant here. Nevertheless, Keiron and others are concerned about performance. That is why I factored out the idea of eager vs. patient processing. One of the benefits to getting all of the control logic up to these higher-level classes is that we can achieve Separation of Concerns (at least my conception of that term) without sacrificing the performance benefits of eager processing when it is appropriate. The lower-level workhorse classes don't have to know anything about what is going on "over the wall" or whether eager or patient processing is occurring. All they know is that when they are done with their task, they return control back to the higher-level objects. Right now, for example, when a page is completely laid out, the layout tells rendering to render it. What I am trying to achieve is that control would come back to RenderContext instead, which decides whether to fire up rendering logic to render (perhaps in a separate thread), or perhaps to fire up two rendering tasks (because there are two output media sharing the same AreaTree), or perhaps (down the road), it doesn't render yet at all because it knows it eventually wants to create an optimized PDF instead of the non-sequential page building we use now. >From that standpoint, I like the term "service" that Jeremias uses. FOTree building is a service that is consumed by Document. AreaTree building is a service that is consumed by RenderContext. Rendering is a service that is consumed by RenderType. I would love to have Keiron involved with this conversation. The last time we discussed this, I asked him whether he liked the idea of moving these control mechanisms into these higher-level objects, and he has so far not responded. > Here's food for thought--if we rename FOTreeBuilder to > XSLFOProcessor, perhaps you would have less concerns > about feeding it the render type. We can make this No. The only place where it even remotely makes sense (IMO) for FOTree building to know anything about the RenderType is in the StructureRenderers, and the correct way to factor the functionality there is that the parsing is tied to the rendering process (no FOTree built, no layout, go straight to rendering). So, to the extent that the pure SAX parsing is tied to FOTree building, it should be decoupled and made available to the StructureRenderers (I think this may already be in place). So, with StructureRenderers handled correctly, I don't see why FOTree building knows anything at all except to build an FOTree. > centrally-located class the "octopus" of the > application, rather than the left-side > Document/API/APPs class. I'm not terribly hung up on what the API looks like. However, once the control is properly factored out, it seems like the API naturally follows. After all, what we are really trying to accomplish here is to give the user / servlet programmer the maximum amount of flexibility (control!) that we can. Victor Mote --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
