Exit
  • Global community
    • Language:
      • Deutsch
      • English
      • Español
      • Français
      • Português
  • 日本語コミュニティ
  • 한국 커뮤니티
0

international HTML Help does not compile

Guest
Mar 20, 2008 Mar 20, 2008
We imported a simple Russian-language Word document into RoboHelp 7 HTML.
Everything works quite well, and we generally get the expected/desired results.

When are able to generate output for all standard Single Source Layouts, except for Microsoft HTML Help (which, coincidentally, is the one SSL that we actually need).

From the Output View, it looks like the Microsoft HTML Help Compiler 4.74.8702 is having problems with the Russian characters in the file and/or topic names. It seems to "convert" the Russian characters to (extended) ASCII characters, and then reports error HHC5003 and "Compilation failed while compiling <extended-ASCII file name> for each file (except for one file, which as US-EN characters).

At first, we forgot to change File > Project Settings > Language to Russian (Russia), which resulted in an error message dialog for SSL = Microsoft HTML Help. This makes us wonder: would it not be possible to mix, e.g., English and Russian text in the same project? For example, exerpts from English publications as-is in Russian help?

Anyhow, we are guessing that somehow the Microsoft HTML Compiler is not happy with the Unicode characters in the file and/or topic names that RoboHelp is passing to it. I suppose that we could play with the various Regional/International settings in Windows (XP). However, we assumed that this would not be necessary to edit and compile help documentation in RoboHelp. Also, only HTML Help is affected, and the other SSLs are fine.

Any help will be greatly appreciated, as always!
1.6K
Translate
Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Expert ,
Mar 20, 2008 Mar 20, 2008
You can mix languages. Whatever you define in the project settings drives the sort order of the index and how the search works. Basically if a keyword is one starting with a character not in the chosen language, it will drop to the bottom of the index.

Also it is very important that you have the 7.0.1 patch applied.

Help others by clicking Correct Answer if the question is answered. Found the answer elsewhere? Share it here. "Upvote" is for useful posts.
Translate
Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Guest
Mar 20, 2008 Mar 20, 2008
Peter,

thank you very much for your quick reply.

I understand what you are saying, and it makes sense, however for HTMLHelp, we are seeing different (perhaps buggy?) behavior.

We imported a Russian Word document into RoboHelp, and it seems that nearly all Russian characters are non-ASCII. When we import the Word document, and we use Russian characters for the project / file name, RoboHelp crashes when first opening the imported Russian Help project. If we use ASCII characters, then RoboHelp is fine.

We can compile all Single Source Layouts, except Microsoft HTML Help.

By default, in Project Settings, the Language was set at English (US). When we compile HTMLHelp, we get a Html Help Settings dialog box that states "Html Help settings has unsupported characters for the choosen (SP!) language. Do you want to continue? Yes No" Chosing "Yes" results in a CHM file where al the characters in the Table of Contents are question marks (?) and none of the help topics is actually displayed ("The page cannot be displayed). The HTML compiler reports error HHC5003 ("URL reference in the TOC cannot be resolved: "????????.htm"."). If we select "No", then no CHM file is generated.

Now, if we change in Project Settings the Language to Russian (Russia), then none of this happens. Yup. Indeed. Makes no sense, eh!?

Before I continue, keep in mind that everything in this project (except the main project / file name, which is in ASCII characters) are in Russian characters. This includes topic titles, etc. By the way, the image file names are ASCII too, since they are just the image###.gif that the Word import wizard generated.

Anyhow, if we now compile HTMLHelp, we do not get that dialog box anymore. Instead, the compiler reports warning HHC4001 ("The following alias line does not contain an '=' character separating the topic IDs: ."), then displays the Russian-character file names with extended-ASCII (Western-European) characters such as "Êðàòêèé_îáçîð.htm", and then ... huh!?!?! NOW IT WORKS ALL OF A SUDDEN!!! WE HAVE A RUSSIAN CHM FILE!!!

Wow, I have no idea what I did to make it work all of a sudden. Well, persistence with repeated trial-and-error I suppose.

We will investigate some more, to figure out what changed (to avoid this problem in the future).

But in any case, the issue with Project Preferences > Language is still valid.

Thanks so much!

Translate
Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Expert ,
Mar 20, 2008 Mar 20, 2008
Are you using a unicode font such as Arial Unicode?

Help others by clicking Correct Answer if the question is answered. Found the answer elsewhere? Share it here. "Upvote" is for useful posts.
Translate
Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Guest
Mar 20, 2008 Mar 20, 2008
Hmmm, not knowingly, no.

Is this required? I thought that as long as the Windows application (RoboHelp) application supports Unicode, then the users do not have to worry about which font to use (i.e., any available font will do). This seemed to work, since the international characters do appear in RoboHelp, and the Single Source Layouts (except HTML Help) work fine.

Since the problem seems to be the characters in the file names, I am not sure how the font selection could be to blame.

But perhaps we are on the wrong path, and your are (likely!) on the right path...
Translate
Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Expert ,
Mar 20, 2008 Mar 20, 2008
LATEST
For unicode to work, the font has to be a unicode font.

Help others by clicking Correct Answer if the question is answered. Found the answer elsewhere? Share it here. "Upvote" is for useful posts.
Translate
Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Resources
RoboHelp Documentation
Download Adobe RoboHelp