8 Replies Latest reply on Jan 3, 2013 11:22 AM by Peter Grainge

    Invalid Characters Monster Back in RH 10


      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


      Colorado Springs

      Firefox-Contents.JPGFigure 1: Broken Contents Panel in Firefox on UNIX

      Firefox-Index.JPGFigure 2: Index Display in Firefox on UNIX

      Firefox-Search.JPGFigure 3: Search Display in Firefox on UNIX


      Message was edited by: lipikar11

        • 1. Re: Invalid Characters Monster Back in RH 10
          Peter Grainge Adobe Community Professional

          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:

          1. Do the fix itself (httpd.conf: AddDefaultCharset utf-8).
          2. Restart the box to apply the fix.
          3. 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




          • 2. Re: Invalid Characters Monster Back in RH 10
            lipikar11 Level 1

            Much thanks Peter.  My apologies if I offended your sensibilities about Adobe.  We will try the Apache fix you suggested and I will post our results.


            But I would still question why Adobe would not post this workaround themselves either on their Support page or in the RH10 documentation.


            But thanks anyway.


            Su Piercy


            Message was edited by: lipikar11

            • 3. Re: Invalid Characters Monster Back in RH 10
              Peter Grainge Adobe Community Professional

              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




              • 4. Re: Invalid Characters Monster Back in RH 10
                lipikar11 Level 1

                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?




                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.gif No Contents Panel after Apache Fix




                Su Piercy


                Colorado Springs

                • 5. Re: Invalid Characters Monster Back in RH 10
                  lipikar11 Level 1

                  Sorry the second sentence should say: 

                  Our engineer says that fix #1, adding the charset to the Apache httpd.conf file and restarting Apache did not work.

                  • 6. Re: Invalid Characters Monster Back in RH 10
                    Peter Grainge Adobe Community Professional

                    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




                    • 8. Re: Invalid Characters Monster Back in RH 10
                      Peter Grainge Adobe Community Professional

                      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