Pre-Release Review of Flare V5

Soon MadCap Software will be releasing the next major version in the Flare product line, approved Flare V5.

I’ve been beta testing Flare 5 for a couple of months now, information pills and there are some great new features in Flare 5 that you are going to love. In this review, I want to point out some of my favorite new features, as well as some of Flare 5’s other great enhancements.

Let me begin by saying that I love Flare, and I think Flare 5 is a great enhancement on an already great product. I am biased; I’m a certified Flare instructor, have been a VIP in the Flare Forums for 2+ years, and am a certified MadCap Advanced Developer for Flare V4. But being biased doesn’t necessarily make me wrong <grin>. I’m under NDA for this project, but I’ve received permission to give you a preview of what you can expect from the soon-to-be-released version 5.

Here are five killer reasons you should consider upgrading your version of Flare to V5 as soon as you can:

  1. Workspace improvements in both XML Editor and Source Code View
  2. DITA Support
  3. PDF Target Enhancements
  4. Relationship Tables
  5. Other Enhancements
    – Topic Tool bars
    – Thumbnail Image Support
    – Text Redaction Support
    – Improved Performance
    – Conditions in Project Organizer
    – Backup Differences
    – New Toolbar buttons

I’ll discuss each of these features in the sections below.

Workspace improvements in both XML Editor and Source Code View

Flare 5 sports a spiffy new code editor with line numbers, color-coded tags, and easy access from the XML Editor. It’s also a lot easier to get to the source code editor, as there is now a button in the XML Editor.

When you are using the XML Editor, click the “Send this File to Text Editor” button, which is now in the XML Editor toolbar.

The code view opens in a separate tab:

This image is kind of small, but you can see that the code editor includes line numbers and color-coded tags. When you make a change and save it in the code view, the change is automatically reflected in the XML Editor (WYSIWYG) view. Flare finally includes a code editor that makes me want to use it instead of an external editor!

In addition, you’ll notice new formatting indicators in the XML Editor. These help you see where the invisible tags are in your source code. For example, the following image shows the Flare 5 XML E

There are three things in the screen shot that are new in Flare 5: First, spans are now identified in the XML editor. Look at the word “originally”; notice the blue brackets around it. These indicate that there is a span applied to that text.  This makes identifying spans easier. They (obviously) don’t affect your output, but when working in the XML editor, you can easily see where the spans begin and end.

Second, notice the condition tag that is applied to the “[5]” reference. Now when you apply conditions in-line as spans, not only does the background change, but now there is a box showing which conditions have been applied (just like you see next to content in the Content Explorer, or in other areas in Flare). This is a small, but very nice enhancement.

Third, Flare now shows you empty tags so you can remove them from your code. In the case of the image above, there is an empty <p> tag set. I can delete it from the XML editor, or I can open the code view to delete it there.

DITA Support

This is the headline feature in Flare 5, and for good reason. You can now import DITA projects into Flare, edit them in Flare, and then generate any of Flare’s output types. This is a groundbreaking achievement.

As with other Flare import types, you can continue to author in a native DITA application and use Flare as a publishing engine, or you can take existing DITA content, import it into Flare, and then use Flare as your authoring tool. In either case, you can then publish your DITA files directly to PDF, WebHelp, Word, FrameMaker, etc.

Flare 5 also has a DITA target output type. This means that you can export your Flare project as a DITA project that you could then transport to any tool that supports DITA.

This is cool for so many reasons, especially when you consider the implications of project collaboration. DITA is quickly becoming a standard format for technical documentation. Being able to export your project to DITA means you can send your project to anybody who uses DITA, with whatever tool they use, and they can open and use your project. If your localization team supports DITA, you can send them a DITA export of your project for translation. If you need to send your project to a client for them to modify at a later date, you don’t have to worry about tool compatibility, because as long as they can work with DITA, you can send them files they can use. And if for some incomprehensible reason you want to use a different authoring tool, you can export your project to DITA, and import it into some other tool.

This is the end of proprietary file types! Your content is YOURS to do with what YOU WANT. You don’t need to rely on somebody creating a transform that can convert MadCap’s content into an importable format for another tool, because you can create a DITA target.

This version of Flare does not yet support native DITA authoring. While you can get DITA in and get DITA out, the project in the middle is a Flare-based project with the Flare-based XHML source files. However, a future version of Flare is supposed to provide native DITA  authoring.

If you are using DITA, or if you are considering how DITA can be used in your organization, you ought to check out Flare V5, because the direction they are going with DITA support is literally awesome.

PDF Target Enhancements

Flare 4.2 addressed some PDF enhancement requests, in that it allowed you to modify the image compression settings for creating PDF files. That was a nice feature, since you finally got some control over how images would be compressed and how that would affect your overall file size. However, you still needed the paid version of Acrobat in order to set the metadata (like author, etc.). No more. Look at what is available to you now:

Now I can truly build and release without any post-processing. I run a script nightly that builds all my documentation and places it in a location where the software build script can pick it up. Now that script builds releasable documentation. That is awesome, and this is a small feature, but one that adds a great deal of value.

Relationship Tables

DITA supports relationship tables, so Flare 5 now supports relationship tables. The Center for Information-Development management has a good article that describes DITA Relationship tables. To summarize, a relationship table is a centralized location where you can link related concepts, related tasks, and reference topics.

In Flare 5 you can insert a relationship proxy into your master page, and then every topic that is linked in the relationship table will show the relationship in the topic, grouped by concepts, tasks, and references (if a relationship exists for that topic).

When you need to update these references, you do them all in one place: the reference table. There is no need to go into individual topics and tag them with a concept; no need to add “related topics” manually. You can have these appear automatically in topics with the relationships proxy.

I have only used this superficially until now, but I plan to use this feature extensively in my next project, so I’ll keep you updated on how it goes.

Other Enhancements

There are several other enhancements I’ve discovered in Flare 5 which include:

  • Topic Tool bars
  • Thumbnail Image Support
  • Text Redaction Support
  • Improved Performance
  • Conditions in Project Organizer
  • Backup Differences
  • New Toolbar buttons

Topic Tool bars

You can now include a toolbar anywhere in a topic, which is pretty cool. Here is a skin I created for a project I was working on. I made tabs for the tool bar, and then I moved topic-specific stuff into the topic toolbar, which I floated right. So there you can search the topic, remove highlighting, or mark the topic as a favorite. Since these are topic-level tasks, it makes sense to add them to a toolbar that is in the topic itself.

This feature greatly increases the flexibility options for creating custom skins.

Thumbnail Image Support

Flare now supports image thumbnails. You can create a thumbnail class and apply it to your images. Flare will generate a smaller version of the image, and when users hover over the image (or click on the image, you decide), a larger version of the image can be displayed.

The help system gives detailed information on how to set up and use this feature in your projects.

Text Redaction Support

If you produce sensitive documents, Flare now supports text redaction. With text redaction, you can generate two versions, say of a PDF file. One can contain the full text, and one can contain the redacted text.

You might wonder why you would want redaction when you could conditionally exclude content. In some cases (particularly in government applications) it may be preferable to produce a document with redacted text, rather than just not containing the text. Additionally, when you redact text (instead of excluding it conditionally), the page counts stay the same in both versions of the document.

Improved Performance

Flare 5 sports improved performance, especially surrounding WebHelp target generation. I don’t have any hard numbers here, but it just feels faster. It also seems to have improved stability, based on my experience using it. I can’t remember a time during my beta testing of Flare 5 that the application crashed on me. That is a far cry from the days when I was using Flare 3, which (for me) seemed much less stable. (There was a time, using Flare 3 that Flare was crashing every day at least once, so for me, the improvements in Flare 4 and Flare 5 are fantastic.)

Conditions in the Project Organizer

You can now use conditions in the Project organizer. This allows to you exclude content from the Project Organizer, based on conditions settings in the target. So, if you have separate deliverables in the same project and you want to separate the header and alias files based on the target, you can–and you won’t get any errors when you generate the build!

Again, this is a minor enhancement, but it is one that will make things a lot easier for many people.

Backup Differences

If you use the backup options in Flare, you can now view a diff of the current version from the one that is backed up, which you can view in code view, or in WYSIWYG view.

New Toolbar buttons

There are two new buttons available on the toolbar or the topic toolbar. There is now a Previous button and a Next button. If the topic is part of a browse sequence, then the previous and next buttons show the previous/next topics in the browse sequence. If the topic is not part of a browse sequence, then the buttons show the previous/next topics in the TOC. (This won’t work properly if the topic is added to the TOC in multiple places, or if a topic is not in the TOC.)


Flare 5 is a great enhancement to the Flare product line, and includes more features than the ones I’ve listed. If you are in the market for a help authoring tool or if you are using DITA, check out Flare V5; it will knock your socks off. If you already own Flare, upgrade when it is available. Kudos to MadCap for coming up with a great product with enhancements that really improve the technical author’s workflow, making producing great content faster and easier than ever before.


23 responses to “Pre-Release Review of Flare V5”

  1. Sounds amazing. I’ll be tweeting this one.
    Can I ask – since it sounds like you’ve gotten permission to basically spill all – is there any chance this version is going to support RTL languages (Hebrew & Arabic)? B/C *that* would totally swing our doc team over to Flare…

  2. Very informative write-up, Paul. I’m so glad you’re on our team now! I especially enjoyed the light you shed on the DITA publishing. I didn’t know that you could output to a DITA target in Flare 5. That rocks. (Not that we’re using DITA anyway, but still, it feels nice to be DITA capable.)

    One little question. With the enhanced inline editor, are you telling me it does not still wrap the text?

  3. Good article, Paul!
    Thanks for summarizing some of the good new features. We have been Flare users for several years now and are big proponents of Flare, but there are some spectacular time saving upgrades in this version that we can’t wait to implement – line numbers will save us from going to an outside editor to fix problems in the code and we can’t wait to use relationship tables!
    Seeing empty tags will also help us clean up our code.

  4. Paul,

    I didn’t get a chance to participate in the beta this time around, and was really glad to see it through your review. One of the features we asked for back in v3 was the ability to use default Next/Previous buttons in WebHelp. If I read your review correctly, it’s finally here for WebHelp. We created icons that we inserted via a conditioned snippet on each topic page and then converted to text on each page for adding hyperlinks. We didn’t like the idea of the Browser Sequence TOC panel. Yet this workaround is painful when you have to restructure the topic pages or want to output using a different TOC.

    Thanks for the great peek at 5.0!

  5. Any chance that V5 will support FrameMaker 9.0. Last time I heard from MadCap (several weeks ago), is that they were working on it.

  6. Paul, can you shed more light on the details of the DITA implementation? You say that you can’t actually author natively in DITA with Flare. So what is the intended usage model? And what does Flare do with all the DITA tags when you import a DITA project? What does it do with tags when you export to a DITA target? Does Flare support specializations in DITA?

    Another question about the text editor: Can you open multiple files in the text editor simultaneously, as you can in RH or Dreamweaver? That’s always been a major peeve of mine about Flare, because I like to view the source code, and sometimes I have to open multiple files.

    • Steve, I believe that with the current version of Flare the preferred DITA workflow is to take some DITA content, convert it to a Flare project, and work in the Flare project to make updates, publish your targets, etc. I think that a secondary workflow would be to continue authoring in DITA, and then just use Flare as a publishing engine.

      The DITA target solution is a way to get your current project out into an industry-recognized output format that you could then take to use in another tool, if necessary. However, reports from real DITA users suggest to me that the DITA that is created doesn’t match the DITA spec. For example, if you had a [note] element in the DITA source, Flare converts that to a [p class=note] element. When you output to DITA, the resulting content is in the [p class=note] format rather than the [note] element.

      A future version of Flare will address this (I assume) because you will be able to author natively in DITA.

      An ancillary issue is that since in Flare 5.0 you are authoring in native Flare format, not DITA format, Flare doesn’t have any way to enforce the DITA spec (requiring certain elements in a certain order). So when you create DITA output, it is well formed, but MAY not be valid. (I don’t know for sure, since I am not a DITA user, so I haven’t tested this.)

  7. Steve, I haven’t tried the DITA stuff yet, but you can have multiple text editor windows open at the same time.

  8. @Paul Griffiths
    Paul, thanks for your response I’m sorry I wasn’t clear, what I meant about opening multiple files is not actually having them open, but the act of opening them. With Dreamweaver, for example, I can select a whole bunch of files, right-click and open them all in source view. Two clicks. With Flare, I have to right-click a file, move my mouse to select “Text Editor” and then click it. Two clicks and mouse motion. Imagine having to do that for twenty or thirty files. Admittedly, most people don’t do this, but it is very annoying for me.

  9. @paul
    Hi Paul,

    Thanks for the details. That’s really what I need to know. It sounds like as a DITA tool, it’s still not quite ready for prime time, unfortunately.

  10. @Steve Goodman – I would amend your comment slightly. As a DITA publishing tool, I think it is ready for prime time. If you have DITA content, you can use Flare as a multi-channel publishing tool without having to use the open tool kit, or without having to use your own transforms to get some type of output. However, MadCap’s roadmap for Flare includes a future release where Flare becomes a DITA authoring tool.

    So if you expected Flare 5.0 to be a DITA authoring tool, then yes, it’s not ready for prime time, but it wasn’t intended to be. Flare 5.0 is simply a DITA publishing tool. Authoring will be coming in a later release.

  11. @paul – I won’t disagree with you about it being a good publishing tool until, or if, I ever test it. Unfortunately, I can’t see it being a realistic tool for us if it is only a publishing solution, because we already have a publishing solution (though our PDF solution leaves much to be desired-might even say it’s more of a PDF problem than solution).

  12. Real improvement I’d like to see in the new version (I guess I should address this to the Flare folks) is the importing of Word docs into Flare. I’ve tried two different methods and each one is a pain to do a conversion. But I suppose that’s due to code differences in Word and Flare.

    I would also like to see Flare improvement in the generation of map IDs. The current interface is cumbersome, and never changes in product upgrades.

    I’d also like to see DHTML features (or XML equivalent) in the product to produce special effects (such as headings spiraling in on the page, etc. RoboHelp was really fun in that respect.).

  13. Excellent review of Flare 5.0. I found it very helpful, and thanks for the link about the DITA relationship tables. I just upgraded to 5.0, like you – I remember when 3.0 used to shut down on me three our four times per day. It was so bad, in fact, that I used to hit the save button after every single update to any file or topic – just to be on the safe side. What a pain that was. Flare 4.0 got much better, so if 5.0 is even better still, I’ll be looking forward to it.


    end transmission……………….///

  14. Since the posting of the first Reply over a month ago, a Flare press release regarding Microsoft’s use of Flare with their Amalga software was published. Our company has an Israeli unit, and I too thought there was no RTL language support in Flare, but check this out:

    “Because Flare provides a command line compiler can handle right-to-left languages, such as Hebrew and Arabic, as well left-to-right Western and Asian languages,” Gross explains, “that means we can simply send the original source content for localization. Once the translated content comes back, it becomes part of the project that we can have Flare build.”

Leave a Reply