Discussion:
FOP - external-graphic in absolutely positioned block container.
Mike Trotman
2005-04-18 19:03:51 UTC
Permalink
I have what seems like some weird inconsistent when trying to use
block-container to absolutely position a graphic.
(This is often a sign that one is doing something stupid - and a fresh
pair of eyes can help.)

The code below works OK (at least it shows the graphic - I still have to
adjust the size properly use consistent and proper units).

37 <fo:static-content flow-name="xsl-region-before">
38 <fo:block-container position="absolute" top="0cm" left="0.0cm"
height="20.5cm" width="28cm" border="1px solid silver"/>
39 <fo:block-container position='absolute' top='3cm' left='3cm'
height='3in' width='2in' border='3px solid blue'>
40 <fo:block><fo:external-graphic src='url(images/img_2.jpg)'
content-height='0.5in' content-width='0.5in'/> </fo:block>
41 <fo:block text-align='right' color='red'
background-color='yellow'>XbeforeX</fo:block>
42 </fo:block-container>
43 </fo:static-content>
44

However if I INCREASE the width of the block-container in line 39 to 2.5in

39 <fo:block-container position='absolute' top='3cm' left='3cm'
height='3in' width='2.5in' border='3px solid blue'>

then the image is NOT displayed!
It is as if it was never there - i.e. the next block is displayed as the
1st line.

Does anyone have any clue as to why this is happening - or what I am
doing wrong?

Mike

P.S. I've also encountered some non-intuitive positioning behaviour when
using xsl-region-end or xsl-region-after.

The origins for absolute position seem to be relative to the top LH
corner of the relevant region.
(at least with the extents I am using.)

Is this correct behaviour?

E.g.
To get something on the visible page in xsl-region-afterr you have to
specify a 'top' value < 0.

<fo:static-content flow-name='xsl-region-after'>
<fo:block-container position='absolute' top='-16cm' left='2cm'
height='3in' width='2in' border='3px solid yellow'>
<fo:block><fo:external-graphic src='url(img_2.jpg)'
content-height='1.5in' content-width='1.5in'/> </fo:block>
<fo:block text-align='right' color='yellow'>after</fo:block>
</fo:block-container>
</fo:static-content>
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.9.16 - Release Date: 18/04/2005
J***@s-s-t.com
2005-04-18 19:29:20 UTC
Permalink
The first block container's width is approximately 11 inches, and it's
height is approximately 8 inches. Did you mean to make a landscape
presentation? If so, is the rest of the FO file set up for it?

Also, the first block container has no content. I guess it's there to draw
a border around the page. If someone prints the document on the average
office printer, the border won't print, since it will be in the printer's
"dead spot".

As for your region-after problem, try it without the block container. I
never use block containers, and I never need to set negative values on
margins to get anything to appear. In fact, you might try the whole thing
without the block containers.

(If it were me, I'd also make the units of measure and quotation marks be
consistent, but I'm fussy about such things.)

FWIW

Jay Bryant
Bryant Communication Services
(presently consulting at Synergistic Solution Technologies)
Mike Trotman
2005-04-18 20:59:50 UTC
Permalink
Thanks for the comments on the other parts of my example.

However - my main question still remains:

Why - when an image is displayed 'correctly' - does making the
block-container BIGGER make the image vanish?
Does anyone else have any experience of this?
Post by J***@s-s-t.com
The first block container's width is approximately 11 inches, and it's
height is approximately 8 inches. Did you mean to make a landscape
presentation? If so, is the rest of the FO file set up for it?
All my output is landscape.

Yes - everything works - this is from a XSLT->FO transformation I have
been using successfully for 3 years.
I just had a sudden surprise when all my logos suddenly vanished after
changing the page size slightly!
Post by J***@s-s-t.com
Also, the first block container has no content. I guess it's there to draw
a border around the page. If someone prints the document on the average
office printer, the border won't print, since it will be in the printer's
"dead spot".
Yes - I'm putting a border round a landscape page - this is purely for
PDF output with no printing.
Post by J***@s-s-t.com
As for your region-after problem, try it without the block container. I
never use block containers, and I never need to set negative values on
The negative value example was not for the margin - it was for the
position of the fo:block-container.

I mentioned it because RenderX XEP uses absolute postioning relative to
the page (or region-body?)
for all xsl-regions - and so behaves differently from FOP (no negative
values needed).
But I wasn't sure from the W3C specification which was the expected
behaviour as I couldn't work out what were the relevant containing areas.
Post by J***@s-s-t.com
margins to get anything to appear. In fact, you might try the whole thing
without the block containers.
I think I have to use fo:block-container - as fo:block can't take
absolute position properties?
Post by J***@s-s-t.com
(If it were me, I'd also make the units of measure and quotation marks be
consistent, but I'm fussy about such things.)
- yes it does need units etc.tidying up.
I am just trying to add an image - and have been trying various
experiments over a few days.
I've been copying and editing other bits that work in other places to
try anddiagnose my original problem
which was that my logos suddenly vanished!
Post by J***@s-s-t.com
FWIW
Jay Bryant
Bryant Communication Services
(presently consulting at Synergistic Solution Technologies)
---------------------------------------------------------------------
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.9.16 - Release Date: 18/04/2005
Roland Neilands
2005-04-18 22:54:44 UTC
Permalink
Mike,
Post by Mike Trotman
Why - when an image is displayed 'correctly' - does making the
block-container BIGGER make the image vanish?
Does anyone else have any experience of this?
Yes, if the block-container no longer fits wholly within static-content for example, it doesn't display anything. You could display
borders on the block-container to check.

I have also seen logos disappear when the logo itself was much bigger than the block-container and it spat the dummy rather than
scale the image down. I think that was only on certain image types (jpg?). I checked the archives quickly but can't find the
details, sorry.

Cheers,
Roland
Mike Trotman
2005-04-19 00:24:01 UTC
Permalink
Thanks for checking the archives.
I also did a quick scan but couldn't find anything.

I think I have pinned down when the image vanishes.
It is when both dimensions of the image display size are too large to
fit in the box.

With a smaller width - the image is constrained in the box by width -
and the height is smaller than the box.
When I increase the width - the image expands to fill the width - and
the bottom of the image gets closer to the bottom of the box.
When I go beyond to the point where the image height exceeds the box -
then the image vanishes!

At 2.3in width - the image displays and just fills the box, at 2.4in the
image does not display as it's height would be larger than the box.
And I increased my sizes by 0.5in which allowed the image to expand and
vanish!

SO - an image IS constrained by the WIDTH of a box - but NOT the HEIGHT!
(And an image display that is too large to fit the box gets suppressed.)

I was using content-height and content-width as these correctly
constrain the image in XEP (height and width don't)
and obviously using the size of the block-container to constrain the
size in FOP.
But it was too long ago when I set this up.
I have now added a large comment to the relevant XSLT code.

Anyway - thanks to all those who responded.


Mike
Post by Roland Neilands
Mike,
Post by Mike Trotman
Why - when an image is displayed 'correctly' - does making the
block-container BIGGER make the image vanish?
Does anyone else have any experience of this?
Yes, if the block-container no longer fits wholly within static-content for example, it doesn't display anything. You could display
borders on the block-container to check.
I have also seen logos disappear when the logo itself was much bigger than the block-container and it spat the dummy rather than
scale the image down. I think that was only on certain image types (jpg?). I checked the archives quickly but can't find the
details, sorry.
Cheers,
Roland
---------------------------------------------------------------------
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.9.16 - Release Date: 18/04/2005
Roland Neilands
2005-04-19 00:35:28 UTC
Permalink
Mike,

That's interesting, and possibly consistent with what I saw. I'll test that when I get a chance.
Have you tried setting height &/or width (use scaling="uniform" if both) attributes on the external-graphic itself?

Cheers,
Roland
-----Original Message-----
Sent: Tuesday, 19 April 2005 10:24 AM
Subject: Re: FOP - external-graphic in absolutely positioned block
container - Solved
Thanks for checking the archives.
I also did a quick scan but couldn't find anything.
I think I have pinned down when the image vanishes.
It is when both dimensions of the image display size are too large to
fit in the box.
With a smaller width - the image is constrained in the box by width -
and the height is smaller than the box.
When I increase the width - the image expands to fill the width - and
the bottom of the image gets closer to the bottom of the box.
When I go beyond to the point where the image height exceeds the box -
then the image vanishes!
At 2.3in width - the image displays and just fills the box, at 2.4in the
image does not display as it's height would be larger than the box.
And I increased my sizes by 0.5in which allowed the image to expand and
vanish!
SO - an image IS constrained by the WIDTH of a box - but NOT the HEIGHT!
(And an image display that is too large to fit the box gets suppressed.)
I was using content-height and content-width as these correctly
constrain the image in XEP (height and width don't)
and obviously using the size of the block-container to constrain the
size in FOP.
But it was too long ago when I set this up.
I have now added a large comment to the relevant XSLT code.
Anyway - thanks to all those who responded.
Mike
Post by Roland Neilands
Mike,
Post by Mike Trotman
Why - when an image is displayed 'correctly' - does making the
block-container BIGGER make the image vanish?
Does anyone else have any experience of this?
Yes, if the block-container no longer fits wholly within static-content for example, it doesn't display anything. You
could display
Post by Roland Neilands
borders on the block-container to check.
I have also seen logos disappear when the logo itself was much bigger than the block-container and it spat the dummy rather than
scale the image down. I think that was only on certain image types (jpg?). I checked the archives quickly but can't find the
details, sorry.
Cheers,
Roland
---------------------------------------------------------------------
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.9.16 - Release Date: 18/04/2005
---------------------------------------------------------------------
Mike Trotman
2005-04-19 00:56:15 UTC
Permalink
Hi Roland.

Yes - I've tried height and width on the fo:external graphic - and they
do control the size in FOP - but not in XEP (3.8).

In XEP these set the height and width of the region for the fo:external
graphic area - but the image can spill outside this region - which is
why content-height and content-width are needed.

I'm assuming that - as this is the case - the scaling attribute is
supposed to apply to the content-h/w attributes?

I haven't tried this in FOP with scaling specified as well - but I'm
trying to come up with something that behaves the same in both XEP and
FOP at the moment.


Mike
Post by Roland Neilands
Mike,
That's interesting, and possibly consistent with what I saw. I'll test that when I get a chance.
Have you tried setting height &/or width (use scaling="uniform" if both) attributes on the external-graphic itself?
Cheers,
Roland
-----Original Message-----
Sent: Tuesday, 19 April 2005 10:24 AM
Subject: Re: FOP - external-graphic in absolutely positioned block
container - Solved
Thanks for checking the archives.
I also did a quick scan but couldn't find anything.
I think I have pinned down when the image vanishes.
It is when both dimensions of the image display size are too large to
fit in the box.
With a smaller width - the image is constrained in the box by width -
and the height is smaller than the box.
When I increase the width - the image expands to fill the width - and
the bottom of the image gets closer to the bottom of the box.
When I go beyond to the point where the image height exceeds the box -
then the image vanishes!
At 2.3in width - the image displays and just fills the box, at 2.4in the
image does not display as it's height would be larger than the box.
And I increased my sizes by 0.5in which allowed the image to expand and
vanish!
SO - an image IS constrained by the WIDTH of a box - but NOT the HEIGHT!
(And an image display that is too large to fit the box gets suppressed.)
I was using content-height and content-width as these correctly
constrain the image in XEP (height and width don't)
and obviously using the size of the block-container to constrain the
size in FOP.
But it was too long ago when I set this up.
I have now added a large comment to the relevant XSLT code.
Anyway - thanks to all those who responded.
Mike
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.9.16 - Release Date: 18/04/2005
J.Pietschmann
2005-04-19 19:46:56 UTC
Permalink
Post by Roland Neilands
I have also seen logos disappear when the logo itself was much bigger
than the block-container and it spat the dummy rather than scale the
image down. I think that was only on certain image types (jpg?).
IIRC the image scaling code uses the available space in the page
body as the maximum heigth of the image, regardless whether the
image is actually placed in static content. The static content is
processed after the flow in the body, and if the current page has
been completely filled, images in static content may be scaled down
to zero or nearly zero height. That's why it is always a good idea
to provide width and height for images explicitly.

J.Pietschmann
Mike Trotman
2005-04-20 10:47:59 UTC
Permalink
Post by J.Pietschmann
Post by Roland Neilands
I have also seen logos disappear when the logo itself was much bigger
than the block-container and it spat the dummy rather than scale the
image down. I think that was only on certain image types (jpg?).
IIRC the image scaling code uses the available space in the page
body as the maximum heigth of the image, regardless whether the
image is actually placed in static content. The static content is
processed after the flow in the body, and if the current page has
been completely filled, images in static content may be scaled down
to zero or nearly zero height. That's why it is always a good idea
From my recent experiments, using absolutely positioned block-containers,
I think the image is scaled so that the width is the maximum width of
the image
but the height is not constrained (though uniformly scaled).
So - if your width allows an image size whose height is bigger than the
container
then the image is not displayed.
Post by J.Pietschmann
to provide width and height for images explicitly.
I think this is a FOP specific fix (which works in FOP - but not in
other XSLFO processors).
Unfortunately the height and width attributes are to specify the size of
the external-graphic area
which the image is allowed to exceed - which is where content-height and
content-width come into play?
Post by J.Pietschmann
J.Pietschmann
---------------------------------------------------------------------
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.9.18 - Release Date: 19/04/2005
J.Pietschmann
2005-04-20 20:32:44 UTC
Permalink
Post by Mike Trotman
From my recent experiments, using absolutely positioned block-containers,
I think the image is scaled so that the width is the maximum width of
the image
but the height is not constrained (though uniformly scaled).
I don't think so. Have a look at the code in
..../fo/flow/ExternalGraphic.java
Post by Mike Trotman
Unfortunately the height and width attributes are to specify the size of
the external-graphic area
which the image is allowed to exceed
Not in the FOP implementation. It may overflow the parent area though.
Post by Mike Trotman
- which is where content-height and
content-width come into play?
I always thought the use case for the content-width|height properties
is for specifying percentages, e.g. content-width="50%" will scale
a 4cm wide image down to a 2 cm wide. This is still tricky for bitmap
images without an embedded resolution.

J.Pietschmann
Mike Trotman
2005-04-20 22:19:43 UTC
Permalink
Post by J.Pietschmann
Post by Mike Trotman
From my recent experiments, using absolutely positioned
block-containers,
I think the image is scaled so that the width is the maximum width of
the image
but the height is not constrained (though uniformly scaled).
I don't think so. Have a look at the code in
..../fo/flow/ExternalGraphic.java
I'm afraid I've only got a binary version of FOP installed - so no
source to look at - and my Java is very elementary.

I'm referring to the width / height of the containing block-container
and may not have phrased it clearly.
But the behaviour in FOP seems to be that containing width (not the
external-graphic @width) restricts image display size, but height doesn't.
(If this isn't what the previous message was about then I've got hold of
the wrong idea and you can ignore the rest of this message.)

I'm basing my comments on the behaviour of this piece of XSL:FO.

37 <fo:static-content flow-name="xsl-region-before">
38 <fo:block-container position="absolute" top="0cm" left="0.0cm"
height="20.5cm" width="28cm" border="1px solid silver"/>

39 <fo:block-container position='absolute' top='3cm' left='3cm'
height='3in' width='2in' border='3px solid blue'>

40 <fo:block><fo:external-graphic src='url(images/img_2.jpg)'
content-height='0.5in' content-width='0.5in'/> </fo:block>
41 <fo:block text-align='right' color='red'
background-color='yellow'>XbeforeX</fo:block>

42 </fo:block-container>
43 </fo:static-content>

This displays the image inside the block-container while the width on
line 39 is < 2.3in (for this particular image).
And as I increase the width upwards to 2.3in the image gets larger and
larger
filling the full width of the bock-container but with an ever decreasing
gap at the bottom
As soon as the displayed image height exceeds the height of the
block-container the image is suppressed.
Post by J.Pietschmann
Post by Mike Trotman
Unfortunately the height and width attributes are to specify the size
of the external-graphic area
which the image is allowed to exceed
Not in the FOP implementation. It may overflow the parent area though.
As you say - in FOP the @height and @width on external-graphic do
control the size of the image - and this may exceed the parent area.

But as I read the spec the external-graphic @height sets the height of
the box - but the content may exceed this area(?).
I may have got my interpretation of which areas the spec is talking
about wrong - although XEP seems to implement them this way.

I've only completely read the spec once or twice and usually only refer
back when something is not behaving as I expect (which happens quite often!)

e.g. when I run the above code through XEP the @content-height/width
control the size of the image.
If I change these external-graphic attributes to plain @height/width
(with no @content-height/width)
then the image (which is large) expands well outside the block and
block-container
but the text in line 41 is positioned under a block which has the
specified @height of the external-graphic (and across the front of the
image).
Post by J.Pietschmann
Post by Mike Trotman
- which is where content-height and content-width come into play?
I always thought the use case for the content-width|height properties
is for specifying percentages, e.g. content-width="50%" will scale
a 4cm wide image down to a 2 cm wide. This is still tricky for bitmap
images without an embedded resolution.
I'm basing my comments partly on reading the spec. (but not being clear
what are the relevant containing areas)
and also on the behaviour of the output in XEP.

@Content-height/width can have % or length values.

% => scale from the image dimensions
<length>=> calculate scale to achieve absolute size (?)
Post by J.Pietschmann
J.Pietschmann
Again - apologies if we're talking at cross-purposes.
I'm no expert at XSLFO - particulalry vague on the behaviour of areas
and inherited traits
and have spent quite a bit of time getting myself confused, unconfused
and then confused again by the W3C spec. and the behaviour of various
formatters.
Post by J.Pietschmann
---------------------------------------------------------------------
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.9.18 - Release Date: 19/04/2005
J.Pietschmann
2005-04-27 21:34:25 UTC
Permalink
Post by Mike Trotman
But the behaviour in FOP seems to be that containing width (not the
Correct.
Post by Mike Trotman
but height doesn't.
Clipped by the MaxHeight of the region-body, whatever this is (probably
not the available height as I claimed before, which would explain the
complaints about images overlapping the footer). The code tries to
keep the aspect ratio but may have some difficulties if either width
or height are explicitely specified and clipping applies.
Post by Mike Trotman
control the size of the image - and this may exceed the parent area.
the box - but the content may exceed this area(?).
This is most likely the correct interpretation. The spec is somewhat
unclear about what should if the content-width/height are missing
and how this all releates to image dimensions derived from the image
data itself.

J.Pietschmann

Loading...