A better way to deal with lost hyperlinks when converting Robohelp to Printed doc?

[TechWriterKat]

I have inherited a 750-page manual that is "single-sourced" in RoboHelp X5. When I generate printed documentation, all of my hyperlinks and converted to plain text. Everytime we release a new version of the manual with any changes, we have to re-generate, and then manually go into the MS-Word converted document and re-create some 350 hyperlinks and page number references. Somebody please tell me that there is a better way to do this, or a better tool to manage single-source documentation.

[Peter Grainge]

Welcome to the forum.

You need to upgrade to RH6. The links work when you generate the printed document.

[TechWriterKat]

Thank you for the quick response. Do I need RoboHelp X6 or RoboHelp X6 Server? I've had some other problems with X5, which I'm running on XP. It doesn't always generate the whole document, and when it does, the images llok like they were stretched are stretched out and distorted. I've been perusing your WEB site; extremely helpful -- thank you! Nothing on it about that problem though.

[MergeThis]

Just RH6.

As to the incomplete compile and distorted images, I'd say you're probably working the project over a network. Nothing good ever comes out of doing that.


Good luck,
Leon

[TechWriterKat2]

This is TechWriterKat, but for whatever reason this WEB site forced me to create a new nickname so I could reply to the messages below. Bear with me, folks; I'm new to this forum stuff!

First to Peter: The problem with the stretched out images and the printed document failing to import the entire help source to WORD only occurs with the 750-page document. I have two smaller help systems that do not have this problem. In all cases, I'ved used my own (or a template from the previous writer) to generate printed documentation. Interestingly enough, it works on her computer, which is running Windows 2000, and is a few years older (and slower) than mine. I'm trying with StyleMapping.dot now, and we'll see what happens with the bigger document. It only processed 450 pages of the book, then produced the index and called it a day. The images look fine though. When I'm able to make it process all 750 pages (why it does it sometimes and not always, I do not know), the images look distorted. This is why on my last deadline, I drove an hour away to build it on a slower, older computer than mine!


On another, but related subject, the company I'm working with asked me to research various solutions to the lost hyperlinks problem. Since RoboHelp is now part of Adobe, do you know if it can/will convert files into Framemaker instead of WORD? What do you know about FrameMaker & WebWorks? These are also Adobe products, which I've heard are supposed to offer a single-source online help/printed doc. solution.

One last thing, the company I'm working with has developed a new product using .NET framework, which requires yet another help system format for context-sensitive help pop-ups to work. RoboHelp 6 Server claims to be able to work with that. So if I do upgrade, perhaps I should upgrade to RoboHelp 6 Server?

To Leon: My computer IS networked to my husband's Macintosh, and I'm connected to the Internet (obviously), but the files I am working with are all on my computer's hard drive, not on another networked machine. Are you saying that if I disconnect from the network when I generate printed documentation, this might solve the problem, or were you asking if I was generating printed documentation using files accessed via network to another computer (sorry I'm being so wordy. . .)?

Thank you one and all!

[Peter Grainge]

The X has been dropped. You just need RH6 unless of course you are also generating a WebHelp PRO ouput.

What are you selecting in the dropdown in the last page of the print wizard? Try style mapping and see if that fixes any of your problems.

Post back to let me know if that makes any difference.

[Peter Grainge]

Very often problems with documents arise when using home brewed templates. That does not mean that there is anything wrong with them, simply that there is something about Style Mapping.dot that does not give the problems.

It used to be the case that Word help stated the limit was 32mb and I wonder if you are hitting that? That is no longer in the help but nobody seems to know if that is because the limit has been removed or just the topic! In any case, the size of your document is likely to give problems simply because of the resource requirement generating a document that size, particularly with graphics. I know a bunch of people will jump saying they have larger documents but nonetheless you are in amber territory. It's a bit like tuning a car way beyond its intended limits, you can do it and some cars will work happily tuned that way, but nonetheless you cannot complain if it does blow up.

What I would try is copying your layout so that you have three versions of it. Then delete two thirds from each one. If all three work fine, it sort of confirms that size is a problem. If one fails, your on the track of the rogue topic.

If splitting it does work better, cut and paste would soon get it all back into one document.

[Peter Grainge]

Oops, missed the links bit.

I have no Framemaker experience so hopefully someone else will jump in here.

What I can say is that there is no export to Framemaker layout but I'll make some enquiries to see whether it is on someone's horizon. I know Adobe are working on better integration of these products.

[HKabaker]

In the "old" days, it seemed to take a lot of memory to produce printed documentation. It was more noticeable then because we had much less in our machines to work with.

Which Windows OS are you running? When I had control over the memory-to-disk paging function, I increased the size of disk memory a good bit beyond the Windows default, and my problems with print doc went away.

Harvey

[TechWriterKat2]

windows XP service pack 2 with 2 GIG of RAM. It runs fine on my co-worker's computer running Windows 2000 with less RAM.

[Peter Grainge]

Another post has been raised relating to this problem. See http://tinyurl.com/yvpaut

I am replying here is this is where most of the relevant information is.

****************************************

You found that using the Style Mapping template solved the images problem but the document stopped generating at 450 pages. That was sort of what I hoped for. Rather than go to the step I will suggest in a moment, I suggested you try something else but you never came back to the forum to indicate you had tried it, so the assumption is you did and it worked. Patently it did not so let's try what I would have suggested next.

On my website there is a topic on Print Issues and one of the them covers Malformed Topics. Try looking for <p style="mso-bookmark: as suggested in my earlier reply in this thread. You can try RH's Multi file find and replace but FAR from http://www.helpware.net/FAR may get better results. I think with this error you usually get a message. Do you have the Output pane opened and have you read right through it for clues? View | Output on the menu. Whether or not the Output pane mentions this error, I would search for it anyway.

Other Points:

A] It could still be a resource problem. The document is very large so, as Harvey mentioned, resources come into it. I know the PCs that won't play nicely have good resources but whilst I am no expert in this area, don't foget XP is using more of them leaving less available to you. It could be an issue but I am inclined towards it being something else.

B] I also suggested a hunt for a rogue topic.

"What I would try is copying your layout so that you have three versions of it. Then delete two thirds from each one. If all three work fine, it sort of confirms that size is a problem. If one fails, your on the track of the rogue topic."

Did you try that? Like I said, if all three work fine, then we are back with the resource problem but we will have ruled out other issues. It should take less than fifteen minutes to set that up. Longer to run it but you can be doing something else at that point.

C] On FrameMaker, no real answer but you will soon see evidence that Adobe are continuing to better integrate all the products we are using. I don't think you will see what you want in the upcoming version though.

NEXT:

1] Please search for <p style="mso-bookmark:

2] If that fails, try creating the three layouts.

3] Then post back how it went. If unsuccessful, tell us if the Output pane gave any information about things the process did not like.

Let us know either way as if one succeeds and you post that, it helps the next person with the same problem.

[TechWriterKat2]

Peter,

Sorry if I messed up your holiday. Since this topic started out on a completely different subject, I thought it would be easier for someone else doing a search to look in the title. Blame it on my "newbie forum" status.

Anyway, on to the results:

I split the document into two, and both halves worked fine with no errors. But this causes other time-consuming problems, so it was not an acceptable workaround for me.

I searched for <p style="mso-bookmark, and I didn't find it. I used RH's search engine, and Windows XP Search option.

Harvey, since it didn't fail when I split the book, do you still think it would be helpful to check the memory usage?

One more thing I'm going to try that my boss noticed: Try using it with WORD 2000 instead of WORD 2003. I'm waiting for a machine where I can try that out. Perhaps Microsoft is the culprit?

[HKabaker]

Peter's suggestions are good. I'd focus on the two topics at the quitting point -- the last one to be included and the first one that didn't make the cut. What's the size of the incomplete doc?

When you're generating a big document, it's interesting to watch how RH and XP use memory, with some data in the machine and some paged to the hard disk, and swapping chunks from time to time. You won't see every movement because it's so fast, but you get a snapshot about twice a second.

The OS should automatically manage the size of the paging cache, grabbing more disk space when necessary, but I think there's a user option to regulate the process.

Before you generate printed doc, turn on Task Manager (right-click on the Windows toolbar) and select the Performance tab. Probably RH takes a while to reach the point where it quits, so if you don't want to monitor the rising memory usage, look at the moving graph and numbers from time to time.

Do you see anything that might be a clue?

Harvey

[Peter Grainge]

The Word version idea is certainly worth a try. It's certainly pointing to it being a resource issue, don't you agree. Both halves work fine but not together. Struggling to think what else that could be.

[HKabaker]

I agree. I'd go for system or application software problems. However, a lot of programs get tangled up in unexpected "memory leaks" that have a solution in their source code.

It doesn't cost anything to turn on the Task Manager.

Harvey

[TechWriterKat2]

OK, I just ran it with Task Manager running, and I looked at the graph as it ran. I didn't see anything that clued me in, but maybe I just don't know what to look for. There were LOTs of spikes on the graphs and the numbers did their thing, but it didn't look like anything reached its limit. When the doc finished generating the graphs spiked low, but when MS-Word started paginating the tome, the graphs spiked up again. At the most, CPU used was 60% at any given time, dropping down to 50% the rest of the time with PF (page file?) usage peaking at around 672 MB. The document IS laden with complex images, but the place where it crashed didn't have any of those. Perhaps one of you can clue me in what to look for and/or tell me what would be the next step if we do determine that it's a resource problem. It will be very interesting if it works with Word 2000, but would that mean it's Microsoft's fault, (my boss loves to blame them), and if so, how do we fix it? Sorry if this raised more questions than it answered.

[HKabaker]

Kat,

I'd say memory usage is not the problem.

Can you put your finger on just how much was accomplished before the crash? Is it consistent from one crash to the next? Is it during pagination? Are you including a TOC, Glossary or Index?

Another process to watch is in the !SSL! folder where the Word doc is building.

Normally, in Windows Explorer while RH is running, you should see a printname.doc and a temp folder. Open the temp folder and you should see the directory of project folders, each containing its topic list. You'll also see a bunch of project source files.

A number of temp chapter files appear, named $HtmlDoc_Chapter_abcdefsoiuy.htm,
where abcdefsoiuy is a folder or file at the root directory level.

A printname.trs file contains a running list of processed topics.

The temp folder stays as long as the RH completion dialog remains on the screen, until you click "View Result" or "Done." Then Poof! the temp file is gone. (Maybe this is why it's called the !SSL! folder?)

Right-click and open the .trs file with Notepad or similar text editor. Scroll to the end. What's there?
I was able to open the file before the process completed, but RH output failed at that, which is to be expected. So wait until the end.

On the other hand, when it failed, the printname.doc was just under 25 MB. So maybe that's the limit in Word 2003? Maybe this version of word stuffs the file with a lot of MS Office code that bloats the output? How big is the successful output on the other machine?

Harvey

[TechWriterKat2]

Harvey,

Thank you for continuing to work with me to try to solve this problem!

I'll try to answer your questions in the order you asked them:

About 503 pages were processed in the last crash, and then it processed the index (leaving off the last few chapters). It seems to happen in the same chapter each time, but on different pages -- sometimes it's processed close to 600 pages before it quits, does the index and goes into "view or Done" mode.

I am including a TOC and an Index

I looked at the .trs file, and the last thing listed was a graphic in Appendix A, which occurs several pages AFTER the place where the document crashed, so I don't know what to make of that.

The final document was 3,426 KB. On the slower computer running MS Word 2000, it was 6,268 KB.

I'm still waiting for the new computer running Word2000 to see if that fixes the problem. In the meantime, does the information I provided give you any more clues?

Thanks again,

--Kat

[HKabaker]

Kat,

Looking back over this thread, I was reminded you're using RH X5. I'm using RH 6, so all I can do is guess based on my experience with X5. Sorry.

Here's a flash of an idea:

Do you have the MS Word Autosave feature turned on, as I do? Does the print generator run for approximately the same number of minutes? Monday I'll try turning it off in Word before starting a new print doc.

Interesting that your output works OK with each half, but not the whole project. Makes you wonder about the "malformed topic" message, which I am also getting. And maybe they finish before reaching the Autosave trigger.

It could be a spurious message, meaning that something happened that made the print generator "think" it was malformed. We both have been able to get past the supposedly malformed topics by changing the size of the output.

In my case, I removed a buch of TOC topics, even a whole book or two, near the top of the TOC (print version, not WebHelp TOC). So the topics were still present, but not included in the output. RH 6 breezed right past the point where it had stopped on two previous runs, only to crash again, after about the same amount of time.

Have you tried reducing the size of the output by omitting topics ahead of the crash point?

Factors that make no difference in RH 6:
--Using the style mapping .dot, or letting RH pick up styles from the topics.
--Preserving hyperlinks or not. (Without hyperlinks, I got more pages, but it broke at about 25 MB in the Word doc, which has been fairly consistent.)

Good luck.

Harvey

[TechWriterKat2]

Hi Harvey and everyone,

It looks like WORD 2003 is the culprit, though what to do about it, I don't know. I finally got a machine running XP with MSWord 2000, and the demo copy of RH6. It produced the entire document with no malformed topic messages, and no distorted images. Some of my list numbering was off, but that is a farily easy fix.
So, is anyone else out there using RH5 or 6 with WORD 2003 and a big document successfully? I wonder if there's a Microsoft forum out there that would address this, but I'm guessing not.

[Peter Grainge]

I don't think any Microsoft or Word specialist forum will help as this issue is simply to do with the conversion from RH to Word, an aspect foreign to those forums. There are some people who only follow HATT on Yahoo Groups so you could try there.

[wgmeisheid]

I do not think the problem is Word 2003 itself, but the RH template for 2003. It sounds like the macro process in the template is running out of memory, which can happen when there is not a proper memory refresh in really long processes, which I have run into with my own complex macros. That is why you can do half and half but not the whole document.

Since the template is locked, it can only be fixed by Adobe.

[Peter Grainge]

Interesting thought from wgmeisheid. I think the template being used is the same one in all cases. Follow the link below and you will find templates for different versions of Word. Could be worth a try.

http://kb.adobe.com/selfservice/viewContent.do?externalId=4cf80b20&sliceId=1

[HKabaker]

Peter,

The tech note says this fix is for RH X5.xx only.
But I tried it anyway with RH 6. It made no difference.

The key templates for RoboHTML are PrintDoc.dot and Style Mapping.dot.

The latter has no embedded macros, and appears to be unchanged since 9/21/2002.

PrintDoc.dot was updated in March 2005 for the RH X5 fix. It has several macros.
For RH6, the template macros viewer shows a new one was added to update image hyperlinks.

I can't read most of the gobbledygook with a text editor, of course, but my file comparison tool found a lot of changes from 2005 to RH6 in December 2006.
I substituted a fresh copy from the RH X5 fix download for the one installed with RH6. The so-called malformed topic popped up in the same place.

The "malformed topic" apparently is not a project topic. As I watched the output directory, I saw two files building. There is a temp file with a .doc extension that builds for awhile, and RH appends its contents into the intended print output doc. The temp file is deleted, and a new one starts building.

In my test, the output doc gets to about 25 MB when the error occurs. I think it is one of the temp files that gets "malformed."

That's why the message says,

The Word Document became corrupt when attempting to append a malformed topic: 'topicfilename.htm'

It processed 1,300 or so topics before the error. I let it run through the remainder, another 8,000 or so topics, each generating the error. It got to the end, reported that some chapters were not generated, cleaned up the temp files and left behind a Word doc containing the 1,300 topics in 800+ pages. But no TOC and no images

All of this took about half an hour, while I was getting some real work done.

Let's hope RH 7 doesn't have this illness.

Harvey

A footnote: Before my time, this project was compiled every couple of years manually into more than a dozen subdocuments merged into a Word master document. It was unwieldy, and you couldn't find any small details because there was no Index, just a table of contents.

That's why we switched to an app that generates HTML files from massive databases, with a hyperlink from every significant term to its parent topic, and fed it into RH to get a coherent directory structure, TOC and Search function.

So why am I trying to generate a printed doc now? Because I can't do it, I guess.

[TechWriterKat2]

Harvey,

The symptoms I have are very similar, except the document doesn't fail in the same place everytime. I DO get a TOC and an index, and the TOC obviously doesn't include all of the chapters, it goes from the failed file to the Index and Glossary. The document always stops building chapters anywhere from page 475 to page 525, and then builds the index and glossary, then cleans up and finishes. Have you tested yours with MS Word 2000? It's not really an acceptable fix, but I'm curious.

Thanks,

--Kat

P.S. Does anybody think this is worth posting to Adobe as a bug and seeing if they can fix ir, or am I asking for finger-pointing between Adobe and Microsoft?