Republish one or two topics

Question about updating 1 topic that may be on 3 or more different published RoboHelpHTML projects or about maintaining multiple versions of a book

As far as I can understand RoboHelp (using version 8 today) to publish HTML?WebHelp, I can create conditional text to HIDE/EXCLUDE certain features.

However, if I want to publish changes to 1 or two topics how would I go about doing that rather than republishing the whole project?

Situation:

patch release(s) that involve changes to

1) Feature List

2) Install script names

If these changed items affect 4 topics (not the other 300), how would YOU go about pushing the updates to the published help locations?

I'm aware that RH publishes ALL topics EXCEPT those I exclude. How do I limit the update to ONLY 2 TOPICS?

For example, the contents of a script file changes and it affects numbered procedures and/or tables...enough that it's messy to revise the HTML on the production web server. And it affects the help for V1, V2, V5 (but not V4).?Do you make a COPY of a topic, edit it, publish it to a bogus location and then replace that .html file on the publication server?

How do you manage multiple copies of feature lists or 'backwards patch' a poorly written topic?

Republish one or two topics

There are two stages to updating the output, generating and publishing. Generating is done locally and RH starts by deleting all that is in the folder and creating new content. Publishing is a bit different, there is an option to only publish changed files but that will not be just the topics you have edited, it will also be some internal files.

The whole process does not take long so it shouldn't be an issue.

---

See www.grainge.org for RoboHelp and Authoring tips

Republish one or two topics

Peter (et al), I want to update 1 topic in a previous publication...but I don't want all my changes to be added.

In other words, I have published 300 topics for versions 1.0

With version, 2.0, I added 25 more topics and updated 100

With version 3.0, I deleted/renamed certain topics, updated all topics.

Now I want to change the contents of a single topic, but in all 3 versions.

Obviously, I cannot just ''publish'' to the production server location(s) because I'll overwrite hundreds of topics with content that does not pertain to versions 1 or versions 2.

How do I do that?

Second scenario: How do I handle a Revisions in this Release topic? It may be cumulative:

V. 1 had 10 features

V 2 fixed certain defects, removed one feature and added 2 new ones

...etc.

When you start work on the help for Version 2 of a product, you need to keep a copy of the source files for Version 1 for precisely this scenario. Likewise with every version of the help you issue.

Do you have an old?backup you can access? If not, if all versions of the help have been produced using the same version of RoboHelp, then you might be able to update existing topics via the back door. You would update the topic in the current source files and then manually copy the topic to the old version. However, if the version of RoboHelp has changed, then the coding might have changed too and things might not work as required. All you can do is rename the original version so that you can reinstate it if needed.

Does that help?

---

See www.grainge.org for RoboHelp and Authoring tips

Thanks Peter,

You've confirmed my 2 workflows:

1) ''the backdoor'' -- edit the raw HTML. This can be complicated if you want to add a row to a table.

2) update topics in the current project, publish, and manually move individual topics into the previous published help.

I'm well aware of the limitations regarding javascript for TOC and cross-topic references; nonetheless, it would be a GREAT feature to be able to republish selected topics without changing the TOC.

One more point:

I have source files (in RoboSource...and now use SVN); however, the process of grabbing source files (100-200 topics) from older versions of RH (X5 or 6) converting to RH 8 and republishing would be grievous, esp. if only 3 topics were affected.

In my opinion, the usefulness ''old source files'' is...not very high.

Give me a moment to add that to the list of reasons I don't use a formal source control system.

---

See www.grainge.org for RoboHelp and Authoring tips