Hi, Keiron

OK, I'll buy all of this. I need to get used to the idea that we are
actually doing viewports. :-) That changes things. :-)

With viewports being used then the ImageArea becomes a relatively
unimportant thing. Except right at the beginning, where odds are pretty good
that the author will set "auto" for block- and inline-progression-dimension
(that is, not set those at all, nor 'height' and 'width'), and therefore in
conjunction with 'content-width', 'content-height', and scaling we'll have
to figure out the content size so the _viewport_ can get this for itself.
But afterwards nobody should care about the image itself except for the
renderer. And in the case that BPD and IPD are both explicitly set on the
viewport then layout will _never_ care about the actual image.

So I don't disagree, although I'd get pedantic and point out that, yes,
we're setting _a_ size  on the viewport, but that is not necessarily the
size of the image. But layout doesn't care - it only cares about the size of
the viewport.

Using the URL as a cache key clears other things up, too. Thanks.

Is it safe to assume that when we refer to the "image" being in cache, and
being retrieved from cache with the URL, etc etc, that _this_ image is the
FopAbstractImage or an advanced version of same?


-----Original Message-----
From: Keiron Liddle [mailto:[EMAIL PROTECTED]]
Sent: March 18, 2002 4:22 AM
Subject: Re: Image Handling Question

Hi Arved,

There are a couple of reasons that it only has a URL.
If the page is going to be serialized we don't want to serialize an image.
There is no advantage to having a reference to the image and it would make
it harder to keep track of references for caching.
The URL is used as a key to get the image from the cache. The only problem
with this is if someone decides to use two syntactily different URL's for
the same image, which I am guessing is rare.

As for the size, since the image is inside a viewport I was thinking of
setting the size and position in the viewport. There are other objects
that can be in the viewport that need the same things.

So in the FOTree it only grabs the image (using the URL) if the size of
the image is needed. The image is then in the cache with the URL as the
key. When the renderer comes to render the image it grabs the image again
and draws it. In the case of the PDF Renderer it no longer needs the
original image in the cache so it releases the image. The image is then
available as a PDF Object.


On 2002.03.17 18:38 Arved Sandstrom wrote:
> Keiron or Karen,
> I have a quick question. This is mostly because I am unfamiliar with the
> code. As it stands right now org.apache.fop.area.inline.ImageArea does
> not
> look like something that the layout process can use; it also doesn't look
> like something that the renderer can use because it supplies only a URL
> reference, not any extra information as to what changes (e.g. scaling)
> may
> have taken place.
> So is it the case that org.apache.fop.image.AbstractFopImage (or
> something
> like it) is the primary object to be used in layout? And I'm thinking
> that if
> this is the case, that the ImageArea class should not have a reference to
> a
> URL, but rather to the AbstractFopImage.
> Am I missing something here? I am going to continue on with research - I
> have
> plenty of serious reading and code review ahead of me, I can see. I
> wanted to
> ask about _this_ to maybe speed things up with image handling.
> Regards,
> Arved

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to