I get the feeling that ever since Adobe released the DITA application pack for FrameMaker 7, lots of people have been beavering away with it writing structure applications and  their own FrameMaker extensions,  and generally seeing how far they can go with DITA in FrameMaker. It's all a bit hacky - even though the functionality from the application pack is now built into FrameMaker 8.0.

The trouble is that the application pack makes DITA possible, but it doesn't make it a realistic option for most folk because you still need to do a lot of work before you can actually get to the stage where you can hope to produce professional quality documentation with it. If you're like me you just don't have the time to dedicate to this. However, there are efforts to bring this to you and reduce the amount of setup work you need to do before you can start using DITA to produce documentation in FrameMaker.

One such effort  is DITA-FMx. I haven't  tried it out yet, but you can download it for free from here:    

http://www.leximation.com/dita-fmx/

Check out the  online help here:

http://docs.leximation.com/dita-fmx/0.01/  

It's probably worth a look, but I'm still kind of hanging on for Madcap to get their act together on DITA. Flare seems like an obvious tool to use with DITA, but it wasn't in the recently released DITA 3.0 and I haven't heard any firm plans for when it's going to get added. Adobe have stolen a march on Madcap here, but I suspect Madcap's DITA effort will be worth waiting for - so I'm holding back spending time doing DITA in FrameMaker until I see what Madcap come up with, or until I get fed up waiting.

Another of those soul-destroying Flare errors that strike you out of the blue when you try to compile output from Flare:

"Object reference not set to an instance of an object."

There appears to be no solution to this problem as yet. See:

http://forums.madcapsoftware.com/viewtopic.php?t=1947&start=0&sid=91025ee508cf1c1cb4e32fc0d17b4628

This error happened to me just now. After restarting Flare I was able to complete the compile, but when I clicked to view the output Flare froze. I then went to the output in Windows Explorer and double-clicked the index.html file to have a look at the output in Firefox. At this point Explorer froze on an egg timer. Even after killing and restarting the explorer process in Task Manager, Explorer does not respond and doesn't let me into the Start menu.

I feel a reboot coming on!

---

The reboot didn't fix the problem. By working backwards I discovered it was a problem with invalid XHTML. One of my topic files had an extra </div> closing tag.

You'd imagine that a little bit of error trapping could have reported an error such as "Invalid XML in topicfile.html." Instead, the last topic in the compiler output had nothing to do with the problem.

My advice if you get this problem is to sort all topic by date modified and then go through, one by one, opening each of them in the XML editor. If one of them fails to open, open it instead in a text editor and track down what's wrong with the XHTML that's causing Flare problems.

I've blogged before about the bug in Madcap Flare that results in all paragraph formats having hyphenation switched on.

Paragraphs should never be hyphenated unless they are justified. Hyphenating text that's aligned left looks daft. So the result is that you have to sort out this problem in the FrameMaker files produced by Flare before you can output to PDF. A tedious process, but here's the best way to do it. The same tip applies to any change you want to make to each and every format in a FrameMaker file:

1. Open the FrameMaker file.
2. Choose Format > Paragraph > Designer.
3. In the Paragraph Designer dialog box, click the Commands button.
4. Choose Set Window to As Is.
5. Now make the format change you want to make. In our case, click the Advanced tab and clear the Hyphenate check box.
6. Click the Commands button again.
7. This time choose Global Update Options.
8. In the Global Update Options dialog box, choose whether you want to apply changes from multiple tabs in the Paragraph Designer dialog box, or just the currently displayed tab. In our case, we've only made one change so it doesn't matter which of these options you choose.
9. In the Update Paragraph Formats section, choose All Paragraphs and Catalog Entries.
10. Click Update.
11. Save the document.

That's it. Hyphenation is removed from all formats in the document.

You can now use this document as a template for the other document. To do this:

1. In the book window, select all chapter documents.
2. Choose File > Import > Formats.
3. In the Import from Document field, choose the document you just modified.
4. Select all of the check boxes in the Import Formats dialog box.
5. Click Import.

If you are outputting from Madcap Flare to FrameMaker and, when you try to generate the output, you get the error message:

"One or more previously generated files are open in Adobe Framemaker"

but FrameMaker isn't running, the problem is almost certainly that FrameMaker exited without cleaning up one or more of its lock files.

The solution is to go to the output directory and delete any files with the extension .lck.

Alternatively, just wipe the entire contents of your output directory and regenerate the output from Flare.

It looks like I'm going to have to come up with some tedius workarounds for the flaws in the way MadCap Flare outputs to FrameMaker. One example of a flaw is that - as far as I can make out - Flare ignores any styles you may have applied to anchors (i.e. a elements) and so, when they come over into FrameMaker, they are indistinguishable and you loose any differentiation you may have had in your WebHelp between two different kinds of anchors. Another baffling irritation is that text I have defined with a PrintOnly condition come over into FrameMaker with a "link" format applied to it.

To workaround a lot of this madness I think I'm going to have to take the FrameMaker files, save them as MIF files (which are text versions of binary FrameMaker files), run a whole batch of search/replaces on these files and then pull the resulting MIF files back into FrameMaker and do the final tidy up, reformatting work prior to outputting to PDF.

All of this is extremely depressing when you consider that you should be able to go straight from Flare to FrameMaker, apply a template, and output to PDF, without ever having to do anything more than click a few buttons in Flare. I think that's what's known as a pipe dream. Come on MadCap! Make it happen! Or at least make it possible.

Anyhow, MIF seems to be the only way to do this, since the FrameMaker output from Flare isn't a structured document, meaning you can't process it with XSL in FrameMaker.

Here's some details on MIF:

http://www.stc-siliconvalley.org/newsletter/2002_1...

And here's a link to an evaluation download for Mif2Go - an application that allows you to output a whole bookful of files to MIF from within FrameMaker:

http://www.omsys.com/dcl/download.htm

---

Update:

After writing this post I realised that I was taking the wrong approach to outputting from Flare to FrameMaker. The reason the a elements were indistinguishable was because all of my topics contain the following references:

Following the instructions in Flare's help, I was defining styles in Flare's style editor and associating formatting with a "print" media. However, this was all happening in the main memex.css file that is included in each of these referenced files. Basically, the idea is that I set up all my styles in memex.css, then include this in MemexScreen.css and MemexPrint.css and add to these files any alternative formatting that, because it comes after the included file, overrides the main memex.css file. However, the Flare style editor wasn't making it clear that all of my styling, including the "print" media stuff was going in the memex.css file, when the print-only stuff needed to go in the MemexPrint.css file. Once I worked out this, the classes I applied to the a element got transmogrified into FrameMaker character formats, as I'd originally expected.This finally opened my eyes to the fact that I needed to apply this principal to all styling for my printed output. In fact what I did was, as a test, I just copied all of the styles from the main memex.css file into the MemexPrint.css file. When I then built the FrameMaker output, lo and behold it came out looking very like the WebHelp output. This wasn't actually what I wanted, but it proved the principal that the way to get the single sourcing to work from Flare to FrameMaker is to do all your styling in Flare. See: Hold off on the MIF for more on this.