I just completed a Flare project that was primarily an online presentation, and secondarily, a printed handout. So once the online aspect of the project was done, I moved on to the print CSS.

I had a nifty three column design that I had built with nested div tags and some CSS3 (rounded corners, gradients, and multiple background images) and I realized early on that the three column design, shown here, wasn’t going to fly in print.

So I turned the horizontal layout in to a vertical one but, to make sure sections began and ended properly on a page, I needed to create a page-break done via a <p.page_break> tag that is assigned the Print Only condition tag. Why? I’ll explain:

First, a <p> tag is relatively unobtrusive…and with the styling I’m going to apply it going to be even more so.

Second, since you are adding a <p> tag to the code, you are changing the spacing/layout/look of your online help so adding a Print Only condition tag is smart.

So, I created a <p> tag with the style class “page_break.” Here’s the CSS for this tag:

p.page_break
{
font-size: 5pt;
line-height: 7pt;
page-break-before: always;
padding-bottom: 0px;
padding-top: 0px;
padding-left: 0px;
padding-right: 0px;
margin: 0;
}

Notice that I minimized the font size and the line-height, removed the padding (My default <p> tag has all of those styles set differently).

And the trick to break the page is to set ‘page-break-before’  to always.

Insert this <p> tag wherever you want the page to break. Then, apply the Print Only condition tag. You should do this since you don’t want this tag rendered in your online output.

Note that I set ‘display’ to hidden as an experiment.

It looks like this in the XML Editor:

Here’s what the page looked like before:

I could not leave two bullets alone on the next page…and to make matters worse, the gradient and border from the container <div> is repeated. UGH.

So, <p.page_break> to the rescue. Why didn’t I use the widows/orphans setting in Flare? you ask. I did…but I’ve never been able to successfully use that style with satisfactory results.

I inserted the p.page_break above the second set of bullets, moving the entire bulleted list to the next page. It’s beautiful…no more lonely, gradient-covered bullets.

So, if you ever need a page break somewhere in your printed output – here’s a quick way to make it happen in Flare.

Wow, it’s been too long since I’ve posted. I’m sorry for that. I’m back now…tan, rested, and ready.

When Flare v7.1 came out recently, I noticed a new checkbox in the Advanced tab of the Webhelp target (We won’t discuss how pathetic I am that I noticed a new checkbox):

I’ll admit, I was excited about it. This would allow me to exclude all the topics that I decided not to use in output: old versions, bad topics that were discarded but never deleted, etc.

Why was I excited? Because before that checkbox, if I left those topics as is, meaning in the project but not in a TOC, they would still be included in a build. This was BAD because every time I left unused topics in my project, the test team would inevitably find them through testing the Search feature in my help project. Grrrrrr….

So, I learned to use conditional tags with abandon. For webhelp project, the Print Only tag became a close friend. Setting those unused topics to Print Only was a quick solution to a nagging problem.

Now, if you’re building print output as well – DON’T DO THIS. Create a new condition tag (maybe called ‘not being used’) and use it liberally.

With Flare v7.1, I thought I was free from what was somewhat annoying: applying a conditional tag to all unused topics. So, I checked the box! I was soooo excited! I built my project, published it to the test server, and waited for the brilliance of the help system to shine through during testing.

Except it didn’t turn out that way at all. The test team logged a Critical bug against my help! What?! The majority of my Context-Sensitive Help tags were broken. Huh? How could that be? They worked yesterday?!

Well, the culprit, it turns out, was that blasted checkbox! I had many CSH tags that were topics independent of the others and not used in the TOC. In other words, they were topics that simply defined a field and weren’t really appropriate for the TOC. So, clicking that checkbox resulted in all of those topics being tossed out of the build, thereby breaking my CSH tags.

It almost goes without saying: I quickly unchecked that checkbox.

The lesson here: be careful what you wish for and BEWARE the Power of a Checkbox.