Re: SVG Generator
Glen Mazza wrote: --- Peter B. West [EMAIL PROTECTED] wrote: Obviously, I would love to be able to output alt-design's layout to PDF without having to build a new interface mechanism. I think you have that already in the render.Renderer interface--which defines those methods that a Renderer must be able to implement. Review it and let us know where you think it needs modification. What I'm looking for is summarised in the following code snippet from http://xml.apache.org/batik/svggen.html DOMImplementation impl = SVGDOMImplementation.getDOMImplementation(); String svgNS = SVGDOMImplementation.SVG_NAMESPACE_URI; SVGDocument doc = (SVGDocument)impl.createDocument(svgNS, svg, null); SVGGraphics2D g = new SVGGraphics2D(doc); // Draw into g. For example: // Shape circle = new Ellipse2D.Double(0,0,50,50); g.setPaint(Color.red); g.fill(circle); g.translate(60,0); g.setPaint(Color.green); g.fill(circle); g.translate(60,0); g.setPaint(Color.blue); g.fill(circle); g.setSVGCanvasSize(new Dimension(180,50)); // The following populates the document root with the // generated SVG content. Element root = doc.getDocumentElement(); g.getRoot(root); // Now, display the document JSVGCanvas canvas = new JSVGCanvas(); JFrame f = new JFrame(); f.getContentPane().add(canvas); canvas.setSVGDocument(doc); f.pack(); f.setVisible(true); Note the SVGGraphics2D object, and the JSVGCanvas object for output. The graphics are constructed in SVGGraphics2D in the same way they are in any other Graphics2D object: g.fill(), g.setPaint(), g.translate() etc. SVG Generator can be added to an environment in which Java 2D graphics are already being produced, using the same instructions which are used on a Graphics2D object. The SVGGraphics2D object is used instead, and the same graphical operations are rendered in SVG. Substitute PDF for SVG. It so happens that the availability of such a substitution would be of great use to me, because I am constructing the layout in Java 2D terms, so that I can get it working with minimum agony. I don't hold out any hope that that will happen as part of FOP, but if it were to happen, FOP would have created a PDF library which could almost transparently be inserted into existing Java 2D programs. Do you see what I mean? The FO input cannot be fully realised with a complete resolution of the properties, which in turn relies on layout. (Old argument, I know.) Well, you should have taken the time to refer people to places in the spec [1] which supported your position-- maybe these arguments could have been avoided. [1] http://marc.theaimsgroup.com/?l=fop-devm=107503563018878w=2 A nice summary, Glen, and one I have myself offered (the critical points of it anyway) to the debate before, with exactly the same result. I would add the following, which occurs after your quotes (3.1 Conceptual Procedure). quote The procedure works by processing formatting objects. Each object, while being processed, may initiate processing in other objects. While the objects are hierarchically structured, the processing is not (my emphasis); processing of a given object is rather like a co-routine which may pass control to other processes, but pick up again later where it left off. The procedure starts by initiating the processing of the fo:root formatting object. Unless otherwise specified, processing a formatting object creates areas and returns them to its parent to be placed in the area tree. (my emphasis) Like a co-routine, it resumes control later (my emphasis) and initiates formatting of its own children (if any), or some subset of them. The formatting object supplies parameters to its children based on the traits of areas already in the area tree, possibly including areas generated by the formatting object or its ancestors. It then disposes of the areas returned by its formatting object children. It might simply return such an area to its parent (and will always do this if it does not generate areas itself), or alternatively it might arrange the area in the area tree according to the semantics of the formatting object; this may involve changing its geometric position. It terminates processing when all its children have terminated processing (if initiated) and it is finished generating areas. /quote Note the order of operations; that's what alt-design will be doing. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: SVG Generator
--- Peter B. West [EMAIL PROTECTED] wrote: SVG Generator can be added to an environment in which Java 2D graphics are already being produced, using the same instructions which are used on a Graphics2D object. The SVGGraphics2D object is used instead, and the same graphical operations are rendered in SVG. Substitute PDF for SVG. I think I see what you're mentioning. One issue is that an SVG Document really just translates to a PDF *Page*--and we still have the issue of forward references and perhaps others that SVG doesn't have to be concerned with. [Speaking of which, for references such as Page 1 OF X, which ordinarily require all X pages to be generated before the first page can be rendered--I'd like to think of a way in which placeholders can be placed in the output document, regardless whether PDF/PS, etc., for a final filling in of the last page number later. FOP does not do this currently in HEAD, and IIC in maintenance either. I think we need an ability to set and resolve placeholders (when the document is finished) within the Renderers--i.e., expand the Renderer interface to provide for this. Is this doable? Will it still be doable if we adopt your approach?] There may be an issue with efficiency here as well--I'm unsure if the graphical method is the most efficient way of writing out text data. (PDF is like RTF, internally human-readable text.) AWT and PDF can share the same rendering model--they do in 0.20.5--but there are also some differences. The AWT viewer is re-entrant, i.e., the user can change the source in a text editor and press Refresh in the AWT viewer to see the changes. OTOH, the PDF and other renderers just finish when the document is done. Also, IIRC, AWT does a page-by-page rendering as the user changes the page on the screen. PDF doesn't--the whole document is returned at once. (The above may not have any relevance to what you're proposing, but I'm mentioning it just in case.) It so happens that the availability of such a substitution would be of great use to me, because I am constructing the layout in Java 2D terms, so that I can get it working with minimum agony. Yes, but a PDFGraphics2D will take some time to develop. I'm still with FO objects and layout. We can keep this open as an idea, at least. Glen
Re: SVG Generator
We have it already (to a certain extent)unless I fail to see the point. We have: org.apache.fop.svg.PDFDocumentGraphics2D org.apache.fop.render.ps.PSDocumentGraphics2D org.apache.fop.render.ps.EPSDocumentGraphics2D Of course, it will take some more time to mature but the most important parts are there. I have even added support for multi-page generation in AbstractPSDocumentGraphics2D. Will be easy to add to PDFDocumentGraphics2D. At one point I did a proof-of-concept (not committed) to use the three classes above to create additional output formats for JPS (Java Printing System). One downside I see by using the Graphics2D exclusively is that you will (probably) lose the ability to pass through in-stream objects (JPEGs and SVGs) as-is to the target format. A JPEG will be decoded into a BufferedImage, an SVG will be rendered to a Graphics2D and reencoded as SVG, EPS might not make it into a PS file as-is anymore unless we create a PostScript interpreter (still on my very-long-term wish-list). You guys might want to talk to Hansueli Anderegg who's a fan of the exclusive Java2D approach AFAICS. I'd personally prefer to leave the PDF and PS renderer intact in HEAD for now. No problem with creating a second path and then seeing which is best. On 12.06.2004 13:52:14 Glen Mazza wrote: It so happens that the availability of such a substitution would be of great use to me, because I am constructing the layout in Java 2D terms, so that I can get it working with minimum agony. Yes, but a PDFGraphics2D will take some time to develop. I'm still with FO objects and layout. We can keep this open as an idea, at least. Jeremias Maerki
RE: SVG Generator
Glen Mazza wrote: The FO input cannot be fully realised with a complete resolution of the properties, which in turn relies on layout. (Old argument, I know.) Well, you should have taken the time to refer people to places in the spec [1] which supported your position-- maybe these arguments could have been avoided. [1] http://marc.theaimsgroup.com/?l=fop-devm=107503563018878w=2 Are you guys referring to me? My last word on the subject is here: http://marc.theaimsgroup.com/?l=fop-devm=107074009107318w=2 and it has never been answered by Peter or Glen or anyone else. It is no longer a concern of mine that FOP has returned to a monolithic design, but I think it is a bit unfair to the new developers to imply that the XSL-FO standard mandates such a design, at least with the reasoning that has been offered so far. Victor Mote
RE: SVG Generator
Victor Mote [EMAIL PROTECTED] wrote on 12.06.2004 17:35:04: It is no longer a concern of mine that FOP has returned to a monolithic design, but I think it is a bit unfair to the new developers to imply that the XSL-FO standard mandates such a design, at least with the reasoning that has been offered so far. AFAICS, the cited part of the XSL-FO recommendation only mandates that for refinement the formatter needs feedback from the area tree in some situations. It's just a hint to implementors: hey, it's not as simple as it looks - it's not a pure sequential process. That's it. Let's also remember that refinement and area tree are artifacts used to formally describe the *result* of the formatting process. There is no reason to believe there must be a refinement step or even an area tree as such in an implementation. Of course, directly following the conceptual procedure outlined in the recommendation makes it easiest to validate that the implementation is right, but I don't see that it necessarily leads to the best implementation. Victor's comment (http://marc.theaimsgroup.com/?l=fop-devm=107074009107318w=2) is perfectly valid IMO. Also IMO, design discussions should be about evaluating opportunities in the first place and finding and eliminating showstoppers in the second place. If the benefits of a certain design are important enough and this is seen so by several people, the chances are good that the perceived showstoppers can be eliminated. I think this also applies to Peter's current suggestions. My 2 cents, Arnd -- Arnd Beißner Cappelino Informationstechnologie GmbH
Re: SVG Generator
Jeremias, ... Jeremias Maerki wrote: We have it already (to a certain extent)unless I fail to see the point. We have: org.apache.fop.svg.PDFDocumentGraphics2D org.apache.fop.render.ps.PSDocumentGraphics2D org.apache.fop.render.ps.EPSDocumentGraphics2D Of course, it will take some more time to mature but the most important parts are there. I have even added support for multi-page generation in AbstractPSDocumentGraphics2D. Will be easy to add to PDFDocumentGraphics2D. At one point I did a proof-of-concept (not committed) to use the three classes above to create additional output formats for JPS (Java Printing System). Thanks for the info. You didn't miss the point, I did. I hadn't even looked at your svg or ps handling, and I had forgotten your earlier mention of the uncommitted proof of concept. I was talking concepts here anyway, and I'm exhilarated to find that you have already done so much work along these lines. Can you drop your code into a branch? One downside I see by using the Graphics2D exclusively is that you will (probably) lose the ability to pass through in-stream objects (JPEGs and SVGs) as-is to the target format. A JPEG will be decoded into a BufferedImage, an SVG will be rendered to a Graphics2D and reencoded as SVG, EPS might not make it into a PS file as-is anymore unless we create a PostScript interpreter (still on my very-long-term wish-list). On the image and foreign object front, although I haven't had time to think this through, I think there will be scope within the over-ridden methods to effectively do a pass-through. For layout, all we need to know is the laid-out size and positioning of the element. Images don't have to be fully rendered until they reach the renderer - PDF, PS, 2D. How this would work with those formats I don't know, because I don't know anything about image formats. You guys might want to talk to Hansueli Anderegg who's a fan of the exclusive Java2D approach AFAICS. I'd personally prefer to leave the PDF and PS renderer intact in HEAD for now. No problem with creating a second path and then seeing which is best. I don't see that happening, as I mentioned in my post. I was just excited by the notion of the SVG Generator, and wanted to rattle on a bit about it. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: SVG Generator
Victor Mote wrote: Glen Mazza wrote: The FO input cannot be fully realised with a complete resolution of the properties, which in turn relies on layout. (Old argument, I know.) Well, you should have taken the time to refer people to places in the spec [1] which supported your position-- maybe these arguments could have been avoided. [1] http://marc.theaimsgroup.com/?l=fop-devm=107503563018878w=2 Are you guys referring to me? My last word on the subject is here: http://marc.theaimsgroup.com/?l=fop-devm=107074009107318w=2 and it has never been answered by Peter or Glen or anyone else. Victor, I can't speak for Glen, but I wasn't referring to you. HEAD does not perform the sort of control-splicing between FO tree creation and area tree creation that is implied in the Recommendation as quoted. That's the old argument. It is no longer a concern of mine that FOP has returned to a monolithic design, but I think it is a bit unfair to the new developers to imply that the XSL-FO standard mandates such a design, at least with the reasoning that has been offered so far. Lest there be any doubt in the minds of new developers, the first sentence of 3.1 Conceptual Procedure (from which I quoted) is, This subsection contains a conceptual description of how formatting could work. This conceptual procedure does not mandate any particular algorithms or data structures as long as the result obeys the implied constraints. The reason I want to follow the model proposed is that I think it is the best way to go. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: SVG Generator
--- Peter B. West [EMAIL PROTECTED] wrote: Obviously, I would love to be able to output alt-design's layout to PDF without having to build a new interface mechanism. I think you have that already in the render.Renderer interface--which defines those methods that a Renderer must be able to implement. Review it and let us know where you think it needs modification. The FO input cannot be fully realised with a complete resolution of the properties, which in turn relies on layout. (Old argument, I know.) Well, you should have taken the time to refer people to places in the spec [1] which supported your position-- maybe these arguments could have been avoided. [1] http://marc.theaimsgroup.com/?l=fop-devm=107503563018878w=2 Glen
