Huge .chm file size

[GeorgeChapman]

Last year we migrated from RoboHelp to Flare.

Our main project is a software .chm help system with approximately 450 topics.

The number of topics has not changed much, and while the size of some of the graphics is bigger because of the "Vista look", the .chm that we generate in Flare is much larger than it was when generated in RoboHelp.

For example, our full version is currently 29,532 KB while a previous RoboHelp release fo the same version was only 8,662 KB.

We use a lot of conditional tags and have multiple graphics which are tagged in or out for our various software products.

We use a few variables and about 15 snippets.

I cannot figure out why Flare compiles such a HUGE file.

Are their some settings that I am not using?

I suspect the 'tagged out' content is being retained in the .chm by Flare. A couple of weeks ago I needed to create a demo .chm with only 5 topics. It compiled in Flare at about 25,000 KB. Later I imported the .htm files into a new RoboHelp project and compiled the demo .chm in RoboHelp. Its size was a more reasonable 457 KB.

Does anyone have any suggestions on how to strip the "tagged out" content out of the compiled .chm?

Alternatively, is there another explanation for this HUGE FILE phenomena?

[wclass]

I can't explain the huge file size, but I can suggest a few tests you can do. I have not noticed any such difference on my own converted projects.
First, to ensure that topics that have been tagged as excluded, do a search for them in the CHM.
The next thing I would do is take the output CHM and convert it to source, and then look in the generated files and see if there is anything especially big. If you still have RH installed you can do this by right-clicking on the CHM file, otherwise you can use the HTML Workshop.

[MikeKatz]

Same as Margaret, my converted CHM files were the same size as the RoboHelp versions.

[SteveS]

I'd be looking at the new images for the 'Vista' look - how big (file size) are they compared to the old look?

If that is where your problem lies, check the image size (physical) and file format. For things like .jpg check the file quality. If the image is a graphic, such as a logo, convert it to .gif. All of these things can make a huge difference to image, and therefore file, size.

[RamonS]

Yep, check if you use JPEGs. They have 16 million colours and are huge. GIF or PNG typically do 256 colours and when it comes to screen shots I honestly cannot see a difference. Maybe it is just the Vista look itself. With Vista everything is huge and excessive when it comes to resource needs.

[LTinker68]

GIF or PNG typically do 256 colours ...

Actually, PNG does millions of colors like JPEG as well as has the ability to have transparent areas like GIFs (although the transparent areas don't display in IE6 and earlier).

[RamonS]

Ah, see, I didn't know that. Must have been that the default setting in my image programs always defaulted to 256. In any case, 256 colours is plenty for screen shots.

[KevinDAmery]

That's the beauty of PNG: it can do indexed colour like GIF or channel based colour like JPEG, plus you can define how many bits per channel to use, PLUS it doesn't use DCT compression so you don't get artifacting like you do with JPEG. So by changing the configuration of the file, you can do anything from a pristine photo quality image to a teeny tiny transparent logo.

[MikeKatz]

This is a very useful discussion for me!

I tested using 256-color PNG instead of JPG, and the screen does indeed look the same, and the file is 80% smaller. I just need to test on some more screens, because not all screens are using simple colors, and some could look worse.

There is also another issue, which is a resize issue, and I'd like to ask those who do use screen shots: Do you resize your screens in the help, or do you leave them at full size?

[KevinDAmery]

Depends on the intent of the screen shot. For one of my help systems, I have a screen shot with callouts that identifies the main areas of the interface. I reduced the size of that one so that the screen shot wouldn't be the same size as the application window OTOH, if I need customers to be able to identify a button or pulldown or whatnot, I keep them full size.

[RamonS]

If I do screen shots of the entire screen I may or may not resize it based on the original size, but I typically define various sections of the form and the show screen shots of the individual sections, then drill-down showing entries of the dd lists etc. I think providing it in bite size works out better for everyone.

[MikeKatz]

Kevin, Ramon

I also have smaller sized chunks of the screens, as well as larger ones where necessary. However, I've always resized every screen shot to 80% of the original.

First of all, I don't like having different sizes throughout, because there's no real reason in a help file. For the manual, I will sometimes vary the percentage reduction (usually 70%), to improve pagination or keep two screens together on a page. But in the help file I prefer to be consistent.

The second issue is that with 100% screens, the text is close to the size of the help content text, and I always thought it better to make the screens smaller, so that the text becomes the main element you read.

In a major new project I am going to start on in the near future, I'm considering switching to 100% for help screens, which is why I am asking.

[KevinDAmery]

The second issue is that with 100% screens, the text is close to the size of the help content text, and I always thought it better to make the screens smaller, so that the text becomes the main element you read.

I agree with that idea, provided that what you're trying to do is give users a sense of where on the screen they should be looking. OTOH, if I need them to look at something specific (like the name of a text field, for example) I prefer to keep the size at 100% so that it's easier to read. Some customers don't have 20/20 eyesight, so keeping things large can be helpful.

[LTinker68]

OTOH, if I need them to look at something specific (like the name of a text field, for example) I prefer to keep the size at 100% so that it's easier to read. Some customers don't have 20/20 eyesight, so keeping things large can be helpful.

I'll sometimes create a fly-out type of effect in Photoshop, especially if the screen is fairly large and/or has a lot of fields and buttons in it. So the whole screen will be shrunk down to something small, then I'll show the field of interest at 100% and have a shadowbox extend from the field graphic back to the screen so the user can see the field and see where it is in the screen. I try to keep those at a minimum, though, because they're a pain to update if the screen changes, but it's a useful gimmick in certain situations.

[RamonS]

I also sometimes make full screen shots into image maps so that one can click on a control and get the help for it. It is a lot of work and from my experience not many understand the concept. I just think it's wicked cool.

[MikeKatz]

I don't like doing different things in the help. I like to be as consistent and simple as possible.

For one thing, the user is probably new to the program, and is trying to learn it. To then have to also learn how to use the help, and navigate through different methods of presentation and navigation, etc., doesn't make the help that approachable.

[RamonS]

That is true, which is why I don't use image maps as the only way of navigation. That way it doesn't matter if it is used or not.

[SteveS]

['ll sometimes create a fly-out type of effect in Photoshop,... and have a shadowbox extend from the field graphic back to the screen ...but it's a useful gimmick in certain situations.

And Capture does it very quickly...

[KevinDAmery]

I also sometimes make full screen shots into image maps so that one can click on a control and get the help for it. It is a lot of work and from my experience not many understand the concept. I just think it's wicked cool.

I do that too, although what I do is link the parts of the image to popups instead of other topics. I point out that it's an image map as well by having a bolded line of text above the image saying something along the lines of "click on features of the image below for additional information" so that there's at least a 20% chance a user might realize there's something there