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 17:17:26 GMT

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

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

I have to think about it. Just - Image is an abstract representation of and
image an a pure bitmap is device dependent: you always have to know how to
interpret it. Or do you imply that you always return a RGBA bitmap as int[],
even if you have a bi-level original!? Say, you want to display it on a
256-coloured display: you once transform it from 1-bit to 32-bit and then
back to 8-bit: what a computational and memory overhead. If you use byte[]
instead, the user of the method has to know much more (issues like the
number and order of colour components, even bits per pixel if you want to
save memory) in order to interpret the bitmap. Instead, you could leave the
decision to latest possible moment... It is not that easy. I would still
prefer an opaque Image and not having to know what is inside in order to
display it.

About SVG and other vector formats - I would leave the rasterizing to the
particular graphic engine. First of all, the most important property of SVG
is that it is Scalable. You have to know the output resolution in the moment
you display it, not before. In your approach, you would have to tell
FopImage the resolution you want every time you display the image, otherwise
you would loose the advantages of SVG. We cannot abstract everything as a
bitmap. Those are all graphical objects though, and can be rendered, that's

That's just my sole opinion. Let us find the best solution.



View raw message