I Just wanted to send you a note to say how nice it is to have WebWorks ePublisher again. No post-processing anymore. No need to create special styles in Framemaker just to work around problems in the help system generation. Decent search results. And I can pretty much make the output look however I want. I thought I’d take the time (after the painful experience of working with the Adobe TechCommSuite 1.0) to tell you how great this system is to work with and how much I appreciate the thought that has gone into it. Kudos to the engineering staff and the product management team. I am really happy about having a separate place for all my overrides so that I can maintain the latest ePublisher application code without having to reapply overrides directly into it. Furthermore, giving me access to my overrides directly from the ePublisher interface makes maintaining them much easier and prevents duplication of the entire source code tree. It’s smarter and better. ePublisher truly gives me my help, my way. To provide a little more color on the differences I observed, I’ll list some of the things that drove me most crazy about single-sourcing with Robohelp. Note that I am using the ePublisher 2012.2 WebWorks Help 5.0 format vs. the RoboHelp 7 (bundled with very old TCS 1.0) HTML WebHelp format.

• I had to search/replace in files all the topics in the topics file (underlines with spaces) because the search system would return my topic list with underlines between words (the names of the _files_ rather than the topic names within the source material). This problem was fixed in a subsequent version of TCS, but it goes to show how unfinished the version I originally bought was. ePublisher does TOC topics correctly.
• Every time I added a new chapter to my Framemaker book, I not only had to “Force Update” my RoboHelp project, but I had to update my TOC by hand and remap the flow from page to page throughout. ePublisher does this automatically using the TOC in the FrameMaker file in a correct way. I can break to a new help page wherever I like and the flow from page to page will be updated correctly to follow the regenerated Framemaker book. I can include or exclude any file and adjust the levels at which headings appear in the help TOC easily.
• I had to replace the RoboHelp search engine which had no ranking system and delivered sub-par results to use Zoom Search. This had to be jerry-rigged into the RoboHelp system, and topic indexing done separately outside of RoboHelp to deliver results properly. ePublisher’s search is relatively elegant and delivers good results with user-settable rankings.
• I had to create special styles within FrameMaker to get around RoboHelp issues under specific circumstances. For example, the last bulleted indent paragraph following a step and immediately preceeded a new heading, would be treated differently (indented oddly) than if it were immediately preceding another step. So I had a special Framemaker style (duplicate) to manage this particular case so I could map into it differently. Ugly. There are many more of such cases that could not easily be solved any other way. ePublisher wraps styles in div and table tags a better way to prevent these types of issues from occuring. I have now been able to get rid of all those duplicate styles within my Framemaker files.
• To customize a footer in RoboHelp, a separate templating (htt) file must be created. This worked well enough, but was much more cumbersome that just having ePublisher’s Page.asp to handle it.
• I had to search/replace in output files to add meta tags to the header of each HTML page in RoboHelp. I could easily do this in the Page.asp file in ePublisher. The Page.asp file allowed me to do anything I wanted with NO POST-PROCESSING necessary. I could even generate today’s date to automatically stamp the date the help was generated within ePublisher by customizing the page.xsl, adding an xsl file for compiling and incorporating some javascript into the Page.asp file. In RoboHelp I’d have to update the actual footer template with the current date prior to updating each time I generated. No way I know of to have automated it.
• Our software engineers gave up on trying to get RoboHelp’s context-sensitivity to work properly. ePublisher allows you to open a topic within a page easily just by using a URL with specified parameters. You also can go the API route as per RoboHelp with ePublisher, but for engineers that have other priorities, it is not necessary for them to work with an API. They can expose a special topic within your help by simply using the proper URL and parameters which can easily be integrated into the application code.
• Mapping of my Framemaker styles into RoboHelp took much longer than in ePublisher. Robohelp did not use sensible defaults based on the Framemaker styles so basically all of the Framemaker styles had to be laboriously mapped within RoboHelp to produce good output.
• The handling of conditional tags took some maneuvering in RoboHelp. It was not easily applied. I had to look up a procedure within Adobe Support to get it done. Applying conditional tags in ePublisher was simple and easily located within the Target > Conditions menu.

In sum, it was instantly apparent that Adobe had bought a system that did not easily lend itself to single-sourcing. There were many functional areas that clearly had been tacked on like wings to existing functionality. ePublisher by comparison is a dream to work with and gets the job done comparatively fast.

Thanks Quadralay Corporation!

Katherine | Director