Best Practices for Creating CHM Files from HTML Using htm2chmCreating Microsoft Compiled HTML Help (CHM) files from HTML sources remains useful for delivering offline documentation, help systems, and packaged tutorials. htm2chm is a widely used tool (and a family of similar utilities) that automates the conversion of HTML pages, images, CSS, JavaScript, and index files into a single compressed CHM archive. This article covers best practices to produce robust, searchable, and maintainable CHM files using htm2chm, from preparing source files through packaging, testing, and distribution.
Why CHM still matters
Although web-based documentation is dominant, CHM files are still valuable when:
- Offline access is required (air-gapped environments, installers, portable apps).
- A single distributable file simplifies distribution and installation.
- The target environment uses legacy Windows tools that expect CHM help.
- Documentation must integrate with Windows Help APIs or legacy applications.
Preparing your HTML source
- Organize a clear folder structure
- Keep source HTML, images, CSS, JavaScript, and auxiliary files in a logical hierarchy (for example: /html, /images, /css, /js).
- Avoid deeply nested paths; long paths can cause file path length issues during compilation.
- Use relative links consistently so they remain valid inside the CHM container.
- Normalize filenames and paths
- Prefer lowercase or consistent casing to avoid case-sensitivity issues when sources are edited on case-sensitive filesystems.
- Avoid spaces and non-ASCII characters in filenames; replace spaces with hyphens or underscores.
- Keep filenames short and descriptive.
- Use clean, self-contained HTML
- Prefer static, well-formed HTML (HTML5 is fine). Reduce reliance on server-side includes or absolute URLs that require an internet connection.
- Inline small CSS or JS only when it improves portability. For larger styles/scripts, reference local files.
- Ensure character encodings are declared consistently (UTF-8 is recommended).
- Prepare a logical navigation structure
- CHM supports a table of contents (TOC), index, and full-text search. Structure your pages with headings (h1–h3) and consistent titles to improve TOC generation and search results.
- Include a landing page (index.html or default.html) that serves as the CHM’s home.
Designing for CHM constraints
- Avoid unsupported or problematic web features
- Dynamic features requiring server-side processing (PHP, ASP.NET) won’t work inside CHM.
- Heavy use of modern JavaScript frameworks (Single Page Apps) can break navigation and search. Favor static pages or progressive enhancement.
- Certain CSS features or modern HTML APIs may render differently in the CHM viewer (which uses an Internet Explorer–based rendering engine on many Windows versions). Test visual fidelity.
- Simplify complex layouts
- Complex responsive behavior isn’t necessary for CHM’s fixed-window use. Use straightforward, robust layouts that display well at common help window sizes.
- Use relative links for internal navigation
- Use links like ./topic1.html or ../images/pic.png. Absolute links to external sites are allowed but will open externally (and require connectivity).
Configuring htm2chm
- Choose the right htm2chm version and options
- Check your htm2chm implementation’s documentation (command-line flags, GUI options). Common options control TOC generation, index inclusion, default page, and build verbosity.
- If using a wrapper or GUI, ensure it points to your organized source folder and that output paths are writable.
- Create or supply a project file when supported
- Some htm2chm variants accept a project or configuration file describing TOC entries, index terms, default window layout, and filters. Using a project file makes rebuilds reproducible.
- Set the default topic and window
- Configure the default topic (home page) so the CHM opens to the intended starting point.
- Configure initial window size and navigation options if the tool supports it.
- Include TOC (.hhc) and Index (.hhk) files for control
- Generating a custom .hhc (table of contents) and .hhk (index) gives precise control over organization. htm2chm may auto-generate these, but hand-edited files often yield better structure.
- Keep .hhc and .hhk files in your project root and reference them in the build settings.
Optimizing content for search and indexing
- Use meaningful titles and headings
- CHM full-text search and the index rely heavily on page titles, headings, and visible content. Use descriptive titles and H1/H2 headings.
- Add explicit index keywords
- Use an index (.hhk) or in-page meta keywords if your tool supports them. Put synonyms and alternate phrasings in the index to help users find topics.
- Avoid dynamically injected text
- Text added only by runtime JavaScript might not be picked up by the CHM indexing process. Keep important content in static HTML.
Images, media, and binary assets
- Optimize images for size and compatibility
- Use PNG or JPEG as appropriate; keep dimensions and file sizes reasonable to reduce CHM size.
- Avoid exotic image formats; GIF, PNG, JPG are safest.
- Host large media externally
- If your documentation references large video or audio files, consider linking to external files rather than embedding them to keep the CHM small. Ensure external links degrade gracefully when offline.
- Include necessary fonts carefully
- System fonts are preferred. Embedding custom fonts inside CHM is possible but can complicate licensing and portability.
Handling encoding and localization
- Use UTF-8 consistently
- Save all HTML files as UTF-8 and declare the charset in the head. This avoids character corruption, especially for multi-language docs.
- Plan multilingual CHMs
- Create separate CHM builds per language rather than mixing languages in one CHM. This simplifies TOC and indexing and avoids encoding/platform complications.
Building, testing, and validating
- Do incremental builds during development
- Build frequently during content creation to catch broken links, missing assets, and rendering differences early.
- Test across Windows versions
- The CHM viewer and embedded rendering engine vary by Windows version. Test on target Windows versions (e.g., Windows ⁄11 and any older supported platforms).
- Validate links and assets
- Use link-checking tools locally to detect broken internal links before packaging.
- Confirm images, scripts, and CSS load correctly from inside the compiled CHM.
- Test search, TOC, and index
- Verify full-text search returns expected results and that index entries point to correct pages.
- Confirm the TOC hierarchy matches the intended structure.
Troubleshooting common issues
- Broken internal links after compilation
- Ensure links are relative and reference correct paths. Rebuild after correcting paths.
- Missing images or CSS
- Confirm assets are included in the source folder passed to htm2chm. Check for case-sensitivity mismatches.
- Incorrect rendering
- Remember CHM’s renderer may be an older IE engine. Simplify CSS, avoid CSS grid/flex features that rely on newer engines, and use fallbacks.
- Large CHM files or slow startup
- Optimize images, remove unnecessary files, and consider splitting very large documentation into smaller CHMs.
- Security blocking (blocked by Windows)
- CHM files downloaded from the internet may be blocked by Windows. Unblock in file properties or distribute via installer that properly marks files.
Automation and builds
- Integrate into CI/CD
- Add htm2chm to your build pipeline so CHM artifacts are created automatically from source repositories.
- Store project files and build scripts alongside your documentation source to make builds reproducible.
- Use versioning and release notes
- Embed version information in the CHM and in filenames (for example, docs-v1.2.chm). Keep release notes for users.
- Batch processing and incremental updates
- For frequently updated docs, script htm2chm to rebuild only changed sections when supported, or keep modular source to speed up builds.
Distribution and maintenance
- Choose an appropriate distribution method
- For end-users: provide CHM via installer packages or signed executables to reduce Windows security warnings.
- For internal use: distribute through company file shares or intranet with instructions to unblock if needed.
- Maintain a source repository
- Keep the HTML source, .hhc/.hhk files, and build scripts under version control. This ensures you can reproduce builds and track documentation changes.
- Provide update paths
- If your product auto-updates help content, consider hosting the source on an internal server and using small delta updates rather than replacing large CHM files.
Example minimal workflow
-
Organize files:
- /project/html/*.html
- /project/images/*
- /project/css/main.css
- /project/docs.hhc (TOC)
- /project/docs.hhk (index)
-
Configure htm2chm:
- Set project root to /project
- Set default page to html/index.html
- Point to docs.hhc and docs.hhk if custom
-
Build and test:
- Run htm2chm to produce docs.chm
- Open docs.chm, test navigation, search, and rendering
- Fix issues in source, rebuild
Final checklist
- Source files organized and paths normalized
- Relative links only for internal navigation
- UTF-8 encoding across files
- Custom .hhc and .hhk as needed
- Default topic set and readable content
- Images optimized; large media externalized
- Frequent builds and testing on target Windows versions
- Build automation and version control in place
- Distribution plan that handles Windows security policies
Following these best practices will make your htm2chm-produced CHM files reliable, searchable, and user-friendly across Windows environments.
Leave a Reply