Using RoboHelp 7

This information is from the Readme for Robohelp Help 7.0.3 file that is included with the patch. It can be found at C:\Program Files\Adobe\Adobe RoboHelp 7.

- If a user is creating a project with Adobe RoboHelp for Word – Japanese (with patch 7.0.2 installed), project cannot be saved after editing. This problem is not there in non-Japanese products.

- Publishing to Adobe RoboHelp Server 8 is enabled from RH7 after installing this patch.

To fix this problem, you have to re-register the Acrobat PDFMOfficeAddin.dll.

These step are an amended version of Adobe's fix. The method on Adobe's site can fail if a crash has occurred and the PC has not been rebooted.

1. Reboot the PC. Do not open RoboHelp or Microsoft Office.
2. In Windows Explorer, locate PDFMOfficeAddin.dll and note its exact path, which may include spaces. Its default path will be something like C:\Program Files\Adobe\Acrobat nn\PDFMaker\Office\PDFMOfficeAddin.dll where nn is the version.
3. Do one of the following:
   - On Windows XP: Choose Start > All Programs > Accessories > Command Prompt.
   - On Windows Vista: Choose Start > All Programs > Accessories. Right-click on Command Prompt, choose Run As Administrator, and authenticate.
4. In the Command Prompt window, type regsvr32 followed by a space and the path that you noted in Step 2. Enclose the path in quotation marks.
   For example, if using Acrobat 8 and the PDFMOfficeAddin.dll is in its default location, then you would type the following command:
   regsvr32 "C:\Program Files\Adobe\Acrobat 8\PDFMaker\Office\PDFMOfficeAddin.dll"
   
5. Press Enter.
6. A dialog box will confirm that the registration was successful. Click OK to close this dialog box.
7. Close the Command Prompt window.
8. Open RoboHelp and generate the PDF file.

Hurdl1 and Eilan Jung reported that the word after a highlighted word sometimes loses the space after the next word. Here is Eilan's description.

1. First, we generate WebHelp with the Highlight Search Result option enabled.
2. Perform a Search.
3. Click on a topic.
4. Look for the highlighted word. The word after the highlighted word will have a missing space. This occurs only if the highlighted word is formatted (italicized or bolded)
5. Go to the TOC and click on a different topic.
6. Click on the same topic (as in Step 3).
7. Notice that the highlight is removed (since we are not performing a search) and the missing space is back.

We are able to reproduce this with every project, with or without a skin and in IE (not in Firefox. That's a first!)

Adobe quickly posted a change to one of the javascript files. That file has since been updated to fix a few more issues and the equivalent changes have made for FlashHelp users. Both files can be downloaded here. Click here to download a zip file containing both files.

For Webhelp save the relevant whtopic.js file to "C:\Program Files\Adobe\Adobe 7\RoboHelp\RoboHTML\WebHelp5Ext\template_stock\ assuming installation at the default location. (Backup the old copy first.

For Flashhelp save the relevant whtopic.js file to "C:\Program Files\Adobe\Adobe 7\RoboHelp\RoboHTML\WildFireExt\template_stock\ assuming installation at the default location. (Backup the old copy first.

Do not save the same file to both locations. They are not the same internally.

The table lists the fixes in Adobe RH 7.0.2 released on 29th May, 2008 and are from the Readme for Robohelp Help 7.0.2 file that is included with the patch. It can be found at C:\Program Files\Adobe\Adobe RoboHelp 7.

Most of the settings you need to change the appearance of breadcrumbs can be changed within RoboHelp including the colour. However, the range of colours is limited and might not suit. Thanks to Harvey for finding this solution whereby you only have to make the edit once and it will stick within the layout concerned.

Find the SSL file for the layout. Using a text editor, find the line that starts SSBreadCrumbFontStructure. It will vary according to what you have already set up but will look something like this.

SSBreadCrumbFontStructure=0;2;0;Arial;-13;0;0;3;34;1;0;0;400;0;9220;100;255;0;255

The last three numbers correspond to rgb for fuschia, the color Harvey selected for breadcrumbs text.

If you want other undocumented changes, see Snippet 97. Note that with that method you have to do a little bit of behind the scenes swapping of files post production.

In response to a post reporting a corrupt hh file, cindep suggested open the file in Excel and removing the three leading characterss before #topic. I checked with Adobe and was advised as below.

If the .hh or .h file has only ANSI data then this will work but if any UTF-8 data is present in the file, then it will not work. For example, if the file has only English characters then it will work, if the file has English and Japanese characters then it will not work.

Click this link to download two sample pod layouts that I created. Save them to My RoboHelp Projects.

In day to day use, I use the Standard - Flyout layout. It gives me the Topic List in the editing pane so that I get a good view of its content. Most of the pods of visible but the three I use least are flyouts on the left. Easy to use when I do want them but out of the way most of the time.

The TOC layout makes editing the TOC easier.

When you upgrade a project to Adobe RH7, the language will be set to English US no matter what default language you have set in RH. Make sure you change it to what you want in File | Project Settings.

Generate your CHM with exactly the same name as your project. So myproject.xpj means your chm has to be myproject.chm. You can rename it after generation.

This problem was fixed in Build 7.0.2.

A number of Adobe RoboHelp for Word 7 users have reported that they cannot save changes or generate an output. The cause has been isolated to the RHComAdd.DLL being disabled.

Check for that in Word:

- For versions up to 2003 go to Help | About | Disabled Items. If RHComAdd.DLL appears, re-enable it.

- For Word 2007, go to the Office Button | Word Options | Add-ins. Under "Manage" select Disabled Items and click Go. If RHComAdd.DLL appears, highlight it and re-enable it.

Alternatively, you can re-register the DLL. Go to Start | Run and type in the following line, assuming you have installed RoboHelp to the default location.

regsvr32 "C:\Program Files\Adobe\Adobe RoboHelp 7\RoboHELP\RHComAdd.dll"

How does this DLL get disabled? The cause has been identified as a Word document being opened in Internet Explorer rather than in Word.

This problem was fixed in Build 7.0.2.

If you should need to uninstall RoboHelp 7 for any reason after you have applied update 7.0.1, here's the procedure.

If RH7 standalone was installed:

You will no longer see 7.0.0 in Add/Remove Programs. Instead you will see 7.0.1. Uninstall that and then you will see 7.00 and can uninstall it.

If TCS was installed:

You can uninstall that or the RH component but it will leave the patch high and dry, so don't do it that way. Uninstall the patch and then uninstall TCS or the RH component.

The table lists the fixes in Adobe RH 7.0.1 released on 13th February, 2008 and are from the Readme for Robohelp Help 7.0.1 file that is included with the patch. It can be found at C:\Program Files\Adobe\Adobe RoboHelp 7.

The following was posted on the RoboHelp forum:

In RX7, when we post a Webhelp or Flashhelp project to our server, all the French characters (?, ?, ?, etc.) are replaced by the copyright sign and other symbols such as "A".

This was investigated and here's the explanation I received.

RH7 started producing the output HTML files in Unicode (UTF-8) encoding formats. To tell other editors, browsers etc that it is UTF-8 encoded files you do two things.

1. Set the char-set attribute in HTML meta data to be UTF-8. This tells the browsers that the HTML content is UTF-8 encoded.
2. Set the 3 bytes UTF-8 BOM at the very beginning of the file to tell any kind of text file editor that it is UTF-8 encoded file. These 3 bytes are invisible characters so you won't see them in any editor. These are optional bytes and browsers don’t require them to render a UTF-8 encoded HTML file.

A key part of the problem was the fact that the server was a Novell server.

• The RH7 generated output files are UTF-8 encoded HTML files but without the UTF-8 BOM as the browser does not need it.
• The Novell server while reading these files doesn’t understand that these files are UTF-8 encoded without the BOM so they are wrongly displayed.

Other servers could be affected. If the servers are plainly serving the content, then there should be no problem but if the servers tweak the content before serving, then they need to find out the encoding of the file. If the servers rely solely on BOM on finding out the encoding then there will issues.

The user had found that editing the file in some way corrected the problem. The reason for that is that Notepad figures out that it has UTF-8 encoded characters and adds the BOM while saving it. When the user puts back these files, his French characters start working.

The user also found that applying the Mark of the Web fixed the problem. This is because when the user switches on MOTW, RH7 also puts the BOM in the HTML files and it starts working.

Here's some additional information I was sent to help explain the issue.

1. When a browser picks up a local html file it completely relies on what is written inside that html file. It sees that char-set is set to UTF-8 so it renders everything correctly.

2. When a browser picks get a file from HTTP web server it relies on data other than what is written inside the html file. It gets a header information from the server, in that header info encoding type of the data being served is mentioned.>

2.1 If the browser gets encoding in the header as e.g. windows-1252 it thinks that the content of html file is also in that encoding and reads accordingly. It completely ignores the char-set mentioned inside the HTML file. This action of browsers messes up the rendering.

2.2 If you fix it in the webserver to serve UTF-8 content everything becomes alright because browser gets UTF-8 in the header info.

2.3 Browsers have this problem only for HTML files. For XML files they rely completely on what encoding is mentioned inside the XML file.

A small number of people have reported that what look like HTML entities are appearing as characters in the Design (WYSIWYG) editor but with a small error.

An example of this problem was in a project sent to me where opening one topic in a text editor such as Notepad showed Big Box surrounded by quotes rather than showing the HTML entities.

Fig 1:

In RoboHelp:

• The opening quotes should be the HTML entity “ but in both Design and HTML views, the quotes appeared after upgrading as text in the format ”r; Note the extra semi-colon and letter r.
• The closing quotes should be the HTML entity ” and in the code view it is. However it appears as ” in the Design view as well.

Thus what you see in both Design and HTML view is as below.

Fig 2:

Checking back in RoboHelp X5 showed the true code editor did not display these entities but the WYSIWYG editor was able to display the quotes as in Figure 1.

Fixing the problem for this particular entity hit a second problem. Using Helpware's FAR to find ”r;and replace with " to give straight quotes produced no results. However, a search for ” did find that entity. It would appear that different editors see these quotes in different ways. The search for ” was straightforward.

Thus the solution is going to depend on what tool you use. If you use FAR, then search for &rdquor and ”, replace both with "

If you use another tool, try the same searches first. After that it will be trial and error. I have not investigated the other entities reported but it will be a similar situation. This has been reported to Adobe but please report it yourselves. The more people who report it, the quicker it will be fixed.

I believe this problem occurs when the text was created from a Word import or cutting and pasting from Word. My own practice whenever I set up Word is to turn off smart quotes. In HTML they always seem to produce problems.

This problem was fixed in Build 7.0.1.

You may find Shift Enter does not work. Different users are getting different result but CTRL Shift Enter does work.

From command line silently as follows:
C :> msiexec /qn /L* “<Log file>” /I “<Path to RoboHelp MSI file>” USERNAME=<user name> COMPANYNAME=<comp name> SERIALNUMBER=<serial number> EPIC_EULA_ACCEPTED=1 TRANSFORMS=<Product Lang code>.mst

Product Lang code may be any of the following:
English – 1033
French – 1036
German – 1031
Japanese - 1041

The serial number and EULA will also need to be entered by the end user when they first open RoboHelp 7. You may find a post on the Adobe RoboHelp forums suggesting a workaround by editing the cache.db file. I would strongly caution against that as I am told the file is machine specific and editing it can cause all Adobe products to stop running, with the only solution being a reformat of the hard disk!

This occurred if the path length was too long. Adobe advise the length as 65 but I have found, as did the person who first reported this, that the length seems to be 120. The path referred to is not the relative path but the absolute path to the image being imported.

This problem was fixed in Build 7.0.1.

When you import a topic that has images, RoboHelp automatically brings a copy of those images into the project. That is not the case with snippets. I will be doing a bit more research on this but for now it seems that it is necessary to import the snippet manually before you import the topic.

If you don't want the snippet in the topic after import, you will see a blank line in the editor and you can delete that or, my preference, go into the code and delete it there.

If you go into RoboHelp's stylesheet editor and click New Sheet, once you have given the new sheet a name and clicked Create, that style sheet will be applied to the topic that had focus when you opened the stylesheet editor. If that is not what you wanted, then simply go to Topic Properties and change it to the required stylesheet. That is how RoboHelp has always worked.

There was a problem where any changes you made to the new stylesheet would be applied to whatever stylesheet was listed under "Available in" before the new stylesheet was created and the new stylesheet would be empty. This was fixed in Build 7.0.1.

Hopefully you will not encounter any installation problems. Just in case you do though, Adobe have produced Technotes telling you how to start troubleshooting.

Click here for Vista.

Click here for XP.

A few reports appeared that some topics were blank after upgrading. This problem was fixed in Build 7.0.1.

The Customer Care project supplied with RoboHelp 7 contained three topics where the code was not corrected after a bug fix during the beta tests.

You can download a corrected version (English only) below.

Source files only. Generate the output on your PC. 900 KB

Source files and output files. 4.89 MB

Whilst the licensed version of RoboHelp can be be run on Windows 2000, the trial version cannot. At the point during installation where you have to elect to enter a serial number or run the trial, the trial option is enabled but RoboHelp will not install properly on Windows 2000.

Using the Preview icon if you had unsaved changes forced them to be saved without prompting you or advising you. This problem was fixed in Build 7.0.1.

I was sent a topic with some Japanese characters that were fine in the output but in the HTML editor they were represented by squares. As soon as I selected them and applied a unicode font (Arial Unicode MS), they displayed correctly.

If you have the same problem, you need to have the language packs installed and a suitable font applied.

To install the Language Pack on an XP machine, follow these steps:

1) Access Control Panel and then select Regional and Language Options.
2) In the Regional and Language Option Dialog, select the Languages Tab.
3) Check the two boxes below Supplemental Language Support and click Apply.
4) This will require the WinXP SP2 CD

You may find there are then some spacing issues and text on a line shifts when clicked in (in the source files), I understand that a mono spaced Unicode font is required. Sorry I cannot point you to one.

Be very careful of making changes to your TOCs. When you closed previous versions of RoboHelp or started generating a layout, if there were unsaved changes to the TOC, you were asked whether or not they should be saved. You do not get that prompt in RoboHelp 7, the changes are just saved. There seems to be no way of backing out as the ability to force that prompt and then click No has gone.

I strongly recommend that you take backups of the multiple HHC files you will find in the root of your projects.

If you find that when you rename or delete a snippet RoboHelp saves all topics without prompting you, this problem was fixed in Build 7.0.1.

When you delete a snippet, you will be presented with three options:

You can include any text, tables, and images.

You cannot include dropdowns, expanding text or glossary terms. You can include bookmarks but they will not be listed in Project Manager under the topic where the snippet is used. This makes "in snippet" bookmarks difficult to use so I don't recommend that you do. See the separate item Bookmarking Snippets.

When you save text as a snippet or create a new snippet, it will contain the HTML code for the text. What it does not do is save any reference to a style sheet. The idea is that <h1> in the snippet takes on the attributes of the <h1> definition for the topic in which the snippet appears. The same applies to all other tags. That way the snippet is seamless in whatever topic it is used in.

The other reason that there is no style sheet reference is that snippets can be used in topics at any folder level and that would affect the relative path back to the style sheet.

In many scenarios, that will not be a problem but what if you want the snippet to have an appearance of its own? Perhaps a legal disclaimer and you have been told the heading must always be in red. The answer is that you apply an inline style to the snippet. Note that embedded style sheets will not work in a snippet.

If you look at the TOC column in the Topic List while looking at the default menu, users of previous versions might well think it is showing the topics in that menu. Look at another TOC and you will see that column does not change. Look more closely and you might see it says a topic is in the TOC and you know it is not in the default.

Answer: The TOC column now indicates the topic is in one of the TOCs, not which one. To see which TOCs a topic is in, if any, right click over the column headings and turn on the TOC Name column.

Working with snippets I discovered a couple of problems that were relevant to how I often structure topics in my work. Many of the topics have a What's Covered box in common with some of the topics on this site. Within them I sometimes list the sections of a topic and add bookmarks. Trying to do that with snippets I ran into a problem. You cannot add a bookmark to the same line as the start of a snippet. No problem I thought, just put it on the line before and whilst it was not perfect, it worked well enough. But then I hit another wrinkle. In the WYSIWYG editor, you cannot insert a bookmark between consecutive paragraphs, indeed you cannot even insert an ordinary paragraph after you have created you two consecutive snippets. You can do it in the code editor but it can be a bit tricky. I needed to bookmark each snippet, not just the first one so what to do?

The answer took quite a bit of time to identify but ironically it was simple, childishly simple.

Create a special style that goes before each snippet that you want to bookmark. For that reason I called the style SnippetBookmark, cunning egh? Here's the definition.

P.SnippetBookmark {visibility: hidden;}

You select this style before each snippet that you want to bookmark. Then create your bookmark on that line but nothing else, no text. In the WYSIWYG editor you will see an unwanted line but go to preview and it cannot be seen. I tried it with a webhelp. compiled HTML output and a printed document. It worked with all of them.

Oh for 0.5 of a penny or a cent for every word that has been written about Kadov tags. Bill Gates would be my poor relation.

Yes they have gone with RoboHelp 7. When you upgrade a project, all the topics will be swept and the code rewritten. Now that's a good reason for backing up your projects before you upgrade. I am not implying that the cleanup is flawed, simply that I never let any program change a file without backing up first. I might have put something in the file that nobody could be expected to anticipate but that something might just throw the upgrade routine. Better to be safe than sorry.

I tested one project before and after upgrading it from RH6 to RH7.

BEFORE

Source files had 1873 instances of kadov.

Output files had 1314 instances of kadov.

AFTER

Source files had 4 instances of kadov. Investigation showed these were all in one topic and that revealed the instances were list items where no style had been applied. Applying the normal <p> tag and saving the file resulted in 0 instances being found.

The output was then regenerated and 0 instances of kadov were found.

Notwithstanding that, if you do a text search across your project searching on the word Kadov, don't be surprised if you do find some hits. Kadov was a term also used in the javascript used in various parts of RoboHelp but that is not the same as a Kadov tag. Kadov tags were not compliant HTML code, the use of the term Kadov in javascript does not make the code non compliant.

Special Note for Beta Testers. The automatic removal of the Kadov tags only occurs when you upgrade a project from RoboHelp 6 or earlier. Any projects you opened in the betas before this functionality was added in will not be cleaned up.

Previously if you opened your style sheet in Notepad or a style sheet editor, you would have seen lots of Kadov references and apparent duplication of styles. This was what enabled your topics to be rendered in the WYSIWYG editor and it was part of the design of RoboHelp that was established in the early versions. In RoboHelp 7 you will see your styles much more readily but you will also see additional text with LI references. For example, after the P tag definition, you will see LI.P. My first take on that was "Don't mess with my style sheets, I know what I am doing." I took this up with the senior developer and there is in fact a good reason for this.

If you use Dreamweaver, and perhaps many other HTML editors, when you go from a paragraph to a list, the style for the list is defined quite separately. This is best understood with an example.

Let's say you have a paragraph that is 10 point Verdana. That would be defined by your <p> tag definition. Now let's say you want to follow that with a list (bulleted or numbered). In Dreamweaver, the list would be in accordance with whatever you have defined for the LI, OL and UL tags and would not be influenced by the preceding style, unless you apply the paragraph style as well. You have to do that manually.

RoboHelp 7 has a new HTML editor. If the new LI definitions were not there, then the editor would work the same way as Dreamweaver and that is not what RoboHelp users are used to. They are used to lists retaining the style of the paragraph. So what the developers have done is set things up so that when you create a list, it does adopt the styling of the previous paragraph, whatever that may be.

You can remove all the LI stuff from the stylesheet if you choose but be aware you will need to apply the style you want to the list, it will not make assumptions.

Thus it is your choice. RoboHelp 7 has been designed to work in the way you are accustomed to but you can opt out if you accept the Dreamweaver method.

When you attempt to import a Word document into RoboHelp HTML 6, you may encounter a warning "Word can't load SSWord.wll etc" This will only occur if you have opened RoboHelp for Word 7 and the solution is quite straightforward. You need to unregister a dll.

1. With all versions of RoboHelp and Word closed, go to the Run command and enter the following, assuming you installed RoboHelp 7 to the default location. If not, amend the path as necessary.
   regsvr32 /u "C:\Program Files\Adobe\Adobe Robohelp 7\RoboHELP\RHComAdd.dll"
2. Click OK and you should get a message that the DLL has been unregistered.

You will not encounter the problem again unless you open RoboHelp for Word 7 again. If you do, that will register the DLL again so you will need to unregister it before again trying to import a Word document into RoboHelp HTML 6.

If you need to run this command regularly, put it into a file using Notepad and save it with a .bat extension. Double click that instead of putting the command into Run.

This problem was fixed in Build 7.0.2.