This content has been marked as final. Show 25 replies
The two sources are separate so changing one will not update the other.
Explain more about why you have done this and perhaps we can suggest a different approach.
Is it that you need two different outputs from the same source?
The first project is complete. It include all the system of the organization and inside the system, we have all the services of this system.
I really need to have two different project because the needs of a team in the organization is to have only services of 1 system. This second project will be use for presentation at our partners.
N.B.The person in charge to update the complete project is not in the same area then the other team.
It's not clear whether those teams just need different outputs or different sources. You can have one source and many outputs.
You talk of presentations so it could be that just needs a demo the help rather than the RH project.
So if I understand what you said, it's possible to have only one project on two different URL and publish the complete project on the first URL and only a part of the project on the other URL?
A project contains source files, let's say you have 100 topics for the sake of argument.
You can generate two quite separate outputs which can include whichever of those 100 you want. It could be all or some.
So output 1 (which is what I take you to mean the first URL) would contain whatever that audience needs and output 2 would contain whatever the audience needs.
Topics that go in both would be untagged. So anything that ONLY goes into output1 would be tagged output1 and anything that ONLY goes into output2 would be tagged output2. When you generate output1, you would use a build expression of NOT output2. That way the build would contain all the untagged topics and everything not tagged output2, that is the output 1 topics. Read it again, it makes sense!
It's the whole idea of single sourcing. One set of source files that can produce multiple outputs.
If you right click the single source layout folder, you will see you can create additional outputs. Set up two for this purpose then you will not have to keep changing the target folder and build expression.
Create a small test project to try it out.
Single source is how we work and in general it works well, although there is a problem we can't seem to solve with CHM output. If we create two single source outputs, one for the entire help project and one for a subset (not just one chapter, but multiple scattered parts) the resulting chm for the subset contains all the topics and links to external help files that the larger one does.
The smaller output has a different index and glossary and table of contents, and no linked CHMs, yet the resulting output has the index terms from the linked chms of the larger project and all the topics from the larger project. These topics are accessible by searching or via the keywords that get dragged in from who knows where although the table of contents is as expected.
Any ideas on how to get the output chm of the subset to only includes the topics that are actually referenced instead of having everything dragged in?
Hi dmaxx and welcome to the RH community.
Can you give us a little more detail about the subset project. How are you creating it? From the same source as the main project but using build tags?
Yes, new signle source output, different table of contents, different index, different glossary (which, btw, does not work) and using build tags to manage some of the text within the topics. We only include the topics we want in the toc and the toc does not reference any external chm.
The result is that the toc for the sub-project has what we want, but the chm has ALL the topics, the keywords from the partial index plus all the keywords from the chms that are linked in the toc of the "main" project.
Sorry but I am still unclear what you are doing to achieve your sub-project. Are you creating an alternate TOC and Index file, specifying this in a separate window and assigning the window to the SSL?
BTW you can't have an alternate glossary file so maybe you are manually changing this (and maybe the TOC and Index also)?
Regardless of the above, maybe your problems are related to the manner you are using the build tags in your SSL. Can you tell us what you are specifying in your SSL and how the tags are being used?
We defined a second single source layout (now the project has two HTML help layouts). We defined a second TOC, a second Index, a second Index, and a second window. In the single source layout for the "sub project," we specified the second TOC, the second Index, the second Glossaries, and the second window in the content options.
We include some comditional build tags to control some conditional text within the topics.
When the generated CHM is openned, the result is that the TOC is as expected, the Gloassary tab is blank (all gray), the index has the subset of the keywords plus the keywords for the linked chms for the main help (none of these are in the TOC of this output, and all the topics for the main help are included in the chm.
Reviewing the output window confirms that RoboHelp is including all the topics, not just the ones referenced by the TOC/Keywords specified for the single source output.
Thanks for the additional info. So the build tags are applied to the topic content rather than the topics, yes? If so, this will not exclude the topics from the CHM. If you want a topic to be totally excluded from the CHM, just apply the build tag at the topic level.
The glossary issue is I suspect a totally separate problem. Can you display any glossary in any help file?
So in order to exclude a topic, even though it is not referenced, we need to assign a build tag to the topic. Wierd, but ok. How d we exclude the topics from the chms that are not referenced by the toc yet dragged in?
As for the glossary, if we specify the glossary that originally existed (the one the main chm references) that is successfully displayed.
I wonder if dmaxx thinks the TOC controls what topics are in the help? The tags that Colum refers to do that.
dmaxx thinks that what you reference should control what is included since that certainly is the case for printed documentation. I understand what we need to do, although I would like to know how build tags are going to restrict the dragging in references to external chms that are not referenced by the toc since they are in other projects.
Given that we have to flag a large number of topics with build tags, is there a way, other than one at a time, to set these? The only way I can see how to do this is either from the project manager (right-click) or from the topic properties. The options are grayed out on the format menu option when you select one or more topics from the topic list window.
Not weird, logical. Not everyone wants all their topic in the TOC even though they want them in the build. The TOC is just what you want to present as the main topics.
Go to the topic list and use CTRL and click on each topic to which you want to apply the build tag so that it is excluded, then right click and select Properties.
When you generate, create a build expression of NOT yourtag.
Check out this link on Rick Stone's website for information on how build tags control the output.
If you have pages in your TOC that link to external CHMs, build tags will not exclude these from the subset CHM. You will have to remove the reference manually before you compile. Using build tags in this way would negate the need to specify alternate TOCs and indexes as these would be compiled from the topics left in the TOC after the build tags are applied.
As far as applying build tags to multiple topics, go into your topic list, select the topics you want to apply the tags to, right click, select Properties and apply the tags as normal.
Thanks for the multi-select suggestion - that will help a lot.
There are no references to the external chms, that is my point. The main TOC references them as seperate merged projects. The alternate toc does not, yet all the index items are dragged in. I have tried conditional build tags on those and it does not make a difference.
What version of RH are your using? I don't use the latest version but I'm sure you can add a build tag to a TOC entry there. Not sure about merged project entries though.
Anyhow the alternate TOC just substitutes the main project's TOC. It does not filter out the topics. Therefore if you have a sub-project SSL it just uses all the topics in the PROJECT and applies the specified TOC. The alternate TOC does not limit what is in the CHM. So if you have merged projects in the main TOC, they will still be referenced in the project's .hhp file and will be included in the CHM.
Version 7, added a build tag, does nothing.
I have thousands of topics that I do not want in the TOC but those topics do need to be in the build. That's the same for many people who just want the topics that take the user into a particular area.
What version of RH are you using? RH7 allows multiple TOCs for different purposes.
Is this really merged help or a series of CHMs where in the one you are working on you have created your own links to the CHM?
Tell us more about these links. A quick looks suggest a tag can be applied to anything in the TOC.
You are regenerating the help using a build expression excluding these topics? The expression drives what NOT to include.
The TOC editor calls them a merged project (separate tree branch in the TOC). I have applied build tags to the TOC entries in the main TOC for these items, they are not in the smaller TOC at all. I know that build tags are used to exclude, not include.
In the TOC editor any merged projects are shown by a diamond shaped icon. In the output you will see whatever is in the parent plus whatever is in the child.
Are you seeing such an icon in the parent or are you seeing books?
Given that you have RH7, wouldn't it just be easier to create another TOC as a copy and then trash what is not wanted for this build? Then you will tag the parent topics and not need to worry about the child project because it will not be in your second TOC?
Even without RH7 that is precisely what I was going to suggest. Sledgehammer and nut springs to mind.
I don't output a .chm file, however using the FlashHelp (and hopefully FH Pro if I ever figure out the publishing error) I have merged several projects and have successfully conditionalized the TOC per audience. I get confused easily so haveing multiple TOCs bug me. I like it to be one, that's what the tags are for.
And although unconventional, I use tags to include not exclude. A topic or content is either untagged or tagged based on audience. So my build tags are call center, hr rep. So when I publish the expression reads call center and pulls all topics untagged and tagged with call center.
I tag not only the topic (where applicable) but the toc and have never had a problem displaying the correct content for the correct audience. Maybe try a different output? Is it possible the toc in the .chm has issues with understanding the build tags?
PS: I'm dyslexic, but as long as it works..shrug.