xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric SCHAEFFER" <eschaef...@posterconseil.com>
Subject Re: org.apache.fop.render.awt.AWTRenderer, again
Date Thu, 05 Oct 2000 11:05:35 GMT

----- Original Message -----
From: "Domagoj Cosic" <Domagoj.Cosic@hypercis.de>
To: <fop-dev@xml.apache.org>
Sent: Thursday, October 05, 2000 12:11 PM
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:
>

I agree. If you get an FopImage object, the URL is good. But there can be a
error while recovering image data...

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

All FopImage implementing classes should read, at initialization, image
headers but not image data. So the image data isn't read twice, ok. But the
FopImage implementing classes are here to provide a way to have access to
the iamge headers AND to the image data. That's why i don't really like the
idea to use another way to read images.

I agree that the AWT-mechanisms used by ImageIcon can be better optimized,
but you can't read all image formats. The FopImage architecture allow a user
to add his own format of image, and it is used "everywhere" (in the AreaTree
and the PDFRenderer). So what do you prefer ? Using AWT mechanisms because
they are faster, even if it can break the fop architecture, or integrate the
fop architecture into the AWTRenderer ? That's the reall question, I think.

Or maybe we should change the FopImage architecture...

Eric.

> Regards,
>
> Domagoj
>


Mime
View raw message