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 Fri, 06 Oct 2000 08:22:23 GMT

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


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

Ok, but 2 things :

1 - what is "an opaque Image" ? What is its representation ?
We always need to know what is inside if we want to display it.
2 - For the AWTRenderer, you use the Java native classes to display the
image, because they know how to read/display it, and so you don't have to do
it. That's not the case for the PDFRenderer (and maybe for futur other
renderers).

Java images are represented as int[], whatever is the image format (RGB,
RGBA, YCM, and even indexed images), if I remember well. And that's the
ColorSpace class that tell us how to interpret the int array.
That's why I spoke about int[].
If you think there's a better way...

About overhead, I don't know... I'm not sure it will create so much
overhead. Using int[] is closer to Java native methods.

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

Just an explanation : I don't mean to replace SVG by FopImage classes. I
just mean to provide a way to draw whatever image format users want. For
SVG, FOP supports it.
Vector format was maybe a wrong example...

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

That's what I want to do, but it's not easy.

Eric.

>
> Regards,
>
> Domagoj
>


Mime
View raw message