I worked on my patch and tried to integrate you inputs. There are still many issues, but I think the basic structure is OK. You can find a patch attached to bug 33760.
Comments inline: On Mon, 28 Feb 2005, Victor Mote wrote: > 1. FOray has factored the FOP font logic into a separate module, cleaned it > up significantly, and made some modest improvements. A few weeks ago, I > aXSL-ized it as well, which means that it is written to a (theoretically) > independent interface: > http://cvs.sourceforge.net/viewcvs.py/axsl/axsl/axsl-font/src/java/org/axsl/ > font/ > I think there is general support within FOP to implement the FOray/aXSL font > work in the FOP 1.0 code, but so far no one has actually taken the time to > do it. If you get into messing with fonts at all, I highly recommend that > FOray be implemented before doing anything else. I will be happy to support > efforts to that end. For what I understand now, your approach sounds good to me. But I'm missing some major pieces of the picture ATM to start implementing your aXSL interface in FOP. Please let me come back to you when I'll feel more comfortable with the font-mechanism. On Mon, 28 Feb 2005 , Jeremias Maerki wrote: > > AbstractRenderer: I moved what I could reuse from PDFRenderer to > > AbstractRenderer: renderTextDecorations(), handleRegionTraits(), and added > > the > > needed empty methods. > > I think that was good although only time will tell if this will hold for > all renderers to come. Eventually, I didn't modify AbstractRenderer, PDFRenderer and PS Renderer at all. The implementation of AWTRenderer is close to the other renderers, so that putting some methods in AbstractRenderer should not be a big problem. > > Speaking of startVParea(), could we rename it to something more meanigfull? > > Proposition: TransformPosition, or something like this. > > Actually, I like startVParea() (or rather startViewportArea like I would > rather call it) because only for viewport a new transformation matrix is > necessary. startViewportArea() is fine for me. > I think the Java2D approach is not unlike the > PDF/PS approach. Adobe was Sun's closest partner when they developed the Java2D API. > > I implemented a simple .bmp rendering (BMPReader.java). > > If there's a better way to render .bmp (JAI?), let me know. > > This should not be necessary. We have a BMP implementation in > org.apache.fop.images. > The BMP bitmaps should be loaded through that mechanism. OK, now I see. But how can I get an awt.Image from a FopImage? > BTW, Using Graphics.create() you should be able to create a copy of the > current Graphics2D object. By pushing the old one on a stack and > overwriting the graphics member variable should should be able to create > the same effect as with currentState.push()/saveGraphicsState() in > PDFRenderer.startVParea () and currentState.pop()/restoreGraphicsState > ()in endVParea(). When leaving a VP area you can simply restore an older > Graphics2D object for the stack and continue painting. This will undo > any transformations and state change done in the copy used within the VP > area. See second paragraph in javadocs of java.awt.Graphics. Thanks for the hint. I did just that in AWTGraphicsState (same as PDFState). It holds all the context (font, colour, stroke, transformation) of the current graphics, and can act as a stack, too. I created an interface (RendererState) that could be implemented by all xxxState of the renderers. To be discussed... I also added a "Debug" button on the AWTRenderer-Windows, which outlines the blocks. This is just a test, and I would like to develop a full-fledged visual debugger [1]. If this code works for you, then I'll start to separate the Java2DRenderer and the AWTRenderer. Otherwise, please tell me how I can improve my code. Renaud [1] http://wiki.apache.org/xmlgraphics-fop/FopAndJava2D
