How to limit the number and size of WebHelp output files

[Sharon_G]

Hi,
I'm creating WebHelp and am in the experimental stage of creating a skin with our company look-and-feel and trying to figure out which files in the WebHelp output are really necessary. Is this documented anywhere? I've looked in the Help and have tried to search these forums (tried being the operative word since I have no idea what to search on and anything I try gets no results ).
Enough whining!
I have a single project from which I generate multiple Help systems. It seems like the output file takes every single topic in the project, even if it is not part of a particular Help, and dumps them into the output folder. It appears to do the same for all of the graphics files and icons - those that I have created and those that come from the Default directory in Flare 4.2.
I have also been experimenting with different skins in the same project - and all of the skins end up in the output file for every Help system that I generate - even though the WebHelp is only configured to use a single skin.
As you can imagine, this makes for huge and unweildy WebHelp. Even when items have been deleted from a skin, their related components keep showing up.
Is there any way to limit the files that end up in the output?
Alternatively, is there any documentation of which files can be manually deleted without causing harm to the project? (Manually deleting would be a huge pain, but better than nothing.)
Any and all possible solutions gratefully received.
Thanks,
Sharon

[RamonS]

As you already noticed, Flare includes everything by default. You can use conditions to exclude topics. Conditions should be applied to the topic and the ToC entry (may work with only one or the other, but making sure to cover everything won't hurt). In the target you can then select which conditions you want to exclude. Also, by default any file included in the project folder will end up in the output, for example image files or pdfs that are not linked to anything. So if you find a lot of stuff that is no longer needed you may need to do some housekeeping. If that doesn't take care of things check any links that point to the to be excluded topics. Depending on which Flare version you use a link will cause a topic to be included although conditions said to exclude it. That changed in some Flare version and a smarter approach was taken (remove the link).
There may be other approaches. I never dealt with help projects that needed such partitioning. I am sure others will share their knowledge in a matter of hours.

[wclass]

For generating multiple outputs you need to look at conditions. Unless something is excluded specifically in the build, it will be copied to the final output. This is an advantage for including pop-up only topics that are not in the TOC, BUT it means you have to put conditions on everything and include/exclude topics in your target.

For skins there is more of an issue. They are all included no matter what - this is a problem if your skins are for different companies. I think a few people have put in feature requests to change this. You can remove the unwanted skin folders from the output once you have generated, but you have to remember each time.

Also with skins in the past I have used a text editor to remove old icons etc. as information about resources remained in the skin project file. I have not had to do this for several Flare versions, but it is worth looking at the code to see if editing can still help.

[SteveS]

...I think a few people have put in feature requests to change this...

And remember; the more that ask, the more likely it is that the request gets looked at

Add your voice here.

[GregStenhouse]

For skins there is more of an issue. They are all included no matter what - this is a problem if your skins are for different companies. I think a few people have put in feature requests to change this. You can remove the unwanted skin folders from the output once you have generated, but you have to remember each time.

In another post, Madcap hinted that an enhancement for v5 was the ability to condition files in the Project folder. So this should be possible soon!

[Sharon_G]

I just finished testing and retesting with the help of all the great information contributed above. I documented what I did for my team, so I figured I'd share it here as well. It repeats some of what has been included above, but it ties everything together and answers some of the unanswered questions that I had and that others may have as well:
Minimizing skin files
Remove all Skin (flskn) files except the one you intend to use. You can swap skin files in and out as needed, just remember to update your target.
Because all skins are pulled into the Output, and pull their graphics along with them, a single skin for which the graphics have been minimized is best. You do not need the "Default" skin (I tested this) the underlying skin CSS (Catapult skin) will pull what it needs from the MadCap Flare Resource files.
Minimizing Image Files
Open the .flskn file in Textpad and delete all of the Resources (graphics files) that are not used by the skin. The Resources represent all the graphics files that you add to the skin through the Styles tab in the Skin Editor. If you have been experimenting and adding and removing graphics from your skin, they are not removed from the list of resources in the file unless you do it manually. As a result, if the graphics are still available, they will be pulled into the output whether the skin uses them or not.
In the Output folder, the images that you added through the Styles tab appear in the following location: WebHelp\Data\<Skin name>;
For image files that appear in the skin but that cannot be altered through the Styles tab in the Skins Editor, these files are located in the following folder(default location):
C:\Program Files\MadCap Software\MadCap Flare V4\Flare.app\Resources\WebHelp\Default.flwht\Images
I made a copy of the Images file and renamed it for storage purposes in case I need any of the images in the future (or have to figure out the names of the ones I need to change). In the Images folder, delete all of the images that are not used by your skin. To make changes to any of these images for your skin, you simply replace the image in the folder with one of the same name that looks the way that you want it to. The name and file type must remain exactly the same.
Unfortunately there doesn't seem to be any documentation on which images are used by which xml, js, css, or html files - so there is some trial and error involved. Fortunately many of the files are named clearly, which minimizes the guesswork somewhat.
In the Output folder these files appear in the following location: WebHelp\Skin\Images.
Minimizing Contents files
Unless you conditionalize the files in the Contents folder they are all pulled into the WebHelp Output. If you are already using conditionalization to make sure topics are included in or excluded from our output, this should be fairly simple. The only case where I could foresee a problem is if you have common topics that are not conditionalized, but which you exclude from your output by means of the TOC (that is, they are not included in the target TOC). These topics will be pulled into the Output unless you specifically exclude them by assigning a condition and excluding it from the target output. This is a nuisance and I believe that Madcap plans to address it in the future.
Also note that if, in an attempt to reduce the size of your output, you delete topic files manually from the output's Content folder, the topic titles will turn up in your Help if they contain a relevant search term, but selecting the title will result in a blank topic.
Good housekeeping is also important here. Cleaning out the Images folder ensures that only the files that are used in the target make it into the Output folder. You can also conditionalize the images if they are used in the project but not by the WebHelp target. The same also applies to stylesheets if you use more than one.

Hope this helps.
S.

[NorthEast]

The only case where I could foresee a problem is if you have common topics that are not conditionalized, but which you exclude from your output by means of the TOC (that is, they are not included in the target TOC). These topics will be pulled into the Output unless you specifically exclude them by assigning a condition and excluding it from the target output. This is a nuisance and I believe that Madcap plans to address it in the future.

I'm not really with you on that one, if you don't want those topics in a particular target output, then that's the whole point of using a conditional tag, so that you can exclude that content from the target (without breaking everything). Deleting files from your output is bad practice and just asking for problems, those topics will be in your search and index results and you'll have potential broken links.

And it's not that much effort to do really, in fact fiddling around and deleting files from your output will take just as much time as it'd take to apply a condition tag to those topics.

[panda]

I just finished testing and retesting with the help of all the great information contributed above. I documented what I did for my team, so I figured I'd share it here as well. It repeats some of what has been included above, but it ties everything together and answers some of the unanswered questions that I had and that others may have as well:
[...Hope this helps.
S.

Thank you Sharon, it was very helpful.

I'd just compiled a test project using WebHelp AIR and was astounded at the extraneous stuff which was added in.

Whilst I fully accept that conditions should be applied to topics, I had expected that only the skin I had associated with the output would be included. It does seem back-to-front logic to have to exclude stuff you haven't included in the first place!
Panda

[Sharon_G]

The only case where I could foresee a problem is if you have common topics that are not conditionalized, but which you exclude from your output by means of the TOC (that is, they are not included in the target TOC). These topics will be pulled into the Output unless you specifically exclude them by assigning a condition and excluding it from the target output. This is a nuisance and I believe that Madcap plans to address it in the future.

I'm not really with you on that one, if you don't want those topics in a particular target output, then that's the whole point of using a conditional tag, so that you can exclude that content from the target (without breaking everything). Deleting files from your output is bad practice and just asking for problems, those topics will be in your search and index results and you'll have potential broken links.

And it's not that much effort to do really, in fact fiddling around and deleting files from your output will take just as much time as it'd take to apply a condition tag to those topics.

Hi Dave,
I'm sorry if I wasn't clear but I think we are in violent agreement here. I understand the point of using conditional tags and was definitely advocating in that direction. However, I learned conditionalization through FrameMaker and RoboHelp and the prevailing wisdom was always to conditionalize "in" rather than to conditionalize "out". In RH, if a topic is not conditionalized it is automatically included. In Flare you not only have to include the topics you want to appear, you have to explicitly exclude those that you do not want to appear. It is a change of paradigm that I was trying to get my head around and mentioned for those like me who are recent RH/Frame to Flare converts.

I completely agree that fiddling around with deleting files from the output is not the way to go - in fact I said so later in my post, along with a comment about the info continuing to appear in the Search etc.
Thanks for helping me to clarify my point.
Sharon

[Sharon_G]

For panda - according to Paul Pehrson's new review of Flare 5.0, one of several great updates to the software is that we will be able to conditionalize the contents of the Project Organizer (skins included). this is a great improvement and shows how well the folks at MadCap are listening to the users.

[NorthEast]

In RH, if a topic is not conditionalized it is automatically included. In Flare you not only have to include the topics you want to appear, you have to explicitly exclude those that you do not want to appear. It is a change of paradigm that I was trying to get my head around and mentioned for those like me who are recent RH/Frame to Flare converts.

You don't actually have to include topics that you want to appear; if a target condition isn't set to be included or excluded, it is included. So Flare will ignore a condition unless you tell it what to do with it.

[LTinker68]

And include takes precedence over exclude, so if you have a conflict between conditions, the include will win.

[KevinDAmery]

To clarify the Flare rules:

* If no Condition is applied: object is included, regardless of whether it is in the TOC or not.
* If Condition is set to Exclude: Object is excluded.
* If both Include and Exclude conditions are applied: Object is included (because "Include" always trumps "Exclude")

* If object is Excluded in TOC but no conditions applied in Content Explorer: the object does not appear in the TOC but is included in the build (this is useful if you want the object to appear in search or as a popup window, but not in the TOC)
* If object is Excluded in the Content Explorer: the object is excluded from the TOC and the build

HTH

[LTinker68]

* If no Condition is applied: object is included, regardless of whether it is in the TOC or not.

Unless you're building print output; topics have to be in the TOC in order to be in the print output.

[KevinDAmery]

* If no Condition is applied: object is included, regardless of whether it is in the TOC or not.

Unless you're building print output; topics have to be in the TOC in order to be in the print output.

True, but I figured since we're in the Webhelp forum....

[LTinker68]

True, but I figured since we're in the Webhelp forum....

That would imply that I paid attention to which forum we're in and/or looked at the post title. That's kind of asking a lot, you know.

[KevinDAmery]

True, but I figured since we're in the Webhelp forum....

That would imply that I paid attention to which forum we're in and/or looked at the post title. That's kind of asking a lot, you know.

You mean we can't hold MVPs to a higher standard? What is this world coming to....

[dlogan]

Hi
I have a slightly different twist on the same problem - can anyone help?
I generate webhelp and PDF output from one project. We have alot of screenshots in our print-output, but they are 90% excluded from our webhelp output using the print-only condition within the topics
Problem: ALL my images still show up in the Web Help Output folder: Output\logand\User Help\Content\Resources\Images, even though 90% are not used in this output. This contributes to the huge size of our web help output (50mb + when it should be about 8mb tops). Why are they there at all?

[LTinker68]

Are you conditionalizing the image in the topic or the image file itself? If you conditionalize it out in the topic then it'll still be included in the output because it doesn't know you don't want to use the image elsewhere, it just knows you don't want to use it in that particular topic. If you don't want something (topic, image, etc.) to appear in the output at all, then you conditionalize it at the file level. So in this case, you'd want to go to the Resources\Images folder (or wherever your images are saved), right-click on the image file, select Properties, then apply the print only condition, which I'm assuming you have excluded from your WebHelp output.

Or, to make it easier, I separate my print-only images into a sub-folder under Images called printOnly (had to work to think of that name) then I applied the print only condition at that folder level, which means all its contents also have the print only condition.

[rpineger]

For image files that appear in the skin but that cannot be altered through the Styles tab in the Skins Editor, these files are located in the following folder(default location):
C:\Program Files\MadCap Software\MadCap Flare V4\Flare.app\Resources\WebHelp\Default.flwht\Images
I made a copy of the Images file and renamed it for storage purposes in case I need any of the images in the future (or have to figure out the names of the ones I need to change). In the Images folder, delete all of the images that are not used by your skin.

I can't delete or change anything in the Program Files folder. Flare checks that everything is there each time it starts and reinstalls the deleted images. All of them always appear to turn up in the WebHelp output. Is there another way to prevent this? Filecount is a problem for us because we're using an automated build tool that then checks all the files into version control - more files = more time - and we have 10s of help systems. 42 minutes and counting...

R

[Sharon_G]

Hi R.
I just checked and you are right - I could delete the images in version 4.2, but not in 5.0 - but in 5.0 they don't appear to be included in the Output Data folder, so my problem seems to be solved behind the scenes. I'm mainly concerned with the size of my output files, not the number of files in my project, but I can see how this would be a problem for you with your build tool. Is there any way to tell the build tool to skip a particular folder when it builds?
sorry if this is not much help.
S.