Madcap Dropdown Overrides Page-break-after

[GaryUK]

I often have lines in my lists that end in a colon to show that something (a picture, for example) is to follow. Left to their own devices, they often end up at the end of a page in printed output, with the picture on the next page.

To keep the line together with the picture on the next page, I created an li style called li.keepwithnext (with page-break-after set to avoid).

It works beautifully until I put the whole thing into a MadCapDropdown for online output purposes. The dropdown container seems to disregard the page-break-before in printed output.

Does anyone have any ideas on how to overcome this?

[Msquared]

I've found and reported several formatting issues with drop-downs. Based on my experience, I'd say this is very likely to be a bug, so I'd get on and report it as such.

You may find that you have more success wrapping anything you want to keep together in a div. I use this (not just in drop-downs):

div.KeepTogether
{
page-break-inside: avoid;
}

I've found that drop-downs sometimes behave slightly better if you wrap all the body content in a div anyway, so you may find that doing that is enough to frighten Flare into obeying your formatting instructions on the .li style anyway. I'd be interested to know if that is the case.

[GaryUK]

Thanks for the suggestion, Marjorie. Unfortunately, no luck.

I tried just a regular div and then a KeepTogether div. My ol container also has page-break-inside avoid. Nothing made any difference.

I'll log it

Love your by-line by the way.

[GaryUK]

This has been driving me crazy and there is no sign of it being fixed.

So, for anyone else who cares about pagination, I am doing this workaround:

After I have created a dropdown, I conditionalise the MadCap:dropDown component (I know, it's supposed to be single-sourcing!) with an unbind action rather than a remove. This condition is excluded from any printed targets.

Thankfully, my dropdown content and background icon are retained in print, but the margin is ignored, so it touches the previous and following paragraphs. To overcome this, I had to change the print medium of the style sheet to add it back to the top of the MadCap:dropDownHead and the bottom of the MadCap:dropDownBody. The fun starts when the dropdown is already conditionalised with a remove action. Then you have to put it all in a div and conditionalise that.

I thought of creating a "seed" snippet for this but so often I find it is easier to change the instructions into a dropdown than it is to type instructions into a prepared container. Very often you don't know it's going to be a dropdown until it gets too big.

So far so good, but it seems so much work for nothing. When I recommended Flare I harped on about how you can put things in dropdowns and they will just print in the printed output. More fool, me.

If there are any other pagination purists out there with the same problem, please log another bug (they tried to tell me it was an enhancement).

Despite how it sounds, I really do love Flare.

[Msquared]

MadCap did eventually acknowledge the fact that text in drop-downs paginate poorly as a bug. But I've just checked my records and it turns out that they never gave me a bug number, although I do have bug numbers for all the other issues I raised against drop-downs in PDFs.

Initially they told me that it wasn't a bug because they couldn't reproduce it in a clean project - they could only reproduce it in the project that I sent them.

[GaryUK]

I definitely have a bug number, so they do know about it.