xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Domagoj Cosic <Domagoj.Co...@hypercis.de>
Subject RE: org.apache.fop.render.awt.AWTRenderer, again
Date Thu, 05 Oct 2000 14:56:16 GMT
> -----Original Message-----
> From: Eric SCHAEFFER [mailto:eschaeffer@posterconseil.com]
> Sent: Thursday, October 05, 2000 1:06 PM
> To: fop-dev@xml.apache.org
> Subject: Re: org.apache.fop.render.awt.AWTRenderer, again
> 
> 
> 

...

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

If so, then it would be wise for FOPImage to define a Method Image
getJavaImage(), so that AWTRenderer does not have to combine the bytes the
FOPImage currently supplies itself to an Image. Such a code would have to be
ColorSpace aware and would be increasingly complex with every new image
type, with FOPImage interface providing no encapsulation/hiding at all and
so missing its objective. It should not be difficult to implement, as almost
all Java image libraries are somehow able to deliver an Image. Correct?

In all other points I absolutely agree with you.

Domagoj

Mime
View raw message