(Comments inline) On 27.02.2005 23:51:25 bugzilla wrote: > I've been working on the AWTRenderer those last days. Before I move forward, I > would welcome some feedback to know if I'm heading in the right direction.
I think you are. Interesting work. Keep it up! > = What I did = > > Basically, I tried to implement in AWTRenderer what the PDFRenderer does. The > drawback is that all what doesn't work for the PDFRenderer doesn't work for > the > AWTRenderer neither. > I've posted a patch with the updated renderers. The patch has changes for the > classes AWTRenderer, AbstractRenderer, PDFRenderer and CTM plus a new class > BMPReader. > > AWTRenderer: I implemented several renderXXX() methods and the corresponding > helper methods. > > 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. Each renderer may have a slightly different way of holding state (currently selected line width, font etc.). So far it looks good to me even if pulling up currentFontName was necessary. Ideally, this variable should probably not be in AbstractRenderer I think. > PDFRenderer ans PSRenderer: > I moved 2 lines (currentIPPosition = 0; currentBPPosition = 0; ) in > startVParea() because the AWTRenderer uses those values in another way and > need > to keep track of them (see startVParea() in AWTRenderer). > Speaking of startVParea(), could we rename it to something more meanigfull? > Proposition: TransformPosition, or something like this. > Deleted the methods moved to AbstractRenderer. Actually, I like startVParea() (or rather startViewportArea like I would rather call it) because only for viewport a new transformation matrix is necessary. I think when you port the matrix concatenation from the PDF renderer over to Java2D in startVParea() you will start to understand what's going on here. I think the Java2D approach is not unlike the PDF/PS approach. See Graphics2D.setTransform() and AffineTransform.concatenate(). > fop.area.CTM: added two getters for e and f. If there's another way to get > those > values, please let me know. Normally, we use toArray() but I guess these two getters are ok and don't hurt although I think they are not necessary because you need to use all other values in the CTM, too, to get the reference orientation stuff right. See above. > = Points I would like to discuss (see the corresponding FIXME in the code) = > > Fonts: I must be missing something with the font-mechanism: the rendered text > in > the AWTRenderer is smaller that the one of PDFRenderer. The AWT/Java2D renderer uses a different font source than the PDF and PS renderers. The AWT/Java2D renderer gets the font metrics of the individual fonts from the AWT subsystem. See AWTFontMetrics and FontMetricsMapper. The different way of getting font metrics may result in a slighly differently rendered document when compared to PDF. That is expected and is the same in FOP 0.20.5. > What I need is a way to get a java.awt.Font from an area. I think you are already on the right track with the current implementation. Simply use PDFRenderer.updateFont() as a reference. The only thing I see is that you should check currentFontName and -Size to avoid any unnecessary and costly creation of Font objects. The FontMetricsMapper should do all the rest for you. > Is the class FontSetup implemented correctly? Yes, I think so, although it might be worth checking out if the available font could be enumerated and registered. On the other side this might lead to a lot of work being done during setup. Maybe this stuff could be refactored to do late font resolution (creation of the necessary objects when needed/requested). Check with a special font (not Arial or Times or one of the standard fonts) from your system to see what happens. > Do I have to worry about multibyte-stuff? I don't think you have to worry about multi-byte stuff because it will be handled for you as Java internally uses Unicode and you only send normal Unicode strings to the Java2D api. > I could investigate the whole mechanism, but a hint would certainly speed my > work. > Colors: My method updateColor (Graphics2D graphics, Area area) doesn't work > for > some areas.Same question here: how can I get a java.awt.Color from ANY area? Not sure but I think Graphics2D.setColor() only sets the stroking and text color. Have a look at Graphics2D.setPaint(). Did you see that you didn't use the fill parameter of updateColor? if fill is true you can probably simply set graphics.setPaint(newCol). Try to consolidate all the updateColor() methods. Also I'd remove ColorTypeProperty.getAWTColor() to avoid the dependency on java.awt.Color. Use AWTRenderer.toColor instead and improve this for non-sRGB colors (if we already have color outsite sRGB). > There are still many issues with the positioning of the areas. I keep track of > the current position with the variables currentIPPosition and > currentBPPosition. Mostly related to omissions in startVParea I think. > Images: I can't update the currentIPDPosition and currentBPDPosition for > Image-areas. The Viewport associated with the image doesn't have any bpd > associated with it. Is this normal? No. For external-graphics and instream-foreign-object there are still a few gaps in the LMs. > The enclosed image doesn't have ipd/bpd > either. Again: is this normal so? I have a workaround in mind (getting those > values through the FopImage), but it doesn't sound right. In this case it is probably better to fix the LMs. I've started doing that but haven't finished. ATM this is lower priority for me. I can send you my current code if you want to try to fix it. Shouldn't be so difficult. > I implemented a simple .bmp rendering (BMPReader.java). It only supports 8-bit > and 24-bit uncompressed windows bitmap images. I found this code on the net. I > know you had problems with licences and I don't want to raise an issue here. I > did this implementation more for myself than anything. If there's a better way > to render .bmp (JAI?), let me know. Otherwise, I could try to convince the > author to donate the code in conterpart of some fine chocolate :) This should not be necessary. We have a BMP implementation in org.apache.fop.images. The BMP bitmaps should be loaded through that mechanism. Your approach only fixes AWT/Java2D and not PDF, PS etc. The only image types that should be allowed to be treated in a special way are XML-based formats, EPS and JPEG. > SVG + External Objects rendering is very alpha. No problem. This is work in progress after all. > renderTextDecoration(InlineArea) seems to work, even if it's not implemented?? Huh? It was you who moved the implementation up from PDFRenderer to AbstractRenderer. That's how you implemented it. Inheritance! > renderViewport is overriden in PDFRenderer to allow clip(). Is this feature > also > needed in AWTRenderer? Yes. 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. > > = What's next = > > - fix the bugs described here > - implement the remaining features > - test the renderer on more complex files > - implement what's described on the wiki FopAndJava2D [1] > > > In the code, I used the following conventions: FIXME for the points I would > like > you to review before checking the code in. And TODO for the points I still > have > to work out (so please leave them). If someone using eclipse could mail me his > formatter (Preferences>Java>Code Style>Formatter, then Export profile), that > would be nice. > > Any comments or suggestions most welcome. Again, please let me know if I'm > doing > things the right way. > > I wish you a nice weekstart. > Renaud > > [1] http://wiki.apache.org/xmlgraphics-fop/FopAndJava2D I'll let you improve your patch a bit before applying it. As I said, I think you're going in the right direction. I'm looking forward to committing your changes when you're happy with the results. Another thought: One of my low-priority tasks is to create a little application that renders a test suite with all of FOP's renderers creating bitmap images for each generated document and ultimately creating a little website that lets us compare the output. PDFs and PS files can be converted to bitmaps using GhostScript. Maybe you might want to write such a thingy. I won't get to it before I get to updating the PS renderer to full quality. Jeremias Maerki
