ITauthor

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.