xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From COFFMAN Steven <SCoff...@CBSINC.com>
Subject RE: org.apache.fop.render.awt.AWTRenderer, again
Date Thu, 05 Oct 2000 17:07:46 GMT
Hi Domagoj,

I had to import java.net.MalformedURLException, and change the "Font" into
"java.awt.Font" in your patch, but I don't know what
currentAreaContainerXPositionShadow is supposed to be. It's not defined
anywhere I can see, and my compiler pukes on it. After you tell me that I
think we can commit it.

I'm referring to trying to apply the last patch you sent, not the first one.

I figured the URL exception was like that. 

-----Original Message-----
From: Domagoj Cosic [mailto:Domagoj.Cosic@hypercis.de]
Sent: Thursday, October 05, 2000 6:11 AM
To: 'fop-dev@xml.apache.org'
Subject: RE: org.apache.fop.render.awt.AWTRenderer, again

Look down for my answer:

> -----Original Message-----
> From: Eric SCHAEFFER [mailto:eschaeffer@posterconseil.com]
> Sent: Thursday, October 05, 2000 11:35 AM
> To: fop-dev@xml.apache.org
> Subject: Re: org.apache.fop.render.awt.AWTRenderer, again


> ----- Original Message -----
> From: "COFFMAN Steven" <SCoffman@CBSINC.com>
> To: <fop-dev@xml.apache.org>
> Sent: Wednesday, October 04, 2000 9:29 PM
> Subject: RE: org.apache.fop.render.awt.AWTRenderer, again

> I'm going to
> wait
> > on Eric or a patch that's less scary.
> 1 - The problem is that I don't know the AWTRenderer.
> I agree that exceptions should be handled, but it's also true 
> that if an
> error occur, we only don't show the image... (maybe we should draw an
> "error" image or something like that)

We cannot do that. My first version with ignoring the error was O.K. If the
URL was not O.K. then renderImageArea never gets called in the first place.
I tried the following, but it never displays an error image, if and I did
the same in the catch clause. The execution never gets there!!! But if you
insist, you can modify the code the following way:

	public void renderImageArea(ImageArea area) {
		int x = currentAreaContainerXPositionShadow +
		int y = currentYPosition;
		int w = area.getContentWidth();
		int h = area.getHeight();
		FopImage img = area.getImage();
		if (img == null) {
			MessageHandler.logln("Error while loading image :
area.getImage() is null");
			graphics.drawRect(x / 1000,
					   pageHeight - y / 1000,
					   w / 1000,
					   h / 1000);
			Font f = graphics.getFont();
			Font smallFont = new
			graphics.drawString("area.getImage() is null", x /
1000, pageHeight - y / 1000);	
		} else {
			String urlString = img.getURL();
			try {
				URL url = new URL(urlString);
				ImageIcon icon = new ImageIcon(url);
				Image image = icon.getImage();
				graphics.drawImage(image, x / 1000,
						   pageHeight - y / 1000,
						   w / 1000,
						   h / 1000,
			} catch(MalformedURLException mue) {
				// cannot normally occur because, if URL is
wrong, constructing FopImage
				// will already have failed earlier on
		currentYPosition -= h;

> 2 - As I can see, the image data is read "again" during 
> rendering (when
> creating an ImageIcon). When I tried to create the FopImage 
> interface, I
> asked to people writing the AWTRenderer class if the 
> interface befit them.
> But if the FopImage interface was returning the image data as 
> an int array
> (like Java does), maybe it would make things easier.
> Comments and ideas wellcomed ....

Hmh, if all implementaions of FopImage had lazy behaviour, the image would
not be read "again" but only once, and the user of the interface would have
the choice either to read the image through the particular FopImage
implementation or from it original location. At least as long as we don't
have a better solution, I find using built in AWT-Image mechanisms simpler
to use because they are optimized for reading images from their original



View raw message