This post has been edited. Much of the original text of this post is no longer valid.
From the comments and a post on the forums, it looks like this is no longer applicable. I ran a test this morning after seeing a comment by Eddie, a well skilled Certified MadCap Flare trainer, and the text of this original post is in fact, inaccurate. Eddie is right, my post is wrong. This is where the post is fundamentally inaccurate – to avoid using print mediums simply because it will create blank topics where all H1s occur. Attempt it, and nothing of that sort mentioned in the post about page breaks occur.
A little explanation is in order
When I made a decision to use a new print medium, much more than a year ago, with Flare v3, it was apparent then, from our testing, that a separate medium was always required to avoid page-breaks being inserted into topics when printed from the browser. I can still recall it very clearly. Getting feedback from users and running it myself as I attempted to print topics from Webhelp or CHM targets, always seeing print pages starting with one blank page first, usually with the breadcrumb proxy on its own page. Unfortunately, this is no longer reproducible. Not in Flare v4, I suspect, not in Flare v5 as well.
It was a heavily modified stylesheet that was reused from migrated legacy RoboHelp projects, into Flare v3, although in all honesty, I doubt that may have been the real reason. Months later, we rebuilt and cleaned the old stylesheet, replaced everything in ‘print’ in a medium called printOnly… mystery page breaks solved – then Flare 4 arrived…and Capture v4..which led to the seeds of this post, written more than a week ago (its a scheduled blog post). I think a few posts in the forums on an almost similar issue in the last few weeks started the germ of an article idea as well.
I guess a little redaction is in order, no?
I’ll keep the content of the original post, so you can see for yourself the inaccuracies laid bare. However, a discussion about considering multiple stylesheets and not use the print mediums for printed outputs might still be in order.
IMHO, I like to keep the stylesheet as clean as possible, that’s from experience, the less mediums I have to use the better, which is I think is the most popular, conventional thinking on the matter.
All the same, as time passes, and the more a stylesheet you create gets reused in your different projects, temptation to constantly overwrite your original master stylesheet will always be there, be it with Flare/Blaze’s Global Project Linking (or the more nifty, GPL acronym) enabled or not. Its not a tool issue. Its a user issue.
So why should you use the print medium?
You actually have more advantages to using the print medium than not in most cases. Here are some.
When you want:
- The convenience of switching to Print Layout view, and the medium switches immediately from (default) to print every time. You get to see it as it would be printed…always.
- When you want to take advantage of MadCap Capture’s image single-sourcing capabilities. You can create separate image rendering properties for all screenshots in print targets. No…You can’t do this with SnagIt. It lets you specify completely separate DPI and colour settings just for print outputs. Nice!
As the good Dr. House would probably do, for now, I’ve got a mystery to solve and no body to prove it.
How did those print page-breaks occur only in CHM and Webhelp?
If you do this, there is a high likelihood that when your readers decide to print a topic from an online target that you created in WebHelp or CHM, they will end up printing an empty page followed by the actual topic content. The empty page break is caused due to the use of page-break-before for the heading1(h1) when styling within the ‘print’ medium for print outputs.
So when an online topic, when printed from a browser, consistently starts with an empty page, it really is an avoidable waste of paper and a minor usability annoyance.
Solution – the page-break free version
Specify all your book/print styling information in an alternative user defined medium such as ‘printOnly’ or ‘bookOnly’, as long as it is not ‘print’. Reserve the print medium to fine tune topics printed from a browser.
How empty pages are created
The CSS ‘print’ medium is used by all web browsers to style an online page for print when you click Print.
To try this, in ‘print’ medium, set a new body font. In your online targets(CHM/WebHelp) click Print from the web browser’s toolbar. When the page is printed (or with Print Preview) your new fonts are applied. Similarly for the case of page breaks.
If you are single-sourcing your online projects to print as well, it is most likely that you, with most Flare authors, use a heading 1 (h1) with a page-break-before attribute enabled so that page breaks occur in all the right places.
Since most topics in online help will start with a heading 1(h1), the page break from h1, will be applied by the browser.
So what looks perfectly alright for printed books, but when a topic is printed from a browser, this results in an empty page followed by the topic on the next page.
Alternatives
Flare supports different approaches to accommodate different single-sourcing challenges. So if you choose to adjust to this workflow approach, you may need to accommodate changes in how you approach DPI management for image single-sourcing. For example, Capture with its dedicated Flare Print Format image property, relies on the assumption that the ‘print’ medium is used for all printed deliverables.
However, Flare/Blaze’s documentation does not recommend any single approach over any other approach.
References
This is still a good read. I am using this reference to build new stylesheet guidelines.
Flare Print Publishing, Stage 2: Defining Styles
Forum: Another recent forum topic on this article about print mediums.
Forum: Mediums vs Separate Stylesheets
Ellison Consulting – Generating Quality Print Output from Flare or Blaze
Roughly Everything about Flare 
Eddie VanArsdall
June 15, 2009
When I teach Flare classes, I recommend using the W3C-recommended media and not over-complicating the style sheet development process by creating custom media. Of course, some special cases may require a custom medium, but based on my experience, print is not one of them.
In my own work, I have always used only the Default and Print media. I have never used any custom style sheet media for printed output. In my style sheets, H1 Default sets the page-break-before property to “not set.” H1 Print sets it to “always.”
I have never encountered the empty page problem that you describe. In both WebHelp and .chm output, H1 and all body content appear on the same page when users click the Print button on the toolbar.
Are you using the Non-print medium, by any chance? If so, you may want to check what’s set in Default, Non-Print, and Print. Flare remembers that last medium that you were using when you closed your style sheet, so unintentionally applying styles to a specific medium is quite common. And the more media you create, the more likely the problem will occur.
Eddie
Writer In Training
June 15, 2009
Eddie,
Thank you!
I like using as much clean, compliant code as much as I possibly can.
It looks like you’re right on this. I did a quick test with H1s and page-breaks in the print medium; it still looks great, no empty pages. I think an update to this article is in order. I don’t have access to the original stylesheets that I tested on, more than a year ago, that caused me to enforce ‘this workaround’ then early in the project cycle. Nice though! Finally, I can use the Flare print format correctly now.
However, I am experimenting on a type of design where a print/book design has headings indented left by 100px(margin-left:-100px) outside of a Flare body layout frame. We’ve seen books like this I am sure. It looks like an alternate workaround may be in order.
Ryan Cerniglia
June 16, 2009
One of the best tricks I’ve picked up for when the print medium needs to cover several different outputs is to create and use multiple stylesheets that link to a main stylesheet.
To accomplish this, the main stylesheet is used exclusively for WebHelp, while additional stylesheets for PDF/FrameMaker/Word link to the main stylesheet. This allows me to do a lot of per-output customization while still being able to utilize single-sourcing practices.
This also allows me to pull off some advanced behaviors, such as different table-styles per output (grayscale colours for WebHelp-print & PDF to print, full color for WebHelp-online, Word, & Online PDF).
— RC
Paul Pehrson
June 15, 2009
I have a similar issue in print. My body frame is set to a specific width, and I sometimes “outdent” headings by several inches. When users printed these topics from the WebHelp, they lost the first part of all the outdented headings.
I’ve solved this in my project by creating separate style sheets, as described below.
In my own Flare projects, I usually create two separate style sheets. “style.css” is the basic style sheet and is used for online styles. “print.css” is the style sheet that is only used for print targets.
At the beginning of my print.css style, I use the @import command to import the contents of the style.css, so I have all the basic web styles in the sheet, then I can override them as needed for my pirnted output.
This gives me two important benefits: First, when I publish to Web, I conditionally exclude the print.css style sheet, so those styles aren’t even included in the otuput.
Second, it makes it so I can create custom print settings for when people print the online help, but these don’t affect the print.css, because I can override them there.
This has worked pretty good for me. I have a web(online) style, a printed-from-web style and a printed-to-pdf style, all using just the @print section, and using two style sheets.