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:59:30 GMT
Ah! I saw the name similarity, but I wanted to be sure. I committed your
patch. Please check it out of CVS and test it, as I haven't heard from
Juergen, Rainer, and Stanislav (the AWTRenderer folks) in a while.

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


Hi Steven,

about the symbol that could not be resolved:

currentAreaContainerXPositionShadow should be currentAreaContainerXPosition.


The problem aroused because I did not patch the original class but made a
class which extends it in order to not patch the parent class.
currentAreaContainerXPosition happens to be private, so I recalculated it
and named it currentAreaContainerXPositionShadow. (However I DID patch
graphics to protected because of the same reason, but there I had no
choice). You can recognize that, if you change the original class, you can
now use currentAreaContainerXPosition directly and forget about the shadow
variable. Sorry about the mess.

Domagoj

> -----Original Message-----
> From: COFFMAN Steven [mailto:SCoffman@CBSINC.com]
> Sent: Thursday, October 05, 2000 7:08 PM
> To: 'fop-dev@xml.apache.org'
> Subject: RE: org.apache.fop.render.awt.AWTRenderer, again
> 
> 
> 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. 
> 
> -Steve
> -----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 +
> 		    area.getXOffset();
> 		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
> Font(f.getFontName(),f.getStyle(),8);
> 			graphics.setFont(smallFont);
> 			graphics.drawString("area.getImage() is 
> null", x /
> 1000, pageHeight - y / 1000);	
> 			graphics.setFont(f);
> 		} 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,
> 						   null);
> 			} 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
> locations.
> 
> Regards,
> 
> Domagoj
> 

Mime
View raw message