(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

> 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

> 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

> 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 
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,

> 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?


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

Reply via email to