Helpify provides a very simple means of generating HTML that is properly formatted for use as Apple Help, including navigation links, abstracts and the HTML comments used as segment commands by Apple Help. Though it’s not a full-blown help authoring tool, Helpify is used to create the help books for all current Omni Group products.

If your project is not too complex and you have a copy of OmniOutliner lying around, you might want to give Helpify a try. Big thanks to William and Omni for releasing this very useful tool!

As the release notes say:

CVSNT and VMware Tools are incompatible.
There is a known incompatibility between CVSNT (…) and VMware Tools. You should uninstall CVSNT if you want to install VMware Tools to use Unity view, and to use cut-copy-paste or drag-and-drop between your virtual machine and your Mac.

While you can work around the clipboard issue by exchanging text between host and guest via a public pasteboard file stored in a shared folder, it’s aggravating that this sort of kludge should be necessary and especially astounding considering that “Unity Improvements” are among the selling points for the new version.

According to an employee comment in a recent thread, it’s the CVSNT Server control panel that VMware Tools don’t get along with, and a fix is in the works for the next release.

So if you’re not running a CVS server on your virtual machine, you can solve the problem by removing the CVSNT Server control panel via Add or Remove Programs (select CVSNT, click the Change button, select the Modify option and disable the CVSNT Server components).

Restart the guest system and re-install VMware Tools in the virtual machine. After another reboot, Unity view should work properly, and you can still connect to remote CVS servers using the client components of CVSNT.

It’s a shame VMware didn’t manage to include this solution in the release notes…

While you can easily remove files and re-add them under a new name or location, this method loses the precious nuggets of wisdom contained in the file’s history — you do enter meaningful commit messages, don’t you?

Although recent CVS versions (CVSNT 2.0.55 and later) include support for a new rename command, the feature is classified as “experimental” and it’s not well-supported by common clients nor well-documented in the manual.

However, it can be done — the key is to understand that rename operations are properties of directories, not of the files inside. So when you move or rename a file, it is essential to commit the folder containing the file — and (if you moved the file) the new folder as well.

Before using the rename command, you may want to back up your local working copy (sandbox) just to be on the safe side if anything goes wrong — and if it does, please don’t blame me!

The steps below outline the basic process.

To move (rename) an existing file in CVS:

1. If you’ll be moving a file to a new location that is not already under version control, create NewFolderName and add it to CVS with cvs add.

2. At the command line, navigate to current location of the file you want to move (let’s call this OldFolderName) and enter:

   cvs rename OldFileName ../_NewFolderName_/_NewFileName_

   (the file is moved to NewFolderName and renamed to NewFileName)

3. This is the important part! — Still in OldFolderName, enter:

   cvs commit

4. If you moved the file to a different folder, cd to NewFolderName and repeat the commit command:

   cvs commit

   At this point, the repository knows about the changes to OldFolderName and NewFolderName.

   Now, for good measure, we will update our local sandbox to be sure we have a pristine copy of the project. In fact, to really make sure the repository “gets it”, we’ll remove NewFolderName and verify that it returns on update.

5. So take a deep breath, and delete NewFolderName.

6. Then, finally, navigate to your project’s root folder and enter:

   cvs update -P -d

   (In this command, the -P option tells CVS to “prune” (remove) any empty folders in your working copy, and -d creates any missing folders like NewFolderName.)

That’s it. You’re done! — NewFolderName should reappear, and inside it, NewFileName will be waiting for you with its history intact!

What? It isn’t? — well, you do have that backup, don’t you?

The sidebar now includes a small popup menu (shown at left) which toggles the sidebar to display either the table of contents or the index.

Congratulations to Robin for listening to users and reacting so quickly!

With the new index feature, Sparkle-based application updates and the tag-powered bookmarking system mentioned earlier, iChm is certainly the best CHM viewer available for Mac.

When you bookmark a topic, you can assign tags which allow you to quickly access topics in any CHM file based on the keywords you have specified.

While the concept of tagging is hardly new, the feature is unique to CHM viewers on the Mac, and can be especially useful for help developers looking for a simple means of flagging open issues in topics—just add a FIXME tag to keep track of those pesky output bugs while you tweak your WebWorks stationery.

Unfortunately, iChm shares a shortcoming with many other Mac CHM viewers: the current version (1.1.1) offers no support for the index, which is an essential component of any well-built help system. With a little luck and a bit of persuasion, perhaps Robin can be convinced to add this feature in a later version.

It wouldn’t take much to make this the best CHM viewer available on the Mac—so many of the others were apparently released as one-hit wonders and have not been actively maintained in years.

2008-08-27 Update: Version 1.2 now includes index support.

2008-09-04 Update: Version 1.3 now allows you to search the index.

The steps below describe the basic setup, and while the output location is project-specific, the rest should be essentially the same in any environment.

1. Install XEP (for example, to /Applications/RenderX-XEP)

2. Point oXygen to XEP executable in oXygen prefs: XML > XSLT-FO-XQuery > FO Processors (Use the Browse button)

3. Create/verify configuration of PDF2 transformation scenario in oXygen:

• Open a DITA map file & select Configure Transformation Scenario from the DITA Maps menu.

• Create new scenario, select PDF2 - Idiom FO Plugin as transformation type

• In the Edit DITA Scenario dialog:

  • On the FO Processor tab, select XEP from the Processor list.
  • On the Parameters tab, set:
    • args.input to ${cf}
    • dita.dir to ${frameworksDir}/dita/DITA-OT
    • (other parameters optional)
  • Leave the default settings on the Filters tab.
  • On the Advanced tab, set:
    • Custom build file to ${frameworksDir}/dita/DITA-OT/build.xml
    • Java Home to Default, such as /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home
  • On the Output tab, set:
    • Base directory to ${cfd}
    • Temp directory to a subfolder of output location, such as …/documentation/output/temp
    • Output folder to a subfolder of SVN documentation checkout location such as …documentation/output/pdf2
  • Click OK to save settings.

• Click Transform now to create a PDF of the current DITA map.

David’s instructions are much more detailed than the brief steps provided on the WordPress site, and also describe how to check out stable WordPress versions as opposed to the latest bleeding-edge code from trunk, and how to switch an established blog to Subversion to facilitate future updates.

(Essentially, you check out a working copy to your webserver via SSH and reconfigure the fresh install to use your existing database content—worked here quite nicely.)

We wanted to make an application which would make version control usable and, most-of-all, approachable to Mac users.

As John Gruber pointed out, they were brave enough to commercially release v1.0 without the requisite hype or beta Versions. And unlike many of the other Mac Subversion options, Cornerstone includes not only client functionality, but also the administrative tools, so you can perform various operations on the repository itself, not just your local working copy.

Oddly enough, many clients seem to only support a subset of even the client commands, so with many of the GUI frontends, you need to fall back to the command line to switch or relocate your working copy to a different repository, move files, etc.. Curious to see how complete Cornerstone is in this respect…

Now the question is, who will be first out of the blocks to support the new features in Subversion 1.5–sparse checkouts, anyone?

The opening line of the beta announcement sheepishly concedes the app’s impending vaporware contender status:

Versions one year anniversary – celebrating with an actual app!

While the interface is certainly slick, it remains to be seen whether a Mac-like look and feel and a bit of Beanstalk integration are enough to win over those who’ve made do with the various alternatives thus far.

Despite the variety of cross-platform and Mac-specific Subversion clients available, with the exception of the somewhat orphaned SCPlugin, each oddly seems to assume developers need yet another app running alongside their work just to interact with a version control system, instead of just blending into the woodwork like the venerable TortoiseSVN.

Sometimes beauty in UI design is less about lickability than invisibility…