Re: FOP - external-graphic in absolutely positioned block container - increase the width and the image vanishes!
Mike Trotman wrote: But the behaviour in FOP seems to be that containing width (not the external-graphic @width) restricts image display size, Correct. 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. 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(?). 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP - external-graphic in absolutely positioned block container - increase the width and the image vanishes!
J.Pietschmann wrote: Mike Trotman wrote: 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 38 39 40 41 XbeforeX 42 43 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. 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). - 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 => calculate scale to achieve absolute size (?) 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP - external-graphic in absolutely positioned block container - increase the width and the image vanishes!
Mike Trotman wrote: 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 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. - 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP - external-graphic in absolutely positioned block container - increase the width and the image vanishes!
J.Pietschmann wrote: Roland Neilands wrote: 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. 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? J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP - external-graphic in absolutely positioned block container - increase the width and the image vanishes!
Roland Neilands wrote: 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: FOP - external-graphic in absolutely positioned block container - increase the width and the image vanishes!
Mike, > 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? 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP - external-graphic in absolutely positioned block container - increase the width and the image vanishes!
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? [EMAIL PROTECTED] wrote: 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! 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. 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. 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? (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! FWIW Jay Bryant Bryant Communication Services (presently consulting at Synergistic Solution Technologies) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
