MadCap Flare: Next Page/Previous Page Buttons
When I generate WebHelp output with a FrameMaker-to-ePublisher Pro workflow, the conversion tool automatically creates Next Page and Previous Page buttons that the reader can click to navigate through the document.
Flare doesn't seem to provide that feature. It does have something similar called "Topic Continued" and "Topic Continued From . . ." links, which you set on the Options page of the Frame Import Editor window.
That option adds text links that reference the preceding or following file name, which isn't exactly the effect that I want.
So I went into the CSS file for my project and updated the code for the "Topic Continued" and "Topic Continued From . . ." links:
font-family: 'Arial, Sans-Serif';
background: url(../images/Previous_Page.png) left bottom no-repeat;
font-family: 'Arial, Sans-Serif';
background: url(../images/Next_Page.png) left bottom no-repeat;
While this doesn't produce an effect that's exactly like the one I got from ePublisher Pro, it is closer to what I want.
Modifying the search pane in WebWorks Help 5.0 ouput
We use ePublisher Pro and FrameMaker 7.2 to produce WebWorks Help 5.0. The search functionality in this output is a bit quirky and not quite like what you might expect if you're used to doing Web searches. For example, putting quotes around search terms finds only that exact term in most Web searches. But that doesn't work in WWH 5.0. As a result, we get a lot of questions from confused customers as to why they can't find what they're looking for.
I've included some hints about searching in a help file that I created to show users the ins and outs of our guides. But I've found that most people don't bother reading the help file, so I wanted to find a way that they couldn't miss the information.
As you can see by the image on the right, the default Search pane in WWH 5.0 has a lot of white space. So I wanted to see whether I could utilize that white space for my purpose.
I found the JS file that contained the information for that pane, which is the search.js file in the install directory\ePublisher Pro\Formats\WebWorks Help 5.0\Files\wwhelp\wwhimpl\js\scripts folder. Following is the code that I needed to change (line 320 in my version of the search.js file):
HTML.fAppend("<p><strong>Type the word(s) that you want to find in the above box using the following hints:</strong> </p><ul><li><p>Search results appear in order based on a results scoring system. Click the help file icon at the bottom of the page to view more information about the scoring system.</p></li><li><p>Some search results may appear in sections of collapsed text. To show all text, click <strong>Expand All</strong>.</p></li><li><p>The search functionality does not support the use of quotes around search terms or the use of Boolean search operators. If you type more than one word in the search box, the results include every page that contains all the words you typed, regardless of the order in which they appear.</p></li><li><p>You can search for word fragments using the * symbol. For example, if you search for <em>*serve</em>, the results would include all words that end in <em>serve</em> such as <em>observe</em>, <em>preserve</em>, or <em>conserve</em>. </ul>\n");
When I re-generated my project, my Search pane looked like the following:
Update for FrameMaker 7.2 for Windows
Adobe FrameMaker 7.2p158 update for Windows
This download updates the English, French, German, and Japanese language versions of Adobe® FrameMaker® 7.2b144 software (released in December 2005) to version 7.2p158.
The FrameMaker 7.2p158 patch for Windows® includes the following corrections:
• Code point correction providing added support for missing characters on Cyrillic, Central European, and Baltic code pages for Windows.
• Fixed capability to drag and drop files from Windows Explorer onto the FrameMaker Book window.
• Various fixes related to Undo, WMF/EMF filter, PDF conversion, DITA, and XML schema.
• Added limited support for URL paths (e.g., http://...) in import and export XML workflows for schema. The schema URL will need to map to a local path (on disk) using the entity catalog file. The syntax for mapping is the following: SYSTEM "http://url..." "local path of schema". Whenever you have an HTTP path for the schema file, FrameMaker will refer to the local mapped file on the disk and will use this schema file for processing. This support is not extended to schema in include, import, and redefine elements. The URL path mapping support should not be used in "import XML fragment" workflows.
Updates for Acrobat and Reader
Acrobat Web Capture causing problems
I had a user who was struggling with links in a PDF file that she was creating. The links were to Excel files stored on our company Web server (i.e., Internet links). When she clicked a link in the PDF, a Download Status dialog box appeared followed by an error message.
I was gone for a few days, so she first contacted our LAN department, who re-installed Acrobat 6 for her and spent the better part of two days trying to track down the problem.
When I returned, I opened her PDF on my PC and had no troubles when I clicked the links. So I started checking preference settings. I checked an Acrobat book that I have and discovered that the Download Status dialog box appears when you try converting a Web page to PDF. That pointed me to the preferences for Web Capture.
I checked the Web Capture page of the Preferences dialog box, and I found that my Open Web links option was set to In Web Browser, while my colleague had it set to In Acrobat. I changed her settings to In Web Browser, and everything worked fine.