RE: startup refactoring
Victor Mote wrote: > 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. OK, I have clarified some items and added some (informal) API information to the main API wiki, toward the bottom of the "Startup Concepts Proposal" section: http://nagoya.apache.org/wiki/apachewiki.cgi?FOPAvalonization Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: AW: AW: Structure renderers & area trees (Re: startup refactoring)
Jeremias Maerki wrote: Speaking of which, how does the file created by '-at' differ from the file generated by running xalan.bat? That's the Area Tree XML: The layouted pages serialized to a proprietary XML format. It's only interesting for debugging purposes (in layout engine development). And people who want to feed back results from the rendering process into a second XSLT pass... J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: AW: AW: Structure renderers & area trees (Re: startup refactoring)
On 23.06.2003 19:33:23 Clay Leeds wrote: > On 6/23/2003 10:19 AM, Jeremias Maerki wrote: > > Nice idea, but there's a problem. The xsl namespace gets filtered out by > > the XSLT engine, or IOW expanded to the FO attributes before they reach > > FOP. FOP never sees anything with the xsl: prefix. > > Does this mean that just about every fo:block in the intermediary FO > file (the one you can only see if you run xalan.bat instead) has a > cagillion font-weight="bold" and font-face="courier new, courier, > monospace"? Wow! Sounds inefficient, and tedious but I guess that's how > it goes... Yep. > Speaking of which, how does the file created by '-at' differ from the > file generated by running xalan.bat? That's the Area Tree XML: The layouted pages serialized to a proprietary XML format. It's only interesting for debugging purposes (in layout engine development). Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: AW: AW: Structure renderers & area trees (Re: startup refactoring)
On 6/23/2003 10:19 AM, Jeremias Maerki wrote: Nice idea, but there's a problem. The xsl namespace gets filtered out by the XSLT engine, or IOW expanded to the FO attributes before they reach FOP. FOP never sees anything with the xsl: prefix. Does this mean that just about every fo:block in the intermediary FO file (the one you can only see if you run xalan.bat instead) has a cagillion font-weight="bold" and font-face="courier new, courier, monospace"? Wow! Sounds inefficient, and tedious but I guess that's how it goes... Speaking of which, how does the file created by '-at' differ from the file generated by running xalan.bat? -- Clay Leeds - [EMAIL PROTECTED] Web Developer - Medata, Inc. - http://www.medata.com PGP Public Key: https://mail.medata.com/pgp/cleeds.asc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: AW: AW: Structure renderers & area trees (Re: startup refactoring)
Nice idea, but there's a problem. The xsl namespace gets filtered out by the XSLT engine, or IOW expanded to the FO attributes before they reach FOP. FOP never sees anything with the xsl: prefix. On 23.06.2003 18:51:45 Clay Leeds wrote: > Forgive my intrusion, and perhaps this is not related, or just using a > different namespace, but why not define a xsl:attribute-set for each > "style" and then use the xsl:use-attributes to help with the definition > of the RTF/MIF style? Consider this this example (the comments are meant > for people who want to modify 'my' template to change their output): > Is this related to the discussion? I see that I'm using xsl: namespaces, > but I'm curious to learn how this relates... Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: AW: AW: Structure renderers & area trees (Re: startup refactoring)
On 6/23/2003 3:08 AM, J.U. Anderegg wrote: Bertrand Delacretaz wrote: How do you plan to handle RTF styles? In jfor we defined an extension to XSL-FO (the "jfor-style" attribute) to control RTF styles. I think some form of extension is needed as (AFAIK) the concept of styles does not exist in XSL-FO, as it is meant for printed output. (1) This is not a FOP extension, but rather a fundamental change of the XSL-FO language, which does not know stlye sheets. Forgive my intrusion, and perhaps this is not related, or just using a different namespace, but why not define a xsl:attribute-set for each "style" and then use the xsl:use-attributes to help with the definition of the RTF/MIF style? Consider this this example (the comments are meant for people who want to modify 'my' template to change their output): #ff #00 courier new, courier, monospace 8pt Then couple this with these fo:page-sequence calls: Is this related to the discussion? I see that I'm using xsl: namespaces, but I'm curious to learn how this relates... -- Clay Leeds - [EMAIL PROTECTED] Web Developer - Medata, Inc. - http://www.medata.com PGP Public Key: https://mail.medata.com/pgp/cleeds.asc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: AW: AW: Structure renderers & area trees (Re: startup refactoring)
Le Lundi, 23 juin 2003, à 12:08 Europe/Zurich, J.U. Anderegg a écrit : Bertrand Delacretaz wrote: ...In jfor we defined an extension to XSL-FO (the "jfor-style" attribute) to control RTF styles (1) This is not a FOP extension, but rather a fundamental change of the XSL-FO language, which does not know stlye sheets. What I called "extension" applies to XSL-FO, or rather to the input documents handled by jfor, which use the "jfor-style" attribute in addition to standard XSL-FO. You're right that this is not a FOP extension. This can be implemented cleanly with namespaces, so as not to pollute the XSL-FO input, something like Meaning that the style names are "decorations" to the input document. ...(2) I wrote a few weeks ago this and it is still my idea, how FOP should store properties: "Apply the principles of relational databases to eliminate redundancies: set up tables of unique/used fonts, strokes, colors, ... and have the objects reference table entries Sounds reasonable, but I don't know enough about the current properties code to comment on this. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
AW: AW: Structure renderers & area trees (Re: startup refactoring)
> Bertrand Delacretaz wrote: > ... > > How do you plan to handle RTF styles? > > In jfor we defined an extension to XSL-FO (the "jfor-style" attribute) > to control RTF styles. > > I think some form of extension is needed as (AFAIK) the concept of > styles does not exist in XSL-FO, as it is meant for printed output. > (1) This is not a FOP extension, but rather a fundamental change of the XSL-FO language, which does not know stlye sheets. > Another way would be to recognize sets of attribute values in the input > XSL-FO and map them to RTF styles. > (2) I wrote a few weeks ago this and it is still my idea, how FOP should store properties: "Apply the principles of relational databases to eliminate redundancies: set up tables of unique/used fonts, strokes, colors, ... and have the objects reference table entries. This will cost table lookups, CPU. However, it will also ease state processing. The program does not have to keep track of inherited properties set 300 FO elements earlier. The nuisance is that style sheets have acceptable redundancy (see DocBook), XSLT replicates properties innumerable times and FOP has to recollect and normalize all this stuff." My opinion: (1) is off FOP territory (2) to be considered, if FOP is implemented on this way Hansuli Anderegg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: AW: Structure renderers & area trees (Re: startup refactoring)
Le Lundi, 23 juin 2003, à 10:35 Europe/Zurich, J.U. Anderegg a écrit : ... How do you plan to handle RTF styles? In jfor we defined an extension to XSL-FO (the "jfor-style" attribute) to control RTF styles. Another way would be to recognize sets of attribute values in the input XSL-FO and map them to RTF styles. I think some form of extension is needed as (AFAIK) the concept of styles does not exist in XSL-FO, as it is meant for printed output. If you import XML in the newest versions of FrameMaker for example, you have to define a kind of "style map" which recognizes specific constructions in the XML and assigns styles to them. This might also be an option, use a second input file that tells FOP which (MIF or RTF) styles to assign when certain patterns are recognized in the input. ...Is it difficult to transform tables and lists? Not too much, but when we developed jfor we targeted it at RTF 1.5 which as no support for nested tables, so we had to fake them using joined cells (as older versions of Word did). Other than that, the tables and lists structures of XSL-FO map nicely to RTF. Possible problems are relative dimensions, for example it might be hard in RTF to say that a table must take 60% of the page height. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
AW: Structure renderers & area trees (Re: startup refactoring)
> Bertrand Delacretaz wrote > The whole point of the StructureHandler interface is to be able to > reuse FOP's "frontend" for structure-based renderers. > The impact of StructureHandler on the "standard" FOP output formats > (PDF mostly) is minor, but it allows the FOP "pipeline" to branch > cleanly, after the parsing and attributes resolution, to generate > either structure-based or page-based formats. > How do you plan to handle RTF styles? Is it difficult to transform tables and lists? Hansuli Anderegg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Structure renderers & area trees (Re: startup refactoring)
Le Dimanche, 22 juin 2003, à 21:15 Europe/Zurich, Arnd Beißner a écrit : ...Before we're getting too philosophical, let me say that we're now talking two different issues: 1. Is it possible to develop a conforming XSL:FO implementation that produces RTF or MIF or similar ouput? Probably not, XSL-FO is clearly meant for page output and RTF and MIF (unless abused in strange ways) are document formats, not page formats. 2. Are there really two different groups of output formats and does it really make sense to support both in one tool (FOP) There are definitely two groups, and I agree with you that All of the stuff needed for FO->RTF or FO->MIF conversion is pretty straightforward stuff The whole point of the StructureHandler interface is to be able to reuse FOP's "frontend" for structure-based renderers. The impact of StructureHandler on the "standard" FOP output formats (PDF mostly) is minor, but it allows the FOP "pipeline" to branch cleanly, after the parsing and attributes resolution, to generate either structure-based or page-based formats. Besides sharing code, the advantage in RTF and similar output formats being developed as part of FOP is the community: one project with more audience instead of several, each with a smaller audience. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: startup refactoring
Glen Mazza wrote: > --- Victor Mote <[EMAIL PROTECTED]> wrote: > > (At the risk of getting esoteric, if the > > Document object knows that none of the output > > options requested support SVG, it > > could tell the FOTree builder to ignore that > > namespace and save the memory. > > That's one helluva smart document you're planning > there... ;) Just to clarify -- I don't intend to write such logic, or even suggest that it would be a good thing. The only point that I am trying to make is that if you get the control objects lined up right you can make the whole thing pretty sophisticated & flexible, and still maintain Separation of Concerns. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Structure renderers & area trees (Re: startup refactoring)
Arnd Beissner wrote: > determined a formatting-time if you can't hand over the Correction, this typo can be misleading: > determined at formatting-time if you can't hand over the -- Cappelino Informationstechnologie GmbH Arnd Beißner Bahnhofstr. 3, 71063 Sindelfingen, Germany Email: [EMAIL PROTECTED] Phone: +49-7031-463458 Fax: +49-7031-463460 Mobile: +49-173-3016917 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Structure renderers & area trees (Re: startup refactoring)
Glen Mazza wrote: > We don't do HTML at all (Xalan's department)-- HTML is > browser dependent. HTML is not an output format. I know, the purpose was to illustrate my point, since everyone is familiar with HTML, but perhaps not with MIF or RTF. If you think it makes sense for FOP to output RTF, then it also makes sense for FOP to support HTML (at least in combination with CSS2). > w/RTF, "as for reaching even basic conformance"--my > impression on XSL-FO was that we must render up to the > maximum capabilities of the output format. > > So where there is an FO object or property that RTF > simply can't support, this would *not* mean (1) we're > incompliant with the XSL-FO spec w.r.t. the RTF > rendering, or (2) that RTF cannot done via an XSL-FO > input. Well, formatting objects are mandatory for a specific conformance level regardless of the output medium (sometimes different for visual and aural output media of course). As for properties, the specification already defines behaviour if certain rendering properties can not be represented. This is true for color and fonts, for example. The specification, however, seems to always assume that you (the implementation) have precise control over the formatting and pagination process, which you don't have with RTF. Example: expressions including functions seem to be basic conformance level to me. RTF doesn't support expressions. How will you resolve an expression that can only be determined a formatting-time if you can't hand over the expression to RTF? You cannot anticipate the actual formatting an RTF renderer (like Word) will do, if only because a different hyphenation library is used. > I think the "binary" of PDF is also human-readable, > just like RTF is, albeit it's more complex and has > much more functionality. It appears that the main > difference between the two groups is back to some > needing page numbering and others not. With this I don't agree at all. First, PDF is only human-readable in a way that PostScript is, too - and only if you totally leave out encoded objects. You could even say that PDF is something like annotated and restricted PostScript. Nitpicking aside - this is basically true. Second, it's not really about page numbering. The difference is formatting. By formatting I mean deciding were lines and pages are broken and where glyphs and other graphical elements are put exactly. If you don't know where exactly a glyph will end up, it's not formatting. 8-) Extreme example: XSL:FO to formatted ASCII. There are lots of constraints that you now have, but the formatter will still know where each glyph will display. Before we're getting too philosophical, let me say that we're now talking two different issues: 1. Is it possible to develop a conforming XSL:FO implementation that produces RTF or MIF or similar ouput? 2. Are there really two different groups of output formats and does it really make sense to support both in one tool (FOP). My answers: 1. Probably no. Only if all XSL:FO specification constraints are either directly supported by the destination language (RTF, MIF, whatever) or can be transformed into supported destination language elements without anticipating concrete formatting steps (like line-breaking). Anyway, this probably cannot be definitely resolved without contacting the W3C. Also, it's a rather academical (or worse, legal) issue unless/until you want to claim conformance for these output types for FOP. 8-) 2. Yes, there are, and no, it doesn't really. That's a bit like taking a C compiler that produces machine code, and then add the capability to produce Java source code output to that C compiler. Yes, you can do it, but no, it doesn't make too much sense, since the only code you share is the parsing stuff and abstract syntax tree building. Of course, the few parts that *can* be shared *should* be shared. Maybe it's even worth to bundle both things into one "tool" or library - if only for the user's convenience. I just think it's absolutely not worth the bother to clutter major parts of FOP (old or new) with stuff needed by converter-type output renderers, when these don't even profit from these same major parts of FOP. All of the stuff needed for FO->RTF or FO->MIF conversion is pretty straightforward stuff. IMO not at all comparable with the complexities lurking in actually *formatting* according to the XSL:FO specification. Sermon ends. 8-) -- Cappelino Informationstechnologie GmbH Arnd Beißner - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Structure renderers & area trees (Re: startup refactoring)
--- Arnd Beißner <[EMAIL PROTECTED]> wrote: > Glen Mazza wrote: > > > So the XSL-FO spec--which FOP is trying to > implement > > for as many output types as possible--is not > relevant > > for those output types which don't need to know > glyph > > size? By putting it into a separate tool, that is > > what you may be implying. > > In a way, that's true. You need control over glyph > placement (and, of > course, lines, area, etc.) if you want to do a > conforming implementation. > I don't think you will be able to reach even basic > conformance with output > types HTML, RTF and MIF - We don't do HTML at all (Xalan's department)-- HTML is browser dependent. HTML is not an output format. I don't know MIF, so can't comment on it. w/RTF, "as for reaching even basic conformance"--my impression on XSL-FO was that we must render up to the maximum capabilities of the output format. So where there is an FO object or property that RTF simply can't support, this would *not* mean (1) we're incompliant with the XSL-FO spec w.r.t. the RTF rendering, or (2) that RTF cannot done via an XSL-FO input. > To summarize my view on this: FO->RTF, FO->MIF, > FO->HTML is a conversion > between similar high-level-languages where each > language element has a > similar corresponding language element in the > destination language. > FO->PDF, FO->PostScript, FO->PCL, FO->AWT are > formatting processes. I think the "binary" of PDF is also human-readable, just like RTF is, albeit it's more complex and has much more functionality. It appears that the main difference between the two groups is back to some needing page numbering and others not. > How about seeing things from this perspective: > transformation of XSL:FO to > RTF, MIF and HTML could be done using an XSLT > stylesheet (provided that > you create a trivial XML representation of RTF and > MIF first, of course). Certainly with HTML, it's done all the time; I suspect you're also correct with RTF. __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Structure renderers & area trees (Re: startup refactoring)
Glen Mazza wrote: > So the XSL-FO spec--which FOP is trying to implement > for as many output types as possible--is not relevant > for those output types which don't need to know glyph > size? By putting it into a separate tool, that is > what you may be implying. In a way, that's true. You need control over glyph placement (and, of course, lines, area, etc.) if you want to do a conforming implementation. I don't think you will be able to reach even basic conformance with output types HTML, RTF and MIF - expect perhaps in a very degenerate way (like creating an image for each page). With RTF (but only with a very recent version of it), you might stand a chance to reach at least roughly basic conformance. Conceptually, XSL:FO, RTF, MIF and HTML are the same thing (no nitpicking please 8-)). A renderer implementation of each of these standards produces glyphs, lines, and other low-level graphical objects that have definitive place on a medium. This is structurally some very different from converting between these language conversion. To summarize my view on this: FO->RTF, FO->MIF, FO->HTML is a conversion between similar high-level-languages where each language element has a similar corresponding language element in the destination language. FO->PDF, FO->PostScript, FO->PCL, FO->AWT are formatting processes. The formatting part is what makes up the primary goal and especially most of the complexity of FOP. How about seeing things from this perspective: transformation of XSL:FO to RTF, MIF and HTML could be done using an XSLT stylesheet (provided that you create a trivial XML representation of RTF and MIF first, of course). That stylesheet would be complex, of course, but on the 'possible side', because these transformations fundamentally are tree transformations of the same kinds of things. What can be shared between conversion and formatting beside the things I already mentioned? I think you can forget almost everything about fonts, the layouters, the area tree. How does this sound to you? -- Cappelino Informationstechnologie GmbH Arnd Beißner - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: startup refactoring
--- Victor Mote <[EMAIL PROTECTED]> wrote: > (At the risk of getting esoteric, if the > Document object knows that none of the output > options requested support SVG, it > could tell the FOTree builder to ignore that > namespace and save the memory. That's one helluva smart document you're planning there... ;) Glen __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Structure renderers & area trees (Re: startup refactoring)
--- Arnd Beißner <[EMAIL PROTECTED]> wrote: If you need a clear differentiation between the renderer types, you might take this one: do I need to know the size of a glyph in a certain font/size to produce the output? If yes, the appropriate renderer goes into FOP, if not, it goes into a separate tool. So the XSL-FO spec--which FOP is trying to implement for as many output types as possible--is not relevant for those output types which don't need to know glyph size? By putting it into a separate tool, that is what you may be implying. Glen __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: startup refactoring
Peter B. West wrote: > Victor Mote wrote: > > J.Pietschmann wrote > ... > > 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. > > Victor, > > Without presuming the result of this discussion, it wouldn't be the end > of the world if it were true. It just means that certain views of the > process are precluded. You are right of course in a general way. However, for my purposes, I don't think FOP will ever be a suitable solution without pluggable layout. The existing user base is servlet- and performance-oriented, and my application is much more beautiful-output-oriented, with almost no need for speed. I think FOP can be made to accommodate both, and variety on some other axes as well, through the pluggable layout or LayoutStrategy scheme. I don't have a clear idea whether everyone thinks this is the right way to go, but I *think* I am hearing that it is (at least in theory) feasible to do so. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: startup refactoring
J.Pietschmann wrote: > Victor Mote wrote: > > 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. > > Layout and rendering can be factored into different packages > of services, actually this is already done to a large extent. > However, the interface is quite complex, and I don't think you > can plug in the old layout engine without rewriting significant > parts of it into the framework provided by HEAD. Agreed. > > 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? > > Inlined SVG code is parsed by the FOTreeBuilder. In any case, > the FOTreeBuilder must have at least some knowledge about anything > wich can appear in instream-foreign-object. OK, now I follow. Yes, the difference between SVG & other graphics packages would be the namespace issue. The FOTree builder needs to know what to do with the namespace. So, for a renderer-agnostic FOTree builder to work properly, it should parse the SVG & create the necessary objects in the FOTree. The Renderer (this would be the workhorse object that actually renders, not the somewhat-related RenderType control object that controls) then should be responsible to either ignore it or place it into the output, depending on its capabilities. But the FOTree builder doesn't need to know or care. (At the risk of getting esoteric, if the Document object knows that none of the output options requested support SVG, it could tell the FOTree builder to ignore that namespace and save the memory. FOTree builder still doesn't need to know or care about why, it simply "serves" Document). Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: startup refactoring
Victor Mote wrote: 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. Layout and rendering can be factored into different packages of services, actually this is already done to a large extent. However, the interface is quite complex, and I don't think you can plug in the old layout engine without rewriting significant parts of it into the framework provided by HEAD. 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? Inlined SVG code is parsed by the FOTreeBuilder. In any case, the FOTreeBuilder must have at least some knowledge about anything wich can appear in instream-foreign-object. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Structure renderers & area trees (Re: startup refactoring)
Peter B. West wrote: > Bertrand is probably in the best position to comment wrt RTF. Is anyone > familiar with MIF. Does it simply define page structures and flows? I'm roughly familiar with MIF - did some rough HTML to MIF conversion years ago. Basically MIF is structured text that is annotated with stylenames, which needn't even by defined in the MIF (but can, if I remember correctly). As for the general discussion on renderer types: IMO, it's a mistake to mangle "renderers" that produce formatted page-level output like PDF or PostScript with "renderers" that produce flow output in other formatting languages, like HTML, RTF or MIF. The latter is rather a conversion step, and you would need not the area tree but rather the FO element tree to do a good conversion. Fundamentally, I think these two different kinds of "renderer tasks" just have two things in common: a parser and an FO element tree, and that's it. So my suggestion would be to implement only formatted output in FOP and refactor the other outputs into a separate tool. If you need a clear differentiation between the renderer types, you might take this one: do I need to know the size of a glyph in a certain font/size to produce the output? If yes, the appropriate renderer goes into FOP, if not, it goes into a separate tool. Just my 2 cents, of course. -- Cappelino Informationstechnologie GmbH Arnd Beißner - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Structure renderers & area trees (Re: startup refactoring)
Jeremias Maerki wrote: On 20.06.2003 21:23:50 Glen Mazza wrote: If it does, it determines *which* type of area tree to create (Structure or MIF or the other one)--based again on the render_type. The business logic for this would be in FOTreeBuilder. But no area tree is generated when a StructureHandler (RTF/MIF) is active. To take this off on a bit of a tangent, I have always been a little sceptical about the possiblility of realising the "structure renderers" without the area tree. It seems to me to depend on whether the renderer in question follows a page definitions/flows model. I don't know anything about the structure of either RTF or MIF, but, for example, if one of these formats defined page formats (size, orientation, margins) at the beginning of each section, but then had structures corresponding to the data on individual pages, then pagination, i.e. layout, would have to be performed before the structure could be rendered. Can percentages be resolved without at least some degree of area tree construction? Bertrand is probably in the best position to comment wrt RTF. Is anyone familiar with MIF. Does it simply define page structures and flows? Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: startup refactoring
Victor Mote wrote: J.Pietschmann wrote ... 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. Victor, Without presuming the result of this discussion, it wouldn't be the end of the world if it were true. It just means that certain views of the process are precluded. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: startup refactoring
--- Victor Mote <[EMAIL PROTECTED]> wrote: > > > 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. That was the link--Keiron's writing appeared to indicate that the area tree needs to be created/processed *while* the FO Tree is being built, and not *after* it is done. Glen __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: startup refactoring
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]
RE: startup refactoring
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 ;): > > > 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]
Re: startup refactoring
--- Jeremias Maerki <[EMAIL PROTECTED]> wrote: > > Even with AWT/Print an Area Tree is generated. > > > But no area tree is generated when a > StructureHandler (RTF/MIF) is > active. > Yes, I got confused between the two sets of "weird" render types: those that handle their processing with their own starters (which I would like to push past FOTreeBuilder/XSLFOProcessor, and have the latter class handle as well) and those that don't need an area tree because of no page numbering, etc. Glen __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: startup refactoring
On 20.06.2003 21:38:02 Glen Mazza wrote:
> This seems to be another layer of indirection--quite
> useful still--but might the area tree *still* be
> renderer-dependent? ("The involved renderers can be
> asked"--It still has to know which renderers to ask,
> right? It may very well get different answers and
> work differently per renderer then.) If the Area Tree
> wants to know if Tribune New Roman is supported and
> PDF renderer says yes while PS says no, the area tree
> generated would be different for both, I think.
Right in general. I think this cannot be as detailed as individual fonts.
It should be like that: Renderer, do you support font sources X and Y?
Font Source X could be a service providing PostScript Type1 fonts, Font
Source Y could be a service providing fonts available to AWT. The whole
thing will have to happen before processing starts because different
Area Trees have to be generated if the requested set of renderers don't
support the same font sources (AWT against PDF, for example). The
problem is, as we already gathered in the earlier discussion, that I
guess you wouldn't want to simply let FOP generate two different
(!!!pagination!!!) ATs. You will get two different documents. But the
main use case for multiple renderers is to have one doc for printing and
one for the archive. And in this aspect, different output is not
acceptable. Therefore and IMO, multiple output formats in the same
processor run is not worth the pain. But the above concept is still
worthwhile.
Jeremias Maerki
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: startup refactoring
On 20.06.2003 21:34:28 J.Pietschmann wrote: > Could you outline your API ideas on the Wiki? Yes, please. I'm also in the process of writing down my ideas. That way it will be much easier to relate everyone's ideas to each other. At the moment I wish we could all sit together and figure it out by talking together and painting on a whiteboard. The Wiki will have to suffice I guess. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: startup refactoring
Glen Mazza wrote: foTree = foTreeBuilder.createFOTree(); areaTree = areaTree.createAreaTree(foTree); Check old FOP versions, like 0.19 or so... 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. Memory problems, not performance in general. The area tree is usually *huge*. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: startup refactoring
--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> >
>
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.
>
> Today, that is so. My idea is to move the font
> registry out of the
> renderers in to a font subsystem with multiple font
> sources. The
> involved renderers can be asked what font sources
> they support and so
> the available set of fonts will be restricted.
This seems to be another layer of indirection--quite
useful still--but might the area tree *still* be
renderer-dependent? ("The involved renderers can be
asked"--It still has to know which renderers to ask,
right? It may very well get different answers and
work differently per renderer then.) If the Area Tree
wants to know if Tribune New Roman is supported and
PDF renderer says yes while PS says no, the area tree
generated would be different for both, I think.
Glen
__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: startup refactoring
Victor Mote wrote: I don't understand. The setOutputType() would be in the RenderType class, which is one of the four classes that Driver would be split into. So there might also be, for example, a setEncryptionKey() method to handle this. The whole point of creating the three extra classes is to make the granularity fine enough to properly control this kind of stuff. I'm sorry if I have missed your point. Could you outline your API ideas on the Wiki? 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. 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 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. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: startup refactoring
On 20.06.2003 21:23:50 Glen Mazza wrote: > (1) Doc/Dri/whatever feed the FOTreeBuilder the xslfo > and the render_type, calls Run() > > (2) Based on the render_type FOTreeBuilder either > creates an area tree of its choosing, or doesn't > (AWT/Print). Even with AWT/Print an Area Tree is generated. > If it does, it determines *which* type > of area tree to create (Structure or MIF or the other > one)--based again on the render_type. The business > logic for this would be in FOTreeBuilder. But no area tree is generated when a StructureHandler (RTF/MIF) is active. > Regardless of area tree decision, it is responsible > for generating the report via its Run() function. > I.e., the area tree may just be a local variable of > its run() rather than its current status as a member > variable. > > Your idea is (non-graphical, I'm getting tired ;): > > > foTree = foTreeBuilder.createFOTree(); > areaTree = areaTree.createAreaTree(foTree); > > 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. It doesn't need to be separated. But the building (!) of the FO tree is separated from other code like layout or RTF generation. > > See: > http://marc.theaimsgroup.com/?l=fop-dev&m=105270887501490&w=2 > > [EMAIL PROTECTED] FOTree needs to encapsulate the > AreaTree, I thought the next best solution would be to > divorce your document from knowledge of the AreaTree, > rather than have both classes point to it. > > 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 > centrally-located class the "octopus" of the > application, rather than the left-side > Document/API/APPs class. YOU GET IT! Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: startup refactoring
Previous email was sent before I was done , please ignore for this one: --- Victor Mote <[EMAIL PROTECTED]> wrote: > AreaTree > is not > renderer-specific, but RenderContext specific. So, > for example, the same > AreaTree can be used to generate PostScript and PDF > output. 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. > Also, while currently it is true that the AreaTree > creation is somewhat > bound to the FOTree creation, that is one of the > things that I think we are > trying to change (I am anyway). currently it's: FOP -> Driver ---> FOTreeBuilder | | | | | | | | | \/ | | AWT/Print\/ | Starter Structure Handler < As in (1) FOP class determines if the render_type requires an area tree, if so goes to App.Driver, else App.AWT/Print Starter. (2) Driver activates the FOTreeBuilder. (3) Based on the render_type, Driver determines the type of StructureHandler (AreaTree) that FOTreeBuilder should send SAXEvents to, and gives it to FOTreeBuilder. (4) FOTreeBuilder sends SAX events to the StructureHandler that was given to it by Driver. I wanted to move to: (1) Doc/Dri API/Apps > FOTreeBuilder --> its Area Tree (1) Doc/Dri/whatever feed the FOTreeBuilder the xslfo and the render_type, calls Run() (2) Based on the render_type FOTreeBuilder either creates an area tree of its choosing, or doesn't (AWT/Print). If it does, it determines *which* type of area tree to create (Structure or MIF or the other one)--based again on the render_type. The business logic for this would be in FOTreeBuilder. Regardless of area tree decision, it is responsible for generating the report via its Run() function. I.e., the area tree may just be a local variable of its run() rather than its current status as a member variable. Your idea is (non-graphical, I'm getting tired ;): foTree = foTreeBuilder.createFOTree(); areaTree = areaTree.createAreaTree(foTree); 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 [EMAIL PROTECTED] FOTree needs to encapsulate the AreaTree, I thought the next best solution would be to divorce your document from knowledge of the AreaTree, rather than have both classes point to it. 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 centrally-located class the "octopus" of the application, rather than the left-side Document/API/APPs class. > If we > return control of that up to these Control/API > classes, we get a clean > separation of these tasks, add the option for > patient processing as well, > and add the possibility of pluggable layout. > I agree--splitting the business logic between multiple classes tends to create spaghetti code. Glen __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: startup refactoring
On 20.06.2003 20:58:58 Glen Mazza wrote: > --- Victor Mote <[EMAIL PROTECTED]> wrote: > > AreaTree > > is not > > renderer-specific, but RenderContext specific. So, > > for example, the same > > AreaTree can be used to generate PostScript and PDF > > output. > > 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. Today, that is so. My idea is to move the font registry out of the renderers in to a font subsystem with multiple font sources. The involved renderers can be asked what font sources they support and so the available set of fonts will be restricted. We've talked about the difficulties of supporting multiple renderers in one processor run before (see archives). Making the font subsystem standalone would make it possible to use the same area tree for the PDF and PS renderers and also make the AT independant of the renderer (I think). > > > Also, while currently it is true that the AreaTree > > creation is somewhat > > bound to the FOTree creation, that is one of the > > things that I think we are > > trying to change (I am anyway). > > currently it's: > > FOP -> Driver ---> FOTreeBuilder > | | > | | > | | > \/ | > Structure Handler <--- I think now it's: Driver-->FOTreeBuilder-->FOTree-->StructureHandler >LayoutEngine-->AreaTree-->Renderer > As in > (1) FOP class determines if the render_type requires > an area tree. > (2) Driver activates the FOTreeBuilder. > (3) Based on the render_type, Driver determines the > type of StructureHandler (AreaTree) that FOTreeBuilder > should send SAXEvents to, and gives it to > FOTreeBuilder. > (4) FOTreeBuilder sends SAX events to the > StructureHandler that was given to it by Driver. It's not directly SAX events but something similar. > I wanted to move to: > > (1) > Doc/Dri > API/Apps > FOTreeBuilder --> its Area > Tree But then, where's the StructureHandler (output to MIF and RTF)? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: startup refactoring
On 18.06.2003 22:36:12 Glen Mazza wrote:
> > The FO
> > tree
> > builder is (to me) a service that simply accepts a
> > SAX stream and builds
> > the FO tree.
>
> IMHO FOTreeBuilder is an object (C++/Java), not a
> service (C).
I'm talking about Avalon-style services. These are components that
implement a certain work interface. In the background there's a main
implementation class (either alone or representing a whole subsystem).
The interface helps to decouple the whole system (FOP). Loose coupling
is the keyword here. The interface also makes it easy to switch
implementations (for example: font sources, layout engines, whatever).
FOTreeBuilder, in my view of things, will change to be an interface, not
a Java object. You'll then have an implementation of the FOTreeBuilder
(ex. DefaultFOTreeBuilder) which provides the service of building an FO
tree.
> > The layout engine, another (coarse
> > grained) service, will
> > then access the FO tree to do the layout. This is
> > all kept together by a
> > "supervising" class.
>
> If we were doing C programming
We don't.
>--my fear is that the
> supervising class is going to end up eating FOP's
> object-oriented design and splitting the business
> logic too much in multiple places (just like apps
> currently does). (I guess I'll just have to trust the
> team to be disciplined in this regard! ;)
>
> >
> > The FOTreeBuilder should remain an inner service to
> > FOP, not exposed in
> > the public API, if you ask me.
>
> OK, a *very* thin wrapper (for those not needing any
> of the threading/logging goodies in apps/api):
>
> public class Fop extends FOTreeBuilder { }
>
> user's embedded code:
> Fop.setXSLFOStream(blah);
> Fop.setRenderType(RENDER_PS);
> myDoc = Fop.Run();
Please not. This encourages tight coupling between the main classes of
FOP IMHO. Avalon encourages the assembly of a system (several
services/subsystems bound together to build a bigger system, association
instead of subclassing). The subsystems get separated by well-designed
interfaces that encourage SoC (separation of concerns). That's why I'd
like to see FOTreeBuilder as a service:
FOTreeBuilder could look like this:
public interface FOTreeBuilder {
void setStructureHandler(StructureHandler handler);
ContentHandler getContentHandler();
FONode getRootNode();
boolean isEmpty();
void reset();
}
or
public interface FOTreeBuilder {
/** Build an FO tree and store it in the process controller class.*/
ContentHandler buildFOTree(ProcessorRun/Document/, StructureHandler
handler);
}
That's all it does. Already today, it's quite a light-weight thing. It's
Victor's new classes (Document, for example) that will keep the whole
thing together, in as little number of places as possible. This improves
decoupling and centralizes control which in the end should make the
whole thing easier to understand.
I really don't know if this concrete example will work out exactly like this.
I didn't even investigate how this will fit with Peter's work. I'm just
getting the impression that you're going into a problematic direction by
off-loading too much on something like the TreeBuilder.
Jeremias Maerki
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: startup refactoring
--- Victor Mote <[EMAIL PROTECTED]> wrote: > AreaTree > is not > renderer-specific, but RenderContext specific. So, > for example, the same > AreaTree can be used to generate PostScript and PDF > output. 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. > Also, while currently it is true that the AreaTree > creation is somewhat > bound to the FOTree creation, that is one of the > things that I think we are > trying to change (I am anyway). currently it's: FOP -> Driver ---> FOTreeBuilder | | | | | | \/ | Structure Handler <--- As in (1) FOP class determines if the render_type requires an area tree. (2) Driver activates the FOTreeBuilder. (3) Based on the render_type, Driver determines the type of StructureHandler (AreaTree) that FOTreeBuilder should send SAXEvents to, and gives it to FOTreeBuilder. (4) FOTreeBuilder sends SAX events to the StructureHandler that was given to it by Driver. I wanted to move to: (1) Doc/Dri API/Apps > FOTreeBuilder --> its Area Tree > The only reason that > I know of for the > processing to be the way it is now is to facilitate > eager processing. > If we > return control of that up to these Control/API > classes, we get a clean > separation of these tasks, add the option for > patient processing as well, > and add the possibility of pluggable layout. > > Victor Mote > > > - > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, email: > [EMAIL PROTECTED] > __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: startup refactoring
Glen Mazza wrote: > Given that our Area tree is renderer-specific, and > since the area tree creation is tightly bound to fo > tree creation--I think any internal implementation we > would have of multiple rendering types would just > involve running FOP once for each rendering type. If > so, perhaps this is best left with Cocoon. I saw your later posting amending the conclusion, but I want to make sure that the underlying logic is clear as well. AreaTree is not renderer-specific, but RenderContext specific. So, for example, the same AreaTree can be used to generate PostScript and PDF output. PostScript and PDF are part of the same RenderContext, whereas AWT would use a different one. (The user doesn't really have to know anything about RenderContexts because the RenderTypes can be hard-wired to them). Also, while currently it is true that the AreaTree creation is somewhat bound to the FOTree creation, that is one of the things that I think we are trying to change (I am anyway). The only reason that I know of for the processing to be the way it is now is to facilitate eager processing. If we return control of that up to these Control/API classes, we get a clean separation of these tasks, add the option for patient processing as well, and add the possibility of pluggable layout. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: startup refactoring
J.Pietschmann wrote: > Victor Mote wrote: > > In my vision of the API, the > > servlet programmer would not need useThisRenderer(), but would need > > something like setOutputType(OUTPUT_PDF), which would > ultimately cause the > > correct renderer to be selected. > > This has already been discussed up and down. There is still the > problem that renderers may need a lot of renderer specific > confiuguration data. Take for example PDF encryption. I don't > think it is a good idea to always pass this in some generic > way through the Driver (or whatever the replacement) to the > renderer. I don't understand. The setOutputType() would be in the RenderType class, which is one of the four classes that Driver would be split into. So there might also be, for example, a setEncryptionKey() method to handle this. The whole point of creating the three extra classes is to make the granularity fine enough to properly control this kind of stuff. I'm sorry if I have missed your point. > The other problem is the output. There are renderers writing to > a byte stream, there is the AWT and the print renderer which don't > write to a stream like object at all, there may be renderers like > an SVG renderer which write a SAX event stream. Again, I don't > think the output should always be passed through the driver. > It seems quite natural to solve these problems by using separate > renderer objects >processor = new FOProcessor() >// configure processor >renderer = new PDFRenderer(output); >// configure renderer >processor.setRenderer(renderer); > If there is no complicated configuration (use all defaults) > you can still write with another constructor >processor = new FOProcessor(); >processor.format(input,new PDFRenderer(output)); > which should be easy enough to servlet programmers. 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. > Note that TrAX uses a similar pattern, with Source and Result > abstracting a variety of input and output mechanisms to the > XSLT processor. > > [big snip] > Discussing the API may be fun, but IMO fixing bugs like the > broken text justification should get some attention too. The > best API is useless if the code inside doesn't work. 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, which I view as being the critical path toward project sanity. I have been trying for a year now to work on fonts, and I can't get there from here. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: startup refactoring
Errr...this came across as harsher-sounding than I would have liked. If the API has some convenient ways for the user to specify multiple output types for a single xsl-fo stream, that should be fine. Glen --- Glen Mazza <[EMAIL PROTECTED]> wrote: > > > [Responding to Jeremias here] Or, better yet IMO, > into > a RenderType > object > that is a child or grandchild of the Document, so > that > there can be > multiple > RenderTypes for the same Document. > > > > I can understand enhancements for logging and > threading, but multiple RenderTypes for the same > Document appears to be Cocoon's department, not > ours. > > > We're at a level below that, very similar to Xalan: > > Xalan input: xml document, xslt stylesheet > Xalan output: document > > FOP input: xml (xsl-fo namespace) document, render > type > FOP output: document > > Given that our Area tree is renderer-specific, and > since the area tree creation is tightly bound to fo > tree creation--I think any internal implementation > we > would have of multiple rendering types would just > involve running FOP once for each rendering type. > If > so, perhaps this is best left with Cocoon. > > Glen > > > > - > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, email: > [EMAIL PROTECTED] > __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: startup refactoring
[Responding to Jeremias here] Or, better yet IMO, into a RenderType object that is a child or grandchild of the Document, so that there can be multiple RenderTypes for the same Document. I can understand enhancements for logging and threading, but multiple RenderTypes for the same Document appears to be Cocoon's department, not ours. We're at a level below that, very similar to Xalan: Xalan input: xml document, xslt stylesheet Xalan output: document FOP input: xml (xsl-fo namespace) document, render type FOP output: document Given that our Area tree is renderer-specific, and since the area tree creation is tightly bound to fo tree creation--I think any internal implementation we would have of multiple rendering types would just involve running FOP once for each rendering type. If so, perhaps this is best left with Cocoon. Glen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: startup refactoring
Victor Mote wrote: In my vision of the API, the servlet programmer would not need useThisRenderer(), but would need something like setOutputType(OUTPUT_PDF), which would ultimately cause the correct renderer to be selected. This has already been discussed up and down. There is still the problem that renderers may need a lot of renderer specific confiuguration data. Take for example PDF encryption. I don't think it is a good idea to always pass this in some generic way through the Driver (or whatever the replacement) to the renderer. The other problem is the output. There are renderers writing to a byte stream, there is the AWT and the print renderer which don't write to a stream like object at all, there may be renderers like an SVG renderer which write a SAX event stream. Again, I don't think the output should always be passed through the driver. It seems quite natural to solve these problems by using separate renderer objects processor = new FOProcessor() // configure processor renderer = new PDFRenderer(output); // configure renderer processor.setRenderer(renderer); If there is no complicated configuration (use all defaults) you can still write with another constructor processor = new FOProcessor(); processor.format(input,new PDFRenderer(output)); which should be easy enough to servlet programmers. Note that TrAX uses a similar pattern, with Source and Result abstracting a variety of input and output mechanisms to the XSLT processor. [big snip] Discussing the API may be fun, but IMO fixing bugs like the broken text justification should get some attention too. The best API is useless if the code inside doesn't work. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: startup refactoring
Glen Mazza wrote: > > Well, the public API has to have > > some way to control > > the whole show. > > You don't mean that literally--e.g.., a servlet > programmer does not need useThisRenderer() and > attachAreaTree() functions in a public API. (i.e., > the public (embedded) API would be a strict subset of > the functions available to the supervising octopus > running the show) I am not sure what Jeremias meant, but yes, the API needs to at least indirectly control all of the major decisions. In my vision of the API, the servlet programmer would not need useThisRenderer(), but would need something like setOutputType(OUTPUT_PDF), which would ultimately cause the correct renderer to be selected. More likely, it would be set in a constructor. Here is some simplified sample startup code: session = new Session; document = session.addDocument(inputFile); document.addRenderType(RENDER_PDF, LAYOUT_SIMPLE, outputFile1); document.addRenderType(RENDER_POSTSCRIPT, LAYOUT_SIMPLE, outputFile2); document.addRenderType(RENDER_PDF, LAYOUT_CLASSIC, outputFile3); document.addRenderType(RENDER_PRINT); document.process() -OR- session.process() // if you want session to manage a queue of documents >From a big-picture control standpoint: Document = FOTree RenderContext = AreaTree RenderType = Renderer The document.addRenderType() also builds any RenderContext objects that are needed, three in this example (the first two can share the same AreaTree, each of the others requires a different one). When document.process() is run, it looks at the RenderContext objects to determine whether an FO Tree needs to be built In this case it does (and yes, it should be in a different package). It can then loop through the RenderContext objects to see what if any layout work needs to be done, and build an Area Tree based on the output type and the selected LayoutStrategy. Each RenderContext object will then loop through the RenderTypes which are attached to it to fire up Renderers. So in the example above, the same AreaTree will be used to spit out the first two RenderTypes before trying to build the AreaTree needed for the "CLASSIC" layout. Of course, there are a number of configuration options available as well, all of which can be attached to the appopriate object by a servlet programmer. The actual using of those options is in other objects (and indeed, should be in other packages), but the /control/ mechanism can live in these four classes. (I have left eager/patient processing out of this example, but control should be returned to the Document object at the end of each PageSequence to see if eager processing needs to fire off some layout and rendering work before continuing with parsing. I am not entirely sure whether eager/patient processing is totally a function of the LayoutStrategy, or whether some LayoutStrategies can tolerate either, which would make it need to be configurable). > > This will automatically lead to a > > little octopus if the > > code is in ...fop or ...fop.api. But no problem with > > another package. > > > > For my discussion, apps=api (they're both supervising > octopi). (Although I'm sure your package would be > orders-of-magnitude cleaner and simpler!) > > > > FOP is more a pipeline to me: > > > > > > APPs package (CLI, TRAX/XSLTInputHandler, > > Avalonized > > > API, Victor's ideas) --> > > FOTreeBuilder/Layout/Area > > > Tree creation --> Rendering. > > > > Uh, thanks for that one. It's a very nice show why > > the current apps > > package is a mess. > > I agree with you that the apps package is hideous--but > a pipeline may cleanup nearly all of it, providing it > enforces the rules I mentioned earlier: > > a.) The only access between apps/api and the rest of > the packages is via FOTreeBuilder and its "three" > functions. > b.) FOP is designed such that FOTreeBuilder *can* be > directly instantiated via a servlet (even if we don't > allow it). > c.) Once so instantiated, no code within apps/api > packages can be referenced. > > Via these rules, look at what gets removed from apps: > (a) structure and layout handler are gone (those are > past the FOTreeBuilder) > (b) AWTStarter and PrintStarter are gone (those > processing decisions are either handled by > FOTreeBuilder or something that it delegates to.) > (c) App class has *no* knowledge of renderers, element > mappings, area trees, structure handlers. > (d) Business logic is kept with each object, and not > shared in multiple places. > > > > IMO FOTreeBuilder should just expose three > > functions > > > (perhaps another one for logging): > > > > It's best to talk about > > lifestyle primarily and > > leave the lifecycle (instantiation, logging, > > configuration, > > initialization) to a different discussion. Helps > > keeping the focus, I > > believe. > > Excellent! We can leave that distraction out of the > discussion. (Although they, in additi
Re: startup refactoring
--- Jeremias Maerki <[EMAIL PROTECTED]> wrote: > > On 17.06.2003 21:28:29 Glen Mazza wrote: > > Instinctively, I wouldn't trust any code in the > > package root of org.apache.fop -- we wouldn't have > a > > very modularized design that way (knowing FOP's > > current coding style, the main FOP API would then > be > > accessing objects all through the packages, > > Well, the public API has to have > some way to control > the whole show. You don't mean that literally--e.g.., a servlet programmer does not need useThisRenderer() and attachAreaTree() functions in a public API. (i.e., the public (embedded) API would be a strict subset of the functions available to the supervising octopus running the show) > This will automatically lead to a > little octopus if the > code is in ...fop or ...fop.api. But no problem with > another package. > For my discussion, apps=api (they're both supervising octopi). (Although I'm sure your package would be orders-of-magnitude cleaner and simpler!) > > FOP is more a pipeline to me: > > > > APPs package (CLI, TRAX/XSLTInputHandler, > Avalonized > > API, Victor's ideas) --> > FOTreeBuilder/Layout/Area > > Tree creation --> Rendering. > > Uh, thanks for that one. It's a very nice show why > the current apps > package is a mess. I agree with you that the apps package is hideous--but a pipeline may cleanup nearly all of it, providing it enforces the rules I mentioned earlier: a.) The only access between apps/api and the rest of the packages is via FOTreeBuilder and its "three" functions. b.) FOP is designed such that FOTreeBuilder *can* be directly instantiated via a servlet (even if we don't allow it). c.) Once so instantiated, no code within apps/api packages can be referenced. Via these rules, look at what gets removed from apps: (a) structure and layout handler are gone (those are past the FOTreeBuilder) (b) AWTStarter and PrintStarter are gone (those processing decisions are either handled by FOTreeBuilder or something that it delegates to.) (c) App class has *no* knowledge of renderers, element mappings, area trees, structure handlers. (d) Business logic is kept with each object, and not shared in multiple places. > > IMO FOTreeBuilder should just expose three > functions > > (perhaps another one for logging): > > It's best to talk about > lifestyle primarily and > leave the lifecycle (instantiation, logging, > configuration, > initialization) to a different discussion. Helps > keeping the focus, I > believe. Excellent! We can leave that distraction out of the discussion. (Although they, in addition to threading issues, *do* appear to strengthen your argument on the need for a supervising class.) > > 1.) SetXSLFOStream() (file or stream) > > 2.) SetRenderType() (those constants currently in > > Driver or CommandLineStarter) > > 3.) Run(). (returns a stream or file) > > This mixes concerns. A render type does not belong > in a class called > FOTreeBuilder. I think it does, because it needs to know whether or not to generate an Area Tree, *which type* of structure handler, etc., also, since the Area Tree needs to know the render type, FOTreeBuilder will need to pass that information on to it via the pipeline. (Peter had said and you confirmed that the Area Tree still needs to know the rendering type for font sizes, etc.) Furthermore a different implementation of FOTreeBuilder may make different Area Tree decisions based on its render_type. > It should have nothing to > do with the > rendering aspect, especially since FO tree building > is independant of > the output format (wrt Renderers). Indeed, nothing to do with *rendering* but it does need to know the render_type as mentioned above. APPS/API knows nothing but FOTreeBuilder, which knows nothing but AreaTree, which knows nothing but the Renderers. So I also agree with you that FOTreeBuilder doesn't need to know about the Renderers. (but it could be so redesigned in the future, depending on the pluggable implementation of FOTreeBuilder, and this design more easily allows for that type of change.) > The render type > is better placed in a > class such as a > RenderingRun/Document/. Sure, providing they pass that information on to FOTreeBuilder. ;) > The FO > tree > builder is (to me) a service that simply accepts a > SAX stream and builds > the FO tree. IMHO FOTreeBuilder is an object (C++/Java), not a service (C). > The layout engine, another (coarse > grained) service, will > then access the FO tree to do the layout. This is > all kept together by a > "supervising" class. If we were doing C programming--my fear is that the supervising class is going to end up eating FOP's object-oriented design and splitting the business logic too much in multiple places (just like apps currently does). (I guess I'll just have to trust the team to be disciplined in this regard! ;) > > The FOTreeBuilder should remain an inner service to > FOP, not exposed in > the public API, if you ask me. OK,
Re: startup refactoring
On 17.06.2003 21:28:29 Glen Mazza wrote: > Instinctively, I wouldn't trust any code in the > package root of org.apache.fop -- we wouldn't have a > very modularized design that way (knowing FOP's > current coding style, the main FOP API would then be > accessing objects all through the packages, > octopus-like, splitting of the business logic with the > actual objects doing the work, inextricable from the > XSL FO process.) Not necessarily. Well, the public API has to have some way to control the whole show. This will automatically lead to a little octopus if the code is in ...fop or ...fop.api. But no problem with another package. > FOP is more a pipeline to me: > > APPs package (CLI, TRAX/XSLTInputHandler, Avalonized > API, Victor's ideas) --> FOTreeBuilder/Layout/Area > Tree creation --> Rendering. Uh, thanks for that one. It's a very nice show why the current apps package is a mess. SoC (Separation of Concerns) would suggest not to mix thing like CLI, public API and inner communication classes. > IMO FOTreeBuilder should just expose three functions > (perhaps another one for logging): Logging, at least in Avalon-land, is a lifecycle aspect (through the LogEnabled interface). The methods below are lifestyle methods. Lifecycle != lifestyle. It's best to talk about lifestyle primarily and leave the lifecycle (instantiation, logging, configuration, initialization) to a different discussion. Helps keeping the focus, I believe. The lifecycle can eventually be handled automatically by a container (such as Fortress or Merlin). Leaves you to care about the lifestyle (=functionality). > 1.) SetXSLFOStream() (file or stream) > 2.) SetRenderType() (those constants currently in > Driver or CommandLineStarter) > 3.) Run(). (returns a stream or file) This mixes concerns. A render type does not belong in a class called FOTreeBuilder. The name already implies that the class is responsible for building the FO tree. It should have nothing to do with the rendering aspect, especially since FO tree building is independant of the output format (wrt Renderers). The render type is better placed in a class such as a RenderingRun/Document/. The FO tree builder is (to me) a service that simply accepts a SAX stream and builds the FO tree. The layout engine, another (coarse grained) service, will then access the FO tree to do the layout. This is all kept together by a "supervising" class. At least, that's my personal high-level view of it. > You can have 500 methods of calling these functions > within the apps package--it's all fine/OK, because > they will only be able to work with FOTreeBuilder > (apps will have no access to Renderers or Layout, > etc.) and its three functions. > > Such an FOTreeBuilder may be getting to the heart of > the XSLFO Spec: > > Input: XSLFO Stream, RenderType > Output: Document > > and may be close to Xalan's approach, a team which has > similar input/output requirements. > > Also, embedded Java code should be able to run without > accessing the Apps class at all by directly calling > those three functions in FOTreeBuilder. The FOTreeBuilder should remain an inner service to FOP, not exposed in the public API, if you ask me. The public API, IMHO, should be an easily understandable construct that masks the internal complexity from the user. Driver already does that today, it's just a bit too tightly packed and not focused on as little as possible. We need to disentangle that class to make it more like the JAXP API. > (Although we > can certainly provide additional options in apps--but > FOTreeBuilder should be all that is strictly needed.) > Said another way, the processing paths of > FOTreeBuilder, once instantiated in embedded code, > should not access *any* functionality in the apps > package, because apps is to the left of the pipeline. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: startup refactoring
No problem with that. On 17.06.2003 23:03:22 J.Pietschmann wrote: > Jeremias Maerki wrote: > > main FOP api in the org.apache.fop package. > > org.apache.fop.api package? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: startup refactoring
J.Pietschmann wrote: > Well, static data often interferes badly with multithreading. > We can use it in the CLI, but in the core which is intended to be > possibly embedded in multithreaded long running server environments > should it is best to avoid them. Even if you can arrange to > synchronize properly (not as easy as many people think), blocked > threads on shared ressources will almost certainly generate angry > comments. The only static data would be a pointer to the singleton object, which contains the real data. However, it seems that your point would still be valid with regard to that data. The choices for data to be shared amongst threads are: 1. Allow concurrent access. 2. Allow synchronized access. 3. Allow no access (can't share data between threads). We all agree that #1 is bad. Implementing #3 because #2 might be slow seems counterproductive. If a person in line at the store complains that the line is moving slowly, I don't see how it helps them to say that they can't shop here any more (but it will shut them up). Or am I missing some fourth option here? Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: startup refactoring
Jeremias Maerki wrote: main FOP api in the org.apache.fop package. org.apache.fop.api package? J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: startup refactoring
Victor Mote wrote: I'm not opposed to Avalon, but I might be if I understood it. Well, the good message about Avalon is that it can make development for much easier. The bad news is that if too much of Avalon is exposed in the APIs intended for common usage, it will drive many potential embedders away. I think if we want to use Avalon internally (and there are interesting use cases, for example the Hyphenator), it would make most sense to provide an Avalon component shell which can be also used with a simple factory pattern similat to TrAX. Have a look at the Avalonization Wiki. It probably seems lazy that I am not up to speed on it yet -- I have tried a couple of times to get the big picture from the doc, but concluded that I won't get my arms around it until I use it (IOW, the doc wasn't very helpful). Amen, brother. If the static construct and Avalan are mutually exclusive, the former seems far less invasive, and easier both to implement and un-implement. Well, static data often interferes badly with multithreading. We can use it in the CLI, but in the core which is intended to be possibly embedded in multithreaded long running server environments should it is best to avoid them. Even if you can arrange to synchronize properly (not as easy as many people think), blocked threads on shared ressources will almost certainly generate angry comments. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: startup refactoring
Jeremias Maerki wrote: > > > I'm a bit unhappy that you placed/left Session in the apps package. I > > > would like to see the apps package deprecated as a whole over time. I > > > would like a cli package that only contains the stuff needed for the > > > command line and I'd like to have (wish, not a demand) the > main FOP api > > > in the org.apache.fop package. > > > > My humble apologies. What is the easiest way to roll it back? > Is there an > > automated way? > > I wasn't vetoing your changes, merely pointing out possible differences. > You didn't need to revert. But do you agree with what I wrote? Reversion is already completed -- if other changes start getting checked in, then it becomes a much more difficult task. WRT to the location of the "Session" concept, I don't have strong feelings about it the way some others do, and I viewed that as an issue that could be resolved later by simply moving it wherever you guys decided it should go. > > OK. In my terminology, Session is a long-lived object that > lives, well, for > > the Session. Document are children of Session. The only part of > Session that > > you have seen is a renaming of Driver to Session. That is all > that has been > > committed so far. But eventually nearly all of existing Driver > gets pushed > > down to Document, RenderContext, and RenderTask. The only thing > that really > > still lives in Session is the logging stuff, and it might belong with > > Document (under my scheme). > > That's not what I'm talking about. Do we all agree on this > terminology? Can > we find better classnames for what they are? These are key elements in > FOP's architecture. I'd like to have good names for them so they are > easily understandable even by outsiders. If you use Session you'll get > all sorts of strange questions. I'm pretty sure about that. I am not committed to the name "Session", but can't think of a better name, even with the help of my trusty thesaurus. I think FrameMaker uses that name in its FDK API. Microsoft uses "Application" for the equivalent concept in its Office 2000 object model. I didn't like "Driver" much or I would have left it alone (that implies a different concept to me). I suppose FOPInstance, or RuntimeInstance might work. I didn't realize that there would be misunderstandings of "Session". > > Yes, I am talking about GoF Singleton. I understand the > reluctance to use > > static variables, but I haven't adopted the no-tolerance > approach that you > > have. The alternative is to either carry the static information > around with > > you in every method that might need it, or to actually store > the information > > in every object that might need it. I already see that with the > logging. If > > it is needed, then OK, but I don't see it yet. > > So I guess it's a matter of community decision what is preferred. Going > for statics and singleton is certainly easier but it'll carry you away > from the Avalon style of life. I have no problem if the majority of > committers think that Avalon should be thrown out. I didn't manage to > introduce the Avalon-patterns, yet, and it looks like I'm the only one > really pushing it so far but without enough power. I'm not opposed to Avalon, but I might be if I understood it. It probably seems lazy that I am not up to speed on it yet -- I have tried a couple of times to get the big picture from the doc, but concluded that I won't get my arms around it until I use it (IOW, the doc wasn't very helpful). If the static construct and Avalan are mutually exclusive, the former seems far less invasive, and easier both to implement and un-implement. However, I realize that there are more things that you want to do with Avalon that might require that invasiveness anyway. Sorry I am not more help here. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: startup refactoring
--- Jeremias Maerki <[EMAIL PROTECTED]> wrote: > I'm a bit unhappy that you placed/left Session in > the apps package. I > would like to see the apps package deprecated as a > whole over time. I > would like a cli package that only contains the > stuff needed for the > command line and I'd like to have (wish, not a > demand) the main FOP api > in the org.apache.fop package. > Instinctively, I wouldn't trust any code in the package root of org.apache.fop -- we wouldn't have a very modularized design that way (knowing FOP's current coding style, the main FOP API would then be accessing objects all through the packages, octopus-like, splitting of the business logic with the actual objects doing the work, inextricable from the XSL FO process.) FOP is more a pipeline to me: APPs package (CLI, TRAX/XSLTInputHandler, Avalonized API, Victor's ideas) --> FOTreeBuilder/Layout/Area Tree creation --> Rendering. IMO FOTreeBuilder should just expose three functions (perhaps another one for logging): 1.) SetXSLFOStream() (file or stream) 2.) SetRenderType() (those constants currently in Driver or CommandLineStarter) 3.) Run(). (returns a stream or file) You can have 500 methods of calling these functions within the apps package--it's all fine/OK, because they will only be able to work with FOTreeBuilder (apps will have no access to Renderers or Layout, etc.) and its three functions. Such an FOTreeBuilder may be getting to the heart of the XSLFO Spec: Input: XSLFO Stream, RenderType Output: Document and may be close to Xalan's approach, a team which has similar input/output requirements. Also, embedded Java code should be able to run without accessing the Apps class at all by directly calling those three functions in FOTreeBuilder. (Although we can certainly provide additional options in apps--but FOTreeBuilder should be all that is strictly needed.) Said another way, the processing paths of FOTreeBuilder, once instantiated in embedded code, should not access *any* functionality in the apps package, because apps is to the left of the pipeline. > And then I'm a bit unhappy about your terminology: > Session, Document, > RenderContext... Session and Document seem like > "rubber terms" to me. > Your Session looks very much like a > FOProcessorFactory (analog to > TransformerFactory). A session to me is a > short-lived object used during > one transaction. I think we should get consensus on > the terminology > first. > Again, I don't care much about what's in the app package, but I think the idea of a one-way FOTreeBuilder with just those three/four functions exposed should be explored. In general, too much business logic is in the apps package, it evens knows about ElementMappings and Renderers -- it shouldn't have to work with anything that implementation-specific. Also, AWTStarter and PrintStarter appear to be in the wrong places, those should somehow be moved out of apps and be *past* FOTreeBuilder. Let FOTreeBuilder decide to activate those objects should it get an appropriate SetRenderType(). But my "mental model" in incomplete here...comments most welcome! Glen __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: startup refactoring
Victor Mote wrote: > My humble apologies. What is the easiest way to roll it back? Is there an > automated way? I rolled them back manually, and have committed the change. All should be back as it was before, except the affected files are two revisions higher. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: startup refactoring
On 17.06.2003 17:10:19 Victor Mote wrote: > Jeremias Maerki wrote: > > > I'm a bit concerned that you call this "startup refactoring" where it's > > really API redesign in the end, I think. And that's an important topic > > where I would have expected you to ask for a "go for it" before starting > > on this. Generally, JustDoIt (tm) is a good thing but this is about the > > API and I'd like use to reach consensus on the direction. From the Wiki > > page I read that there are substantial differences in our (you, Jörg, me) > > ideas. > > I certainly thought I had tacit consent. Well, I'm certainly guilty of letting trail off that discussion. I'm sorry if I missed anything. > > I'm a bit unhappy that you placed/left Session in the apps package. I > > would like to see the apps package deprecated as a whole over time. I > > would like a cli package that only contains the stuff needed for the > > command line and I'd like to have (wish, not a demand) the main FOP api > > in the org.apache.fop package. > > My humble apologies. What is the easiest way to roll it back? Is there an > automated way? I wasn't vetoing your changes, merely pointing out possible differences. You didn't need to revert. But do you agree with what I wrote? > OK. In my terminology, Session is a long-lived object that lives, well, for > the Session. Document are children of Session. The only part of Session that > you have seen is a renaming of Driver to Session. That is all that has been > committed so far. But eventually nearly all of existing Driver gets pushed > down to Document, RenderContext, and RenderTask. The only thing that really > still lives in Session is the logging stuff, and it might belong with > Document (under my scheme). That's not what I'm talking about. Do we all agree on this terminology? Can we find better classnames for what they are? These are key elements in FOP's architecture. I'd like to have good names for them so they are easily understandable even by outsiders. If you use Session you'll get all sorts of strange questions. I'm pretty sure about that. > Yes, I am talking about GoF Singleton. I understand the reluctance to use > static variables, but I haven't adopted the no-tolerance approach that you > have. The alternative is to either carry the static information around with > you in every method that might need it, or to actually store the information > in every object that might need it. I already see that with the logging. If > it is needed, then OK, but I don't see it yet. So I guess it's a matter of community decision what is preferred. Going for statics and singleton is certainly easier but it'll carry you away from the Avalon style of life. I have no problem if the majority of committers think that Avalon should be thrown out. I didn't manage to introduce the Avalon-patterns, yet, and it looks like I'm the only one really pushing it so far but without enough power. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: startup refactoring
Jeremias Maerki wrote: > I'm a bit concerned that you call this "startup refactoring" where it's > really API redesign in the end, I think. And that's an important topic > where I would have expected you to ask for a "go for it" before starting > on this. Generally, JustDoIt (tm) is a good thing but this is about the > API and I'd like use to reach consensus on the direction. From the Wiki > page I read that there are substantial differences in our (you, Jörg, me) > ideas. I certainly thought I had tacit consent. > I'm a bit unhappy that you placed/left Session in the apps package. I > would like to see the apps package deprecated as a whole over time. I > would like a cli package that only contains the stuff needed for the > command line and I'd like to have (wish, not a demand) the main FOP api > in the org.apache.fop package. My humble apologies. What is the easiest way to roll it back? Is there an automated way? > And then I'm a bit unhappy about your terminology: Session, Document, > RenderContext... Session and Document seem like "rubber terms" to me. > Your Session looks very much like a FOProcessorFactory (analog to > TransformerFactory). A session to me is a short-lived object used during > one transaction. I think we should get consensus on the terminology > first. OK. In my terminology, Session is a long-lived object that lives, well, for the Session. Document are children of Session. The only part of Session that you have seen is a renaming of Driver to Session. That is all that has been committed so far. But eventually nearly all of existing Driver gets pushed down to Document, RenderContext, and RenderTask. The only thing that really still lives in Session is the logging stuff, and it might belong with Document (under my scheme). > Sorry if I'm a bit negative here. I certainly don't want to kill any > enthusiasm. FOP needs this more than ever. > > > 2. Logging. During the dry run, I realized that I don't know > whether we want > > to have logging for a Session, or for each Document, or even at > some finer > > level of granularity. Session will be implemented as a > singleton, so if we > > only need logging at that level, then a static construct can be > used to get > > logging from /anywhere/ without adding anything. Otherwise, > I'll add logic > > that allows the Document object to either be directly accessed > or computed > > (by going up the object hierarchy) to get the logger. That seems more > > desirable to me than implementing logging in all of the > classes, but perhaps > > I am missing something there. > > You're talking about a singleton. I hope you don't mean a GoF Singleton. > A GoF Singleton in Java usually involves a static variable which I would > like to avoid in our new API. Yes, I am talking about GoF Singleton. I understand the reluctance to use static variables, but I haven't adopted the no-tolerance approach that you have. The alternative is to either carry the static information around with you in every method that might need it, or to actually store the information in every object that might need it. I already see that with the logging. If it is needed, then OK, but I don't see it yet. > Static logging à la Commons-Logging is the easiest thing, sometimes even > necessary if you ask people like Nicola Ken Barozzi. Even in > Avalon-enabled software. The normal Avalon style of logging means a > container is giving a logger instance to a service (see LogEnabled). > > As long as we're talking about services (Renderer, FOTreeBuilder, > org.apache.excalibur.source.SourceResolver, > org.apache.excalibur.xml.sax.SAXParser etc.), Avalon-style logging is > superior (but more difficult to do right), because you can have multiple > instances of the same service in a VM but logging to separate log files, > for example, if you run two different applications in the same VM (in > Avalon Phoenix, for example). You could have an invoicing system and a > CRM system both running FOP for document production but logging to > different log files. Ok, they could be separated by different > classloaders but I still think not having statics in a server > environment is better. That sounds possibly useful for what we are doing. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: startup refactoring
On 17.06.2003 01:38:14 Victor Mote wrote: > I did a dry run of the startup refactoring (Session, Document, etc.) work > yesterday & this morning, and am satisfied that the concepts work. > Here are some comments: > > 1. I am going to start committing changes, hopefully this evening. Much of > the work is refactoring, but there are some substance changes as well, > specifically to allow multiple output options, multiple documents, etc. I > have therefore decided to implement it as a series of self-contained > changes, rather than dropping the entire change in at once. This will make a > better doc trail. Let me know if you object. I'm a bit concerned that you call this "startup refactoring" where it's really API redesign in the end, I think. And that's an important topic where I would have expected you to ask for a "go for it" before starting on this. Generally, JustDoIt (tm) is a good thing but this is about the API and I'd like use to reach consensus on the direction. From the Wiki page I read that there are substantial differences in our (you, Jörg, me) ideas. I'm a bit unhappy that you placed/left Session in the apps package. I would like to see the apps package deprecated as a whole over time. I would like a cli package that only contains the stuff needed for the command line and I'd like to have (wish, not a demand) the main FOP api in the org.apache.fop package. And then I'm a bit unhappy about your terminology: Session, Document, RenderContext... Session and Document seem like "rubber terms" to me. Your Session looks very much like a FOProcessorFactory (analog to TransformerFactory). A session to me is a short-lived object used during one transaction. I think we should get consensus on the terminology first. Sorry if I'm a bit negative here. I certainly don't want to kill any enthusiasm. FOP needs this more than ever. > 2. Logging. During the dry run, I realized that I don't know whether we want > to have logging for a Session, or for each Document, or even at some finer > level of granularity. Session will be implemented as a singleton, so if we > only need logging at that level, then a static construct can be used to get > logging from /anywhere/ without adding anything. Otherwise, I'll add logic > that allows the Document object to either be directly accessed or computed > (by going up the object hierarchy) to get the logger. That seems more > desirable to me than implementing logging in all of the classes, but perhaps > I am missing something there. You're talking about a singleton. I hope you don't mean a GoF Singleton. A GoF Singleton in Java usually involves a static variable which I would like to avoid in our new API. Static logging à la Commons-Logging is the easiest thing, sometimes even necessary if you ask people like Nicola Ken Barozzi. Even in Avalon-enabled software. The normal Avalon style of logging means a container is giving a logger instance to a service (see LogEnabled). As long as we're talking about services (Renderer, FOTreeBuilder, org.apache.excalibur.source.SourceResolver, org.apache.excalibur.xml.sax.SAXParser etc.), Avalon-style logging is superior (but more difficult to do right), because you can have multiple instances of the same service in a VM but logging to separate log files, for example, if you run two different applications in the same VM (in Avalon Phoenix, for example). You could have an invoicing system and a CRM system both running FOP for document production but logging to different log files. Ok, they could be separated by different classloaders but I still think not having statics in a server environment is better. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: startup refactoring
--- Victor Mote <[EMAIL PROTECTED]> wrote: > > 1. I am going to start committing changes, hopefully > this evening. Much of > the work is refactoring, but there are some > substance changes as well, > specifically to allow multiple output options, > multiple documents, etc. I > have therefore decided to implement it as a series > of self-contained > changes, rather than dropping the entire change in > at once. This will make a > better doc trail. Let me know if you object. > Shouldn't be a problem (we can always go back to the old code if it's a disaster!) When you're done, I still would like to get the LayoutHandler and StructureHandler classes out of the apps package though (Bug 20397, although on these new classes)--any objections from anyone on this part? Glen __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
