Help & Manual Forums

I am using the skin "Webhelp, Responsive Grey, Keywordslist.hmskin". This is a template with an input field located above the alphabeticel index where users can enter a few letters and then the index is suppost to scroll to the postioin there this entry begins. However, with projects that ...

In recent years, the typical length of help topics has increased significantly due to larger screen sizes and due to the ability to hide irrelevant information with the help of toggles. This sometimes makes it necessary to not only refer to the beginning of a topic but rather to a section within a t...

When linking to another topic, you can use the variable <%TARGETTITLE%> for the link caption, which then inserts the title of the topic you link to only when the document is built. This is an extremely helpful feature that makes keeping links up to date easy. Sadly, many users probably are not aware...

You can work around it by moving the <END> tag to the very beginning of the next (unconditional) paragraph.
However, this is not an ideal and really clean solution. I would also like to learn about a better one if the issue can't be fixed in the software in the first place.

This is most likely due to the fact that your web server uses a more recent version of PHP than Zoom Indexer 8 supports.
Either you need to upgrade to a newer version of Zoom, or you need to have someone adapt the search.PHP file that Zoom uses.
This is independent of Help+Manual.

Having this option really would add a great deal of flexibility to Help+Manual. It could be: something like the "Insert HTML Code" function a special kind of snippet a special kind of topic It would be best if Help+Manual could automatically pick up the most recent version of the Markdown ...

I use the open source tool AutoHotkey for this purpose. It has the great advantage that it works globally in all programs, not just in Help+Manual. You can find more information and the necessary script code here: https://www.indoition.com/en/products/autohotkey-scripts-for-technical-documentation.h...

It is 3 Help+Manual projects: one German, one English, one French. Each of these projects is in its own folder. Within each folder are also the subfolders where the output files are to be stored (eWriter and PDF; the problem occurred with the eWriter files in particular). The projects are published ...

We have 3 languages of a documentation, residing in 3 different folders. So it is 3 different Help+Manual projects in total (DE, EN, FR). There were never any problems before, but now when we open these projects at the same time and publish via the Task Manager (2 versions and 2 formats in each lang...

Thanks for the fast fix

(The following looks like a bug that came with one of the most recent releases. In former versions, this never happened.) If there is an anchor within a paragraph, when you publish to PDF this adds almost one extra empty line on top of the paragraph. In body text this may go unnoticed for a while, b...

Thanks Tim, I see the reason. Maybe then it would be a good idea to prohibit adding comments in the heading in the first place? Just a suggestion so that no important information intended for reviewers can get lost in the process..

It seems that comments that are placed within a topic title are ignored when publishing a PDF with the option "Publish PDF for Peer Review" switched on. Is this a bug or is there any option to enable this?

To be able to use a particular JavaScript library, I need to add IDs to heading elements. The result in the HTML code of the page should be something like this: <h2 id="myidvalue">Hello world</h2> When I add the ID in the XLM editor, Help+Manual removes it when saving the file. Is there an...

Thanks for shedding some light on this