All, I have an open ticket with Adobe Support for the invalid characters issue that was fixed by Adobe for Adobe 8 and 9 with a patch. For some mysterious reason known only to the Adobe gods, their R&D did NOT include the patched fix in the new and improved Adobe RoboHelp 10. As a result:
When you generate Webhelp (running RoboHelp 10 on Windows), the JavaScript files in the RoboHelp output include the invalid characters  at the beginning of the generated XML, html, as well as the JavaScript files. These characters completely break the Help when installed on UNIX machines (and I would assume on any server), even though the Webhelp compiles and displays correctly on Windows. We know that Adobe does not support RoboHelp on UNIX or any OS other than Windows and this is not going to change. We have to find our own solutions to display Webhelp on UNIX.
Also mysteriously, these characters  do not appear in text files or any of the files you find in your generated Webhelp SSL! directory until you do one of these things:
1. Open the JavaScript, XML, or html files in the PSPad HEX Editor. However, you cannot edit the generated files even though you can see the errors since Adobe discards changes to generated files.
2. Your engineers use the Webhelp output in scripts they run on UNIX to install the help on UNIX machines.
Our Tech Pubs team found that by copying all the generated WebHelp output from your Windows machine (where you have RH 10 installed) to UNIX (first copy) and copying them again to another directory (second copy) strips all the invalid characters. Copy them back to the directory from where you will run the Help. Again, for some odd reason, you have to copy the stripped files into another directory--when you look at files during the first copy process, you will see that the invalid characters are still present. So for double insurance against the characters, we do the second copy back to Windows, and then do a third copy to the UNIX directory where they need to be. I hope you can feel our pain, Adobe!
While our partial fix strips the invalid characters, the help does not display properly in Firefox on UNIX. The Contents (TOC) panel does not display the TOC, and the Index and Search functions appear to work (typing in words does not fetch anything). The help text displays so the user can at least read or browse through the help. See Figures 1-3 below.
Adobe needs to sit up and take notice of this one and issue a patch ASAP!
My sympathies to everyone using RH 10. Please post your own solutions if any.
Su Piercy
Sr. Technical Writer
JDSU
Colorado Springs
Figure 1: Broken Contents Panel in Firefox on UNIX
Figure 2: Index Display in Firefox on UNIX
Figure 3: Search Display in Firefox on UNIX
Message was edited by: lipikar11
8
Replies
Before having a pop at Adobe and sympathising with Rh10 users, it would have been nice if you had allowed time for a response.
Whilst Rh itself is not supported on Unix, WebHelp works just fine. See the RoboHelp Tour on my site. http://www.grainge.org/pages/authoring/rh_tour/index.htm That is sitting on a Unix server. This is what I was advised by the company hosting my site.
****************************************
"I would therefore conclude that the solution to this problem (on Linux systems running Apache) is to add the AddDefaultCharset utf-8 directive to either the Apache config or the site .htaccess file. The advantage of the latter is that it only affects individual sites. The default Apache character set is taken from the locale file on Linux and defaults to iso-8859-1. It is the conflict between the Apache header with iso-8859-1 and the page character set of utf-8 that obviously causes Firefox a problem."
In a forum post Chrissy_Tissy added
My machine is Windows, but this fix still worked - some notes about making the fix visible:
- Do the fix itself (httpd.conf: AddDefaultCharset utf-8).
- Restart the box to apply the fix.
- Once the box is restarted, clear your cache in FireFox to make sure you don't continue to see the cached file.
Once all this is done you will see the output content as expected.
****************************************
There is another option that may help that is built into Rh10.
Let us know if those options solve this problem for you.
See www.grainge.org for RoboHelp and Authoring tips
It's not so much sensibilities about Adobe, I just hate it when someone is found guilty before the case has been proven.
The invalid characters are in fact what is known as the Byte Order Mark. Why they are there and why it upsets Firefox, I don't know but the problem does seem to be with Firefox only so who is guilty?
Also Adobe had provided a solution by allowing different encoding to allow the outputs to work with whatever encoding web administrators decided they wanted used.
Let's hope one of those solutions works for you. Let us know.
See www.grainge.org for RoboHelp and Authoring tips
Thanks much Peter for helping resolve this issue. Our engineer says that fix #1, adding the charset to the Apache httpd.conf file and restarting Apache. He did not restart the machine entirely because HP-UX takes a while to restart...could this be the issue? Here is his note and I have attached the screenshot he sent--there are 2 errors in red at the bottom of the picture that don't make sense to me.
================================================================
Hi Su
I add another line into httpd.conf and restart the apache service. It seems the fix doesn’t work, no help on the “Content” issue. Is this related with the “Not Found ” issue in the capture?
/opt/hpws/apache/conf/httpd.conf
AddDefaultCharset ISO-8859-1
AddDefaultCharset utf-8
#
# Commonly used filename extensions to character sets. You probably
# want to avoid clashes with the language extensions, unless you
# are good at carefully testing your setup after each change.
# See http://www.iana.org/assignments/character-sets for the
# official list of charset names and their respective RFCs.
#
AddCharset ISO-8859-1 .iso8859-1 .latin1
AddCharset ISO-8859-2 .iso8859-2 .latin2 .cen
AddCharset ISO-8859-3 .iso8859-3 .latin3
AddCharset ISO-8859-4 .iso8859-4 .latin4
AddCharset ISO-8859-5 .iso8859-5 .latin5 .cyr .iso-ru
AddCharset ISO-8859-6 .iso8859-6 .latin6 .arb
AddCharset ISO-8859-7 .iso8859-7 .latin7 .grk
AddCharset ISO-8859-8 .iso8859-8 .latin8 .heb
AddCharset ISO-8859-9 .iso8859-9 .latin9 .trk
AddCharset ISO-2022-JP .iso2022-jp .jis
AddCharset ISO-2022-KR .iso2022-kr .kis
AddCharset ISO-2022-CN .iso2022-cn .cis
AddCharset Big5 .Big5 .big5
# For russian, more than one charset is used (depends on client, mostly):
AddCharset WINDOWS-1251 .cp-1251 .win-1251
AddCharset CP866 .cp866
AddCharset KOI8-r .koi8-r .koi8-ru
AddCharset KOI8-ru .koi8-uk .ua
AddCharset ISO-10646-UCS-2 .ucs2
AddCharset ISO-10646-UCS-4 .ucs4
AddCharset UTF-8 .utf8
# The set below does not map to a specific (iso) standard
# but works on a fairly wide range of browsers. Note that
# capitalization actually matters (it should not, but it
# does for some browsers).
#
# See http://www.iana.org/assignments/character-sets
# for a list of sorts. But browsers support few.
#
AddCharset GB2312 .gb2312 .gb
AddCharset utf-7 .utf7
AddCharset utf-8 .utf8
AddCharset big5 .big5 .b5
AddCharset EUC-TW .euc-tw
AddCharset EUC-JP .euc-jp
AddCharset EUC-KR .euc-kr
AddCharset shift_jis .sjis
===========================================================================
No Contents Panel after Apache Fix
Thanks!
Su Piercy
JDSU
Colorado Springs
You appear to be using some sort of bug tracking add-in. Try on another FF machine without that add-in and try disabling it on your machine. I cannot recall the name but a year or two back there were problems with a bug tracking add-in.
Then turn to the errors found. Use a file comparison tool to check the content of where you generated locally with what is on the server. If those files did not make it to the server, I would expect problems.
See www.grainge.org for RoboHelp and Authoring tips
Yes I think that was it. If the poster is using some other similar tool, I would still recommend disabling it.
See www.grainge.org for RoboHelp and Authoring tips
AdChoices