Looking for an editable output from Frame 7.2

[Steve Rickaby]

At 21:45 -0800 8/1/07, Greg Thompson wrote:

>  My current client wants me to provide them with output from the Frame guide
>  I created for them in a format they can edit, not using Frame. Then they
>  want to be able to re-publish these files (again, not using Frame) and have
>  them look the same way they looked when I created them in Frame.

Why do they want to do this? Why cannot they buy Frame and learn it? What do they want to use? (Wurd, no doubt...)

>  I am an experienced Frame user but not a guru and I doubt that what they
>  want is possible.

It would certainly be hard, with a tendency toward impossibility unless the document design is very simple.

It seems to be widely accepted that Mif2Go is best at producing RTF, so I would expect that your most productive line of attack would be a FrameMaker -> Mif2Go -> Word -> FrameMaker workflow. The last step would almost certainly be a pain for you. There will be others on this group that will have direct experience of this, so they may be able to provide more concrete advice.

>  I know I can save Frame files as html, xml, text, or rtf and edit them. But
>  I doubt that I can republish them and have them look like they did in Frame
>  without using Frame

Your doubts are well-founded. FrameMaker's native export filters are... ahem... suboptimal.

There's just a smattering of a chance that FrameMaker 8 might give better support for Word round-tripping, but this is nothing more than surmise on my part.

There is another way of looking at your problem. If your clients are only interested in editing *content*, you should at least investigate the possibility of constructing modular documents - that is, FrameMaker documents whose text is imported (as text insets) from plain ASCII files. That way, your clients could edit the ASCII files to their heart's content, and you could then rebuild your FrameMaker document using them.

Snags to this approach are:

. It doesn't directly support graphics

. The modular construction and lack of graphic support leaves text file editors without global milestones (although they could cross-refer to a PDF of the 'real' document)

. Text insets suffer from a few wrinkes, such as (in the case of plain ASCII files) not supporting cross-references into them, and not supporting character markup

However, as you suggest that your clients want to be able to republish themselves, this idea is unlikely to help. I just hope your clients have not fallen into the 'documentation is easy, our engineers can maintain it' trap ;-)

-- 
Steve