--- "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-dev&m=107503563018878&w=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>
