Using MadCap Flare, a help authoring tool, can be cool and unbearable at the same time. Those InfoDevs who deal with it on a regular basis will definitely understand what I mean. The more I work with this tool, the more I learn about its capabilities and pitfalls. The work on multiple print outputs and the HTML5 target makes the challenge even more exciting. Previously, I shared some issues I encountered with possible solutions for them (See MadCap Flare: pain points and solutions). In this article, I have prepared another portion of troubles to be considered. So, Ready Steady Go!
MadCap Flare. We, Technical Communicators, use it daily. But do we really use it to its full potential? Or, maybe it has some hidden capabilities or mysterious forces we may have no idea about? Let’s follow this bumpy journey and find out together! Continue reading
I work with the MadCap Flare tool on a regular basis. Namely, with two targets – the HTML 5 Help system and the PDF file. That presupposes that I deal with two outputs, two style sheets, and all my troubles are usually multiplied by two :). In this article, I want to share my pain points as well as possible solutions for them. So, here we go!
Imagine a situation: you’re going to prepare a help system for a website. You suggest creating a help that has the look and feel of the website itself. The customer is happy with that, and you’re eager to start as you have MadCap Flare 11 or 12 with that cool TopNav output. However, the website uses custom fonts, and you need to use them in your help system.
What would you do?
A good help system portfolio showcases our smashing expertise better than a thousand words. But it’s very easy to deliver a portfoolio if you’re unaware of all pinpricks of MadCap Flare 10 or another help authoring tool (HAT) that you’re using.
This and more below, in less than a thousand words.