Printing from a webhelp topic

[NeilsonB]

Hi all,

I have a Webhelp project (MCF V7) in which individual topics may be printed as required. However, I cannot for the life of me figure out which page layout is associated with a webhelp project. There is no such option in the targets. The Webhelp print output doesn't even use the default page layout, which surely must be the logical print layout when printing from webhelp print icon.

My printed pages include the H1 topic title, print page number (1 of 2, etc), page file location and print date. This information is not printed from any other medium (Word, PDF, etc), and I've therefore worked out it is a madcap issue. I want to remove these elements. I expect this should be a simple process, although I've not been able to find it.

Further, I have graphics in the webhelp topic that fit the full width of a topic. When printing, the page cuts the graphic clear in half, while the body text remains intact. I'd like a solution that either resizes the graphic or is able to seperately print the graphic in landscape. Any solution would be helpful.

Any help appreciated.

[NorthEast]

Page layouts are only for print targets, they are not used for help targets.

The equivalent for help targets topics is to use a master page; you can use these to include content around the topic body, e.g. breadcrumbs, mini-TOCs, or header/footer.

Page layouts (and master pages) are also applied when the target output is generated; i.e. they're fixed and can not be applied dynamically after the target has been built. So you can't apply a page layout to a help output when you print it.

When you print help, the browser will print whatever is on the screen, and some handle pages in frames better than others. One important note about printing help is that the browser will apply any styles that are set in the print medium; so you can change how your styles appear when they are printed.

As for the extra information you see, e.g. filename, dates, page numbers; is that not added by the browser itself? When I print any web page I get that information too, which is added by the browser.

[i-tietz]

via the print mediuem you can make the print page look completely different compared with the looks in the browser. You can make things visible or invisible, give them different positions, have a different font, etc.
E.g.:
- You have breadcrumbs in the Webhelp, but you don't display the breadcrumbs in the print output.
or
- You have links like "see also" or "next topic" that are there in Webhelp but not in the print output.
or
- In Webhelp you have one column only, in the print ouput you have the headlines outdented and all other text indented.
or
- In Webhelp on a web server the user always gets the current version so a version number is not necessary. But in the print output you insert the print date to give the user that information.
or
- ...

[nickatwork]

via the print mediuem you can make the print page look completely different compared with the looks in the browser. You can make things visible or invisible, give them different positions, have a different font, etc.
E.g.:
- You have breadcrumbs in the Webhelp, but you don't display the breadcrumbs in the print output.
or
- You have links like "see also" or "next topic" that are there in Webhelp but not in the print output.
or
- In Webhelp you have one column only, in the print ouput you have the headlines outdented and all other text indented.
or
- In Webhelp on a web server the user always gets the current version so a version number is not necessary. But in the print output you insert the print date to give the user that information.
or
- ...

So are you saying that when printing a page from WebHelp you can use a medium to change how that page printed from the browser will be displayed? I didnt think you could do that...it would be really nice to have a page printed from the webhelp appear the same as a PDF.

[LTinker68]

So are you saying that when printing a page from WebHelp you can use a medium to change how that page printed from the browser will be displayed? I didnt think you could do that...it would be really nice to have a page printed from the webhelp appear the same as a PDF.

Not exactly the same. They can use the same styles. The WebHelp output will use the print medium in the stylesheet and by default, print targets use the print medium, as well, so they can be set to use the same styles.

The rest of the elements, however, won't be the same, as Dave mentioned above, because the WebHelp output won't print using page layouts. So if your page layout has a decoration frame, for example, you won't see that when printing from the web. Likewise, the header and footer frames in a page layout won't appear when printing from the web. You can kind of mimic some of the effects using a masterpage, but anything in the masterpage would appear in both the online WebHelp and printed WebHelp. Even then, some effects users can override when printing (e.g., not printing background images or colors).

[nickatwork]

Right, thats how I thought it worked. Thanks.

Would be nice to have some kind of 'printer friendly' version that somehow uses the page layout settings..

[i-tietz]

So are you saying that when printing a page from WebHelp you can use a medium to change how that page printed from the browser will be displayed? I didnt think you could do that...it would be really nice to have a page printed from the webhelp appear the same as a PDF.

Example:

print-vs-online.png

I have a toolbar and links to go with the headline. The font is Verdana. H2 has a background colour. The hint has a background colour and no border.
I don't print the toolbar or the links. The font is Arial. H2 doesn't have a background colour but an underline and so has H3 (dotted). The hint still has the background colour and additionally a border, so that with every printer you have a chance to distinguish it from the surrounding text (in a non-colour-print the colors are sometimes very far from what you expect).

Another example: If you chose to have a header or a footer in the masterpage, you can have them look differently in print an online or even have them in print and don't have them in Webhelp ...

BUT:
I don't think you can get rid of the bits the browser fits in like the pages, the date, the path, ... that is sth the user sets in the browser.

[LTinker68]

Another example: If you chose to have a header or a footer in the masterpage, you can have them look differently in print an online or even have them in print and don't have them in Webhelp ...

That's right, I said they'd be in both the online WebHelp and print WebHelp, but you could essentially hide the header and footer in the browser view and have them appear only when printing from the browser. To do that, you'd need to put your "header" and "footer" in DIV classes and in the default medium that div class's display is set to none (hides them) and in the print medium the display is set to block (visible).

[NeilsonB]

Thanks to all who responded. I have to say that it's very disapointing that Madcap Flare can't somehow override the browser settings when printing a topic. I fully expected that I could take full control over the way my pages are displayed, both online and printed, when printing from a webhelp topic.

Is there any script that anyone can suggest that might help?

[NorthEast]

Thanks to all who responded. I have to say that it's very disapointing that Madcap Flare can't somehow override the browser settings when printing a topic. I fully expected that I could take full control over the way my pages are displayed, both online and printed, when printing from a webhelp topic.

Is there any script that anyone can suggest that might help?

It's not an issue with Flare as such; the browser's print setup affects all web pages that you print.

Anyway, most browsers do allow you to change the header/footer; both Firefox and IE have 'Page setup' settings.


If there's a requirement to provide printable documentation to your end-users, then it might be a good idea to also supply a PDF.
For the user, printing from help isn't usually ideal if you need to print a lot of content; you can only print one topic at a time, and the results can sometimes be unpredictable (e.g. how the browser copes with frames). The PDF format gives you far more control over how the content will look when printed.

[Steveman]

Thats basically how I decided to run it. The online view is available if you just want to browse and scroll through the info. You can print the current page if you like (allowing for the different format - but only if you really need some hard copy of the selected topic) or you can click on the PDF link and get the whole manual if you want.

[i-tietz]

"the whole manual" ... so you are yet another TA who doesn't make a difference between linear manual and hypertext online help? Or do the contents differ?

[nickatwork]

"the whole manual" ... so you are yet another TA who doesn't make a difference between linear manual and hypertext online help? Or do the contents differ?

I've heard you mention this before, can you explain what you are doing differently and why, is it regarding your content, or you TOC layout or both.....interested to know.

[i-tietz]

An example:
Contextsensitive help
I have GUI - a tab - that has 8 controls. I have the topic describing this tab. The user gets it via F1 or a ? button. The user opens this help if he has a problem with this GUI, e.g. he wants to know what consequences deleting a line in the list has. Or he wants to know why he cannot delete a line in the list or he wants to know the purpose of that input field H.
Do you really see that somebody would open a complete manual or a PDF with control descriptions for that sort of info? He would have to find the chapter for the GUI descriptions, then he would have to find the GUI, then he would have to find the name of the control he wants to to know more about ... scrolling, scrolling, scrolling ... This is even more difficult (even for the TA), if it's a GUI you get on more than one way, 'cos: Where do you describe the control? wWhere does the user look for it? Do you describe it once only? Or do you create redundancies and describe it in all places? Of course you can use snippets for that but still: Those descriptions make the PDF longer and that means: more scrolling for the user.

Search
A PDF that contains more than one online help topic is uncomfortable to use for the user: In an online help you can enter two or more search strings and you get a list of topics that contain those strings. In a PDF you can search for one search string only. This makes looking sth up a pain in the a..

All this only applies if you separate the descriptive part from step-by-step tasks and from background knowledge like describing concepts and algorithms of features.
The other alternative is not to separate those sorts of information and e.g. have the background knowledge in between the control descriptions.
In online help you can do that by using links to those background documents. In a PDF that's difficult: Do you stuff it into each control description it belongs to? Do you fit in a link and make th user jump to a different chapter of the manual? Then the user reads the text there and he scrolls it a bit and then ... how is he supposed to get back to the control description he came from?

...

In addition to all that there are mechanisms like dropdowns in online help that make finding specific controls or tasks a lot easier. In a PDF you would have to fit everything in with dropdowns opened, means quite a bit of scrolling to find the control or the task description you're looking for.

Linear and hypertext media each have features that make them the right tool for a specific task. But none of them is an all-in-one device suitable for every purpose. You can have both kinds, but for different purposes, which automatically means different contents.

The image for that: Of course you can use a spoon to bang a nail into the wall, but it takes longer than doing it with the appropriate tool - which is ...

[LTinker68]

My online and print outputs aren't exactly the same. In some cases, it's minor word changing. In others, it's specific topics not being included because it doesn't work in one medium or the other. For instance, in the online help I have links that bring up PDF forms. In the print output, that wouldn't work so well, so I converted the PDFs to images and put them in topics with no headings because there isn't a way (that I'm aware of) to have Flare pull in a PDF and combine it with the PDF you're building.

You also have to take into account how your users will use each output type. Online help is more interactive with searching capabilities and other ways to find content, so you can't rely on them reading the topics in the order they appear in the generated TOC. Print output is generally read more linearly, but still has to allow for more experienced user to use it as reference only. So you should take into account how your users will use those outputs when you design the TOC order and content.

So, IMO, your online and print outputs should never be exactly the same.

[lacastle]

there isn't a way (that I'm aware of) to have Flare pull in a PDF and combine it with the PDF you're building.

sorry to be off-topic, but i wish there was a way for this too! (and for some reason i haven't done a feature request until now)

[LTinker68]

there isn't a way (that I'm aware of) to have Flare pull in a PDF and combine it with the PDF you're building.

sorry to be off-topic, but i wish there was a way for this too! (and for some reason i haven't done a feature request until now)

I put in a feature request when I was working on this last project, too. Although you can use Acrobat to insert pages into your compiled output, the TOC won't match so your page count would be off. I guess I could put dummy pages in the project and then replace those pages in the output using Acrobat, but if I ever forgot that step then the output would look ridiculous, so safer to insert them as images, even if their display in the PDF output isn't as good.