2 Replies Latest reply on Feb 23, 2011 9:45 AM by rschwarz100

    Problems opening webhelp retrieved from Perforce


      My company source controls the webhelp I create through RoboHelp 7 along with all other software in Perforce (P4V) and creates software builds from P4V. Everything seemed to work OK for my webhelp until my company outsourced P4V management to a development group overseas. Perhaps the previous adminstrator of P4V made adjustments for webhelp that I was not aware of and created software builds in a special way. In any case, my webhelp (obviously HTML based) must have been configured in some wacky way - perhaps as Western ansi character set, because suddenly noone (especially QA) could open it. P4V displayed an illegal character at the head of my default file and most other files (the ones I cared to look at). The new P4V administrator came to visit our heaquarters and assigned the Unicode, UTF-8, no BOM character coding to P4V for my input and the problems seemed to disappear.


      However, a developer (overseas) needs to review my webhelp, I suppose together with her implementation, and was unable to use the copy she retrieved from  P4V- with the same problem (I assume it's the same problem).


      While replacing my files in P4V, I noticed the ehlpdhtm.js file, which appeared in all my webhelps at the root, often caused P4V to reject my webhelp. It seems the special characters for copyright, trademark, and registered trademark, could not be interpreted with the proper encoding. So I reverted that particular file to the "old" version and the webhelps were accepted. (Actually, it's been the same file since I installed RoboHelp 7 in 2008.)


      I request to know what the right settings are so that my webhelps become part of the current software builds in my company. I don't want ugly rumors to start among developers that I am "not doing anything" - the rumors that were quashed when I convinced management to purchase RoboHelp in the first place. (Management caused a problem by forcing me out of FrameMaker and into a wiki before the wiki (and I) were ready to export to online help.)

        • 1. Re: Problems opening webhelp retrieved from Perforce
          Peter Grainge Adobe Community Professional (Moderator)

          It sounds like the root of the problem is that whatever server the help is being viewed from must be UTF8 enabled.


          I have previously posted this in response to other similar questions. Hope it helps you. You will need your IT admin people to deal with this.




          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.


          See www.grainge.org for RoboHelp and Authoring tips



          • 2. Re: Problems opening webhelp retrieved from Perforce
            rschwarz100 Level 1



            Thanks again.


            I forwarded your response to the administrator of Perforce and to the developer complaining of the problem.


            This could mean that the installation procedure for my company's software may have to be modified to accommodate the webhelp character set. I am not sure if they want to implement that. When I switched over to RoboHelp, I had to make sure to name my default files wwhelp.htm because the previously generated help were created by FrameMaker files processed by WebWorks Publisher so that developers would not have to make the minor change of having the Help button invoke a new Help file name in order to open online Help.


            Best regards,