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 16:32:20 GMT

----- Original Message -----
From: "Domagoj Cosic" <Domagoj.Cosic@hypercis.de>
To: <fop-dev@xml.apache.org>
Sent: Thursday, October 05, 2000 4:56 PM
Subject: RE: org.apache.fop.render.awt.AWTRenderer, again


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

Why not. Or the FopImage.getImage() method could return int[]... (but
effectively there should be a method to get the Java ColorSpace object)

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

I don't understand (sorry, my english is very bad).
Let's just explain my vision of the FopImage interface:
every implementing class has the responsability to read/decompress/create
the image data and headers associated with the given URL. But it should only
return the image data as a bitmap. If the real image data is vectors, the
associated FopImage implementing class return the image as a bitmap (and why
not using a Graphic instance object).
One example can be a SVG image. Or an xml file representing chemical
objects, I don't know...
The API is just "opened" and extendable.

Maybe I'm wrong or think to things we don't need.

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

Thank's
;-)

>
> Domagoj
>

Eric.



Mime
View raw message