Convert FrameMaker paragraph formats to RoboHelp styles

[community_help]

This question was posted in response to the following article: http://help.adobe.com/en_US/robohelp/robohtml/WS12199CA1-968E-4a9b-9927-ED490DF6B87E.html

[TimLMun]

After expending a couple of hundred resource hours researching and testing, this statement appears to be totally false: "By default, RoboHelp converts all paragraph formats from FrameMaker to RoboHelp CSS styles, thus retaining the appearance and behavior of the FrameMaker formats in the RoboHelp project."

The opposite seems to be the case. We simply have found no way to preserve/retain the FrameMaker paragraph styles in Webhelp that is published by RoboHelp. If we knew it was going to be this difficult, we probably would not have switch over to the TCS.

[Peter Grainge]

Post moved to FrameMaker Integration forum.

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

[Jeff_Coatsworth]

Can you show some examples? Are your FM paragraph styles that wacky that they don't translate into RH? Nobody else seems to be having any issue with this. Yes, it does involve some work mapping FM paragraph and character styles to RH styles, but their appearance is all controlled by the CSS you use.

[TimLMun]

Thank you Jeff for a specific reply.

First, let me respond to, "Nobody else seems to be having any issue with this." 

In the TechComm Central blog post, "Troubleshooting FrameMaker Content Conversion in RoboHelp Part 1," Mayank Agrawal, the author, says, "Many times, I hear from users that it appears as if Robohelp is not applying FrameMaker conversion settings or eating up the imported .isf settings."  So, what we are seeing is not unique to us.  However, we follow Mayank's steps, and the FrameMaker paragraph styles are still getting lost somewhere.

Second, we have the standard FrameMaker paragraph styles.  For example, this is the content we see in WebHelp that has been published from RoboHelp, along with the FrameMaker paragraph style enclosed in square brackets. (Nothing is indented in WebHelp, but everyone looks fine in FrameMaker.)

1. This is the first step. [FM: List Number 1]

This is an indent that is not indented. [FM: Indent]

2. This is the second step. [FM: List Number +]

o This is a bullet that is supposed to be indented a bit. [FM: Bullet 1]

o This is another bullet that is supposed to be indented. [FM: Bullet 1]

3. This is the third step. [FM: List Number +]

a) This is an alpha list that is supposed to be indented. [FM: List Alpha 1]

b) This is another alpha list that is supposed to be indented. [FM: List Alpha +]

o This is supposed to be a bullet 2 indented even more. [FM: Bullet 2]

o This is another bullet 2 that is supposed to be indented,

and the text wrap for all styles in this example comes to the left margin. [FM: Bullet 2]

This is supposed to be a 3rd level indent. [FM: Indent 3]

Again, everything looks great in FrameMaker.  However, FrameMaker does not appear to be automatically handing off ANY paragraph style formatting information to RoboHelp.  And when we attempt to manually set the styles in the ISF file, the WebHelp generated from RoboHelp does not appear to retain the manually-set formats.

[Jeff_Coatsworth]

Maynak's article doesn't really tell you what to do - he's just explaining the differences between importing & linking. You don't mention which method you use.

Take a look at the resulting RH topics - did the FM paragraph style come over? I.e. did FM's Body appear as Body in RH? All this is controlled by the Conversion Settings screen - the default setting is "[Source]", but you can type over this or select from you list of RH styles to do the mapping.

All of your examples are concerned with lists - that part is also controlled by the Conversion Settings. How did you tell RH to handle them - your options are in that Autonumber section. Did you play around with each choice to see what effect each one had on the resulting RH topics & their output?

Also, further adjustments may be needed to the CSS you use for generating the help output. I found it easier to run all my RH topics through 1 CSS in the SSL recipe when creating my help output.

[Jeff_Coatsworth]

You may also want to check this one out too - http://www.hikaripub.com/presentations/RH_format_control_strategies.pdf

It's a bit old (TCS1), but a lot of it applies.

[TimLMun]

Concerning Maynak's article, we get the same results regardless of whether we link or import a FrameMaker book.

I appreciate the link to the PDF, we are looking it over.  If I am reading the PDF document correctly, then my comment in the OP is correct about the false statement.  There is actually a HUGE amount of manual work that must be done in order for the styles in the Webhelp output to resemble the paragraph styles in FrameMaker.  We would hoping for more of a seamless handoff.

Thanks again.

[Matt-Tech Comm Tools]

Hi Tim,

Sorry to hear that you're having trouble with your TCS linking.

I generally budget about 2 hours for mapping a Frame template to RoboHelp, and almost always come in under that time.

After that, formatting the CSS can take time, but shouldn't be more than a day or two, depending on CSS experience.

If you're spending more than that, I recommend either getting training or arrange for outside help to set up the project. As you might expect, I'm happy to help you with either of these services.

-Matt

@mattrsullivan

[Jeff_Coatsworth]

Sorry that you thought it would it be seamless - I've yet to find much in life that is. From what I gather, virtually every interaction between two different software packages involves some tweaking to get the results you want to see. People are sometimes misled into thinking that just because Adobe owns FM, RH and Acrobat that they all must work perfectly together - they all were developed independently & only recently been interacting with each other.

[TimLMun]

Thanks to Matt and Jeff for the responses.

We are not going to be able to get training or arrange for outside help, because the cost of that would show up as a separate line item in an expense report that went in front of senior management.  If the worker bees just figure it out, even if it takes hundreds of hours, it never shows up as a separate line item in an expense report.  As insane as that sounds, that reason often controls training opportunities or the possibility of bringing in a consultant for many tech writing groups.  (We have also contacted the Adobe Help desk on a couple of different occasions, and so far they have not been able to answer our questions.)  So, it is pretty much up to us.

The handoff from FM to RH could easily be made seamless, using the following strategy.

1. Do an extensive survey to see what kind of paragraph formats users use most. (I have worked for 7 different software companies, and our user guides/online help all had very similar formats.)
2. FM could be given 50 or so out-of-the-box paragraph styles, based on the survey results. For example, H1 - H6, body text, three levels of ordered lists, three levels of indents, some kind of "note", some kind of "warning", and so forth.
3. Users would have to fit/format their documents to use the out-of-the-box paragraph styles.
4. RH could be engineered to reproduce the look of the 50 out-of-the-box styles in HTML.

If people wanted to step outside of the canned styles, then they would only have to map whatever was not part of the canned collection.  If people did not want any part of the canned collection, then they would be exactly where we all are today.

Let me repeat, after viewing all of the posts from the kind people who took the time to respond, that the statement in the OP still appears to be false.

Thank you to everyone who took the time to respond!

Tim

[Jeff_Coatsworth]

I would have to disagree - I haven't had to do much to get this result fairly quickly.

Here's the FM version as a PDF:

and here's it in the published WebHelp:

It's pretty much the same. The only difference is some space left in the PDF for a screenshot - all controlled by conditional tags.

[bgstalder]

We're experiencing a similar issue.

We bought TC1 a couple of years ago expecting that we should be able to fairly easily move from our ePub Pro process of single sourcing Frame files to Webhelp. After all the products were managed by the same company, so you would expect the integration to be fairly capable.

Unfortunately, we've gone through TC2 and now TC3 and we're still fighting the transition. Granted deadlines have a lot to do with that, but what writing group doesn't have deadlines.

And please note, I was the one who set up the Frame to WebHelp process with ePub Pro, so I know what level of commitment that took. I remember diddling with the details for quite a while, but the overall process and UI actually made a lot of sense. I expected this transition to be of the same level of complexity. It's not.