xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Fotis Jannidis" <fotis.janni...@lrz.uni-muenchen.de>
Subject Re: Scaling of images
Date Mon, 04 Dec 2000 22:23:01 GMT
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