Journals by RSS
Journals by EmailRoboHelp has been a bit infamous for bad Word output. That’s a reason one of my colleagues picked Flare (he also got a free copy, so that helped)—Flare smoothly moves CSS styles over to styles in Word that preserve the appearance.
I’ve been trying to figure out how to get my default list styles in a Word template to align the way I want so when I output from RoboHelp to Word, they’ll automatically take on that alignment. (Come to find out that there’s no way to tweak the list styles for “Normal.” Lameness.)
I know the Word-to-RH import and RH-to-Word output have been improved in RH8, but that doesn’t help me right now.
Anyway, while I was messing with this list problem, my eyes opened and saw the reason for bad Word output.
In the past, my Word output looked bad because I used my CSS file, and Word ignored most of my specifications for paragraph and list item spacing and indentation. It didn’t carry paragraph borders over, either. It would take way too much reformatting to make it look right.
My epiphany was this: The reason those things were ignored is that I had them specified in pixels.
I reworked a style sheet for my user guide project that I’m trying to author in RH. I redid everything either in points or inches. This included paragraph borders where I had them—I changed the 1px thickness to 1pt. When I reran the Word output, bang! Word paid attention to my styles much more closely.
It took some cycles of tweaking the style sheet and generating the output to get things the way I want them. I still have some alpha lists that aren’t aligning correctly, and I think it has something to do with the way they’re specified in the HTML. I discovered that after any interruption of an ordered list, such as a secondary list or an indented (non-numbered) paragraph, I have to specify the start number or else Word doesn’t recognize that the primary list resumed.
I also did some experimenting with styles for the TOC, but I haven’t gotten those to work yet. However, a quick reformatting of the TOC isn’t a killer. I’ll also be playing a bit with headers and footers. I’m much more encouraged after today that I can make my printed documentation output from RH presentable.
What about projects where you’ll have the same content going to both online help and printed documentation? You probably don’t want all point and inch declarations in the CSS. I’d say in this case, create a second style sheet with the inch/point styles (I actually am using a second style sheet for the user-guide-only topics). Then before you run the Word output, use the Topic List pod to select all topics and change the style sheet to the one for print in one fell swoop. Then use the Topic List pod to change the style sheet back before running HTML output.
Related posts (auto-generated):
2 Comments to 'Styles in Inches and Points Improve RH-to-Word Output'
April 22, 2009
Ben:
Congratulations on your epiphany! I did one RH/Word Help/manual combination project several years ago (about RH5.5), I do not have a handy copy to review, bit I know I solved the transfer issue with two separate style sheets with identical style names, but different specifications for each style in Word and RH. I have also made matching FrameMaker and Word style sheets in an environment where both tools were used, but the company wanted all the documents to look alike.
I think you just figured out one of the key concepts necessary to make (fake) anything to look good in Word.
I do all my vertical text spacing in tables with pts above and below the text, using text styles that appear only in tables.
Good job!
April 22, 2009
Yeah, I wish I’d have realized it earlier, but this is actually the first time I’ve tried to do much of anything with RH-to-Word. I’ve kept online and print formats pretty separate until now, but I’m trying to wake up to the benefits of single sourcing. So I suppose it’s not so bad. At least it didn’t take me longer to figure this out than it did.