I'm having an issue when I place a floated image in a block of text. I've been successful in using the 'page-break-inside: avoid;' style to prevent the image from being split up across the page break, but I'm having an issue with the surrounding text.

I've attached a PDF that highlights the issue (look at what happens at the first page break), and the JSP that was used to generate the PDF.

What I'm trying to accomplish is:
1) If an image is pushed to the next page, then the text should flow in above it.
2) The text should never be repeated. Take a look at 'Entered Oct 26, 2010 ...'. It appears both at the bottom of page 1 and at the top of page 2.

Any help would be greatly appreciated.

Thanks,
Steph.

We are paying for a Pro license (v 360fx1b1 Pro). Could someone from PDML please respond.

Steph.

Steph,

it is an implicit page break issue. We've been checking if it is possible to implement a fix. (it is quite tricky: PD4ML prints floats after the main content, so a page break "signal" comes from a float too late - when a portion of a text, supposed to go to the next page, is already printed on the current one).

As a workaround I would recommend to add a conditional page break tag between <div>s:

...
		</div>
	</div>

	<pd4ml:page.break ifSpaceBelowLessThan=300>

	<div class="Entry" style="...">
		<img class="Image"
...

where "300" more-less matches the image height.

Thanks for the reply. I've tried the work-around and it gets me past my second issue, but I'd still like to see a solution to my first problem as we need to minimize the amount of whitespace in our document. Our customers will be paying to professionally print the content, so needless white space increases the size of the document which drives up printing costs.

Could you let me know what version I might expect to see a code fix in, and what the timeline for that might be?

Thanks,
Steph.

For the time being there is no workaround.

HTML-to-PDF conversion process consists of 2 phases: Initially PD4ML renders HTML document layout for a "screen device", whose height is unlimited. At this point page breaks are not taken into account. After that the rendered content is "printed" to PDF output device (or Image device, or RTF device etc) and depending on a particular output media nature and dimensions, page breaks (or "page-break-inside: avoid" directives) applied.

What you actually need is to reflow the text depending on an actual image position, and the actual image position depends on a page break position. So during the phase 1 we need a position info, which will be known only during the phase 2. That is a very big challenge to the current PD4ML architecture and we are even not ready to estimate needed efforts yet.