So let me get this straight. You have a Word document. You suck it into RoboHelp to create HTML. Then you create a completely different Word document using RoboHelp that is then used to create a PDF.
Why not simply create the PDF from the original Word document? Seems more straightforward to me.
Your present workflow (using an analogy) is like this: You are baking a cake. You take the flour and eggs and milk and blend them and bake the cake. Then you take that baked cake and break it up to try and get flour and eggs and milk back out of it and you dislike the fact there are all these crumbs to deal with!
Helpful and Handy Links
Nope - I have a word document. I suck it into RoboHelp. I intended to produce multiple output types (pdf, html, maybe chm). In trying to get the PDF output to work I'm finding the TOC/Chapter feature to be confusing, since the results aren't what I'd like and I'm not sure how to get from Point A to Point B.
The problem with that workflow is that RH needs Word to get to PDF; so your workflow ends up being Word to RH to Word to PDF !!
So, this is one of my frustrations with RoboHelp in general - what's the best practice? Lots of how-to guides and videos, but not a lot of recommended ways to do (what appears to me to be) common functions.
I have a bunch of developers writing documentation that will be included in a team guide. All the developers have Word (and we don't want to buy everyone RoboHelp). I've developed Word templates to guide them as to what needs to be captured and how it should be formatted. I need to be able to combine these documents (they contain formatted text, pictures with captions, tables, graphs, so Word seems the appropriate editor for the masses) to generate at least PDF and HTML output. The documentation is to be delivered to the government, so I have some content requirements (front matter, TOC, glossary) that RH seems to be ideal for. Bringing in numbered headings (what I *believe* is the preferred way of doing this in Word) and then generating a TOC in RH seems to be the issue, since the same components that generate the TOC also create my chapter headings - leading to duplicates.
Maybe I'm approaching this wrong and there's some best practice someone can point me to?
I appreciate your time responding to this!
Personally, if I were in your shoes and I really wanted/needed PDF, I'd avoid using RoboHelp to create it. Instead, I'd just PDF the Word documents straight from Word. Then use RoboHelp to pull in and convert to the HTML stuff for the on-line outputs.
But that's just me. I am obviously the laziest person around. Why? Because I've heard it said that you give the laziest person the hardest job and that person will find the easiest way to get that job done.
Just seems easier and less frustrating that way.
Either way, you stil have to perform a separate action to get the PDF, no?
Helpful and Handy Links
Well…there’s a few things in here – the first being that RH was developed (not by Adobe); so the integration to PDF creation we all know & love in Adobe products is very weak. The other thing is that RH was never designed for producing print output (as PDF is); it (RH) does a good job of creating online help output.
Now to your situation – if you really need print as an output, you should invest in the Technical Communication Suite. Have your authors work in Word, pull that content into FrameMaker, produce beautiful PDFs from FM and also link the FM content to a RH project for the production of great help. That’s what I do for one of my product lines. The other has no requirement for PDF, so I author in RH and produce AIR Help for it.
However, this ideal solution may not work for you. In that case I would go with what Rick says – use RH for the help and Word for the PDFs. Don’t mix the two.
Frankly, if the government is your customer, I’m really surprised that you aren’t forced to use structured FM and crank out some DITA or SGML/XML to some obscure government standard ;>)
Understood. I will look to generate the PDFs directly from Word and use RH just for the HTML for now.
Yes, I'm surprised we have as much leeway as we have on the documentation standards - I must be working with a progressive branch. :-)