Topic printing from Flare covers header text

[Dinnit]

How can I control the print output from Flare itself - i.e. that which uses the Print button?

Any print output using my Page Layouts are fine but printing direct from Flare when a topic covers more than one page results in the topic text printing on top of the heading and breadcrumbs on any page other than the first. I'm using a non-scrolling header. As the Print targets work fine I'm assuming that the css doesn't need changing - or does something in the default Madcap Skins Topic stylesheet automatically generated with the output need changing?

[Daniel Ferguson]

The printed output from the Print button uses the same stylesheet as the HTML. You can, however, create an "@media print" section in your stylesheet that defines the styles that should be used when someone presses the print button. As such, you have control over how the printed output displays. Styles that aren't explicitly defined in the @media print section will default to the regular styles that you have defined in your stylesheet.

Flare will automatically create an @media print section in your stylesheet when you change the medium to "Print" when editing your stylesheet.

Hope this helps.

[Dinnit]

Hi Daniel
Thanks for this but I'm still puzzling. I have always used the print medium to set up my normal print outputs (usually pdf) and they are fine, but I still don't get what is governing the print output when printing direct from a WebHelp page.

Is it using a Page Layout for that? Printing from the unaltered Madcap WebPrintMobile test project produces a blank (except for the breadcrumbs) first page with the text starting on the second. Which seems to indicate that the Body Proxy is being shifted to the 2nd page somehow...? so now I'm even more confused

[LTinker68]

... but I still don't get what is governing the print output when printing direct from a WebHelp page... Is it using a Page Layout for that?

The problem is you're confusing the purpose of the print medium, but that's in part because Flare defaults to the print medium for print output, which is not always the best thing to do.

The print medium was added to CSS as a way to control the appearance of a web page when it's printed from a browser. Any time you print from a web page, regardless if it's a Flare help site or not, the browser will look for a print medium in the site's stylesheet or inline styles. (The print medium is a CSS convention, not a Flare one.) So the print medium in the stylesheet itself has nothing to do with the Flare print outputs, at least not from the stylesheet's point of view. The Flare print targets point to the print medium, by default, but you could change it to point to the default medium or to a new medium that you create in the stylesheet. The print targets are only looking for the medium it should look for to determine how the content looks when it's merged with the page layout at build time.

In other words, printing from a web page has nothing to do with Flare's page layouts. The page layouts aren't even in the online output. So if you're trying to making printing from a web page look like printing a page from your PDF output, it's not going to happen.

You can control how a web page's printed page looks via the print medium, so you can add backgrounds to elements, add decorative DIVs, etc. If you do that, then I recommend creating a new medium to use with PDF outputs, because some of the more advanced CSS effects for printing from the web won't work or may cause problems with the PDF output. I create a medium called printPDF, for example, to differentiate styles for PDF outputs versus printing from the web.

[Dinnit]

Thanks Lisa - that's helpful. Thought page layouts were nothing to do with webpage printing but got desperate.
Had got rid of the H1 for printing by using the print medium for now. Wrestling with cutting out the breadcrumbs now but not having much luck.

[LTinker68]

Wrestling with cutting out the breadcrumbs now but not having much luck.

In the print medium, set the breadcrumbProxy's display attribute to none. That should prevent it from being shown when printing from a website and should have no effect when generating PDF output, since Flare is already set up to not include breadcrumbs in print output.

[Dinnit]

That's what I don't understand. I have hidden the H1 class for print by using display: none and also used that on the Breadcrumbs Proxy but the breadcrumbs are still printing. As Flare defaults to not outputting breadcrumbs in print I'm even more puzzled...I am using HTML output and have added the display property on both the ordinary Breadcrumbs and the HTML5 one.

[LTinker68]

I think you need to manually add a style to the stylesheet, because the compiled tags don't look the same as the tags in the XML Editor. I just looked at the output of one of my HTML5 projects, and the breadcrumb trail resolves to:

Code: Select all

<div class="MCBreadcrumbsBox_0"><a class="MCBreadcrumbsLink" href="protecting_intro.htm">Protecting the System</a><span class="MCBreadcrumbsDivider"> > </span><span class="MCBreadcrumbs">Your Responsibilities</span></div>

So in the print medium of your stylesheet, you need to add the following:

Code: Select all

div.MCBreadcrumbsBox_0 { display:none; }

That will hide the entire breadcrumb trails DIV and everything in it. Note that when you look at the page code in the XML Editor, it doesn't mention MCBreadcrumbsBox_0 at all. It should work applying it to the breadcrumbProxy in the stylesheet, but apparently it doesn't, so you need to manually add the styles that it ends up being instead of the one it is in the authoring environment. Try it, at least.

[Dinnit]

Bingo - that has done it . I now have no header and no breadcrumbs printing and will get round the h1 printing on every page (i.e. over the text on every page but the first) by advising users to set their browser to display the title in the browser's page setup so the topic name is shown on the page.

Thanks so much for taking the time Lisa. Much appreciated.

Just wish the css in Flare was not quite so convoluted...Noticed that MCBreadcrumbsBox_0 when checking in Firebug but couldn't work out where it sat or exactly what it was all being used for.

[Spectre]

Hi,

I'm failing to get this to work. My problem is similar to the original post, though in my case, I've no actual header. I've a master page applied to the HTML5 output and the master page includes a breadcrumbs proxy.

When I press the print button in my generated HTML5 help system, the print preview shows the breadcrumbs on the first page followed by the content on subsequent pages. Not a huge problem I agree, but I'd like to get rid of the breadcrumbs when printing the web page, if possible. I've set the display property to none for the breadcrumbsProxy in the @media print section of the CSS. But the breadcrumbs still shows when printing. Any ideas much appreciated.

Thanks.

[Spectre]

okay, just for the record, the method of removing the breadcrumbs from web print, as described in this thread, works fine. I just hadn't read it carefully enough. So, the solution, mentioned by Lisa, is confirmed by MC support as follows:

The breadcrumbs in the HTML5 output is actually control by a div tag called div.MCBreadcrumbsBox_0 that is located inside of a stylesheet that is not accessible within the Flare UI but you can override this by adding the following into the text editor for your stylesheet under @media Print:

div.MCBreadcrumbsBox_0
{
display: none;
}