xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Art Welch <ar...@EASTPOINT.COM>
Subject RE: Scaling of images
Date Mon, 04 Dec 2000 22:55:28 GMT
I have not looked recently, but I do not think that block-container is fully
implemented. Last time I looked it always reported an OK status regardless
of what it's contents did. This would explain why the image does not display
when it overflows. The image overflows so is not rendered. Block container
just returns OK, so there is no indication that the image needs to be
rendered somewhere else. In a table the scaling logic may be hitting the
image without regard to the block container.

Anyway, block-container is listed as not implemented on the FOP features
page so you should be very careful when using it. I have used
block-container myself specifically to take advantage of it's always
successful result behavior (to prevent overflow). I do not think that it
should be necessary to place images in a block-container.

Art

-----Original Message-----
From: Fotis Jannidis [mailto:fotis.jannidis@lrz.uni-muenchen.de]
Sent: Monday, December 04, 2000 5:23 PM
To: fop-dev@xml.apache.org
Subject: Re: Scaling of images


From:           	Charles Palmer <charles@dspdesign.com>

> I've been messing around trying to put images into a document. I
> seem to have found experimentally that: 
> 
> (1) placing an image into a fo:block-container that is too small
> results in the image not being rendered (no error message is
> generated). 

this is a bug. The desired behaviour would be, either that the image 
is clipped to the available space or that it overflows. We can decide 
which one we want to use, because default value for "overflow" is 
"auto": 
"The behavior of the "auto" value is user agent dependent,
but should cause a scrolling mechanism to be provided for 
overflowing boxes." (Mmh, it is certainly difficult to write a media 
independent specification which doesn't make some assumptions 
about the medium) 

> (2) placing the same block-container inside a table cell results
> in the image being scaled to fit the cell. 

I haven't studied the table section thoroughly, but scaling the image 
automatically is afaik not the thing to do. If content-height is not set, 
its value is "auto" and that means: take the intrinsic height. 
 
> Suggestion: If it is expected then is it sensible to print a
> warning message if the image is not rendered? (I note that if I
> have a leader which is too long to fit in a table cell then I get
> a warning message telling me it is being truncated.) 

It sets "auto" for overflow to the value "error-if-overflow"; maybe we 
should handle this uniformly in Fop and document it. But I have to 
admit: clipping a leader is much easier than a image. 

Fotis

Mime
View raw message