Tag Archive for 'tips'

VMware Fusion 2.0 and CVSNT

VMware recently released Fusion 2.0, its Mac virtualization product with an extremely annoying incompatibility–it won’t work properly with Windows guest systems running CVSNT, the CVS client installed with TortoiseCVS.

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.Removing the CVSNT Server

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…

Moving (renaming) Files in CVS

Once of the main complaints about the CVS version control system is that it’s difficult to move or rename files as your project structure changes.

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?

RenderX XEP Setup in oXygen

Recently, a client asked for assistance in setting up the RenderX XEP processor for use with the oXygen XML editor on Mac OS X. XEP is an XSL FO processor that can be integrated with oXygen to transform DITA maps to PDF via the PDF2 transformation scenario.

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.


Upgrading WordPress via Subversion

David over at Geeks are Sexy has a nice tutorial on keeping WordPress installations current by using Subversion to check out the latest code directly from the Automattic repository.

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.)

Spaces in HTML Help Project Paths

Like so many other applications, Microsoft’s HTML Help Workshop often chokes on project files whose paths contain spaces.

If you double-click a HTML Help Project File (HHP) in a location whose path contains spaces, the HTML Help Workshop throws an error when you click the Compile button and refuses to compile the CHM file.

Cannot open the file ""C:\Folder Name\File Name.hhp"".

You can work around this issue by removing the quotes from the path shown in the Create a compiled file dialog before you click the Compile button, but you still won’t be able to save any changes you’ve made to the HHP file.

SOLUTION: Instead of double-clicking, open the HHP file from within the Help Workshop via File > Open. This helps the Workshop to handle the paths properly and you will be able to save your changes and compile as expected.

Using Mac VPN Clients with Virtual Machines

If you use Parallels or VMware Fusion and a Mac VPN client such as VPN Tracker, you can share your VPN connection between the host Mac and the guest PC by setting the network adaptor to share the host’s Internet connection via NAT.

This connection method also has other advantages, as the VMware Fusion Release Notes explain:

“VMware Fusion’s default network connection type for new virtual machines is NAT, which will prevent the spread of viruses over the network into the virtual machine, and will only expose the virtual machine to external viruses through browser security flaws when you browse the Internet.”

The idea of sharing VPN connections with Windows applications via Parallels is touted as a VPN Tracker feature and explained in detail in a how-to PDF, but it works equally well with VMware Fusion.

The key is setting the network adaptor to shared networking (NAT) as opposed to the bridged or host-only options shown in the VMware settings screenshot below.

screenshot

With this approach, network traffic from your virtual machine is routed through the existing VPN connection on the host Mac, so there’s no need to install a separate VPN client application on the guest PC.

Sharing DITA-OT in OS X & Boot Camp

If you’re using the DITA Open Toolkit on Mac OS X, you can’t generate compiled HTML Help (CHM) files directly, since Microsoft only offers the HTML Help Workshop for Windows.

But if you also run Windows on your Mac via Boot Camp, you can set up a single installation of the Open Toolkit on your Windows partition and use it to generate output from either operating system environment.

Essentially, you boot into Windows (via VMware, Parallels, or directly) and set up the toolkit there as usual.

Once you have the toolkit running under Windows, create a copy of the Ant build file for your project, adjust the paths for access from Mac OS X and save it under a new name in the DITA-OT directory on your Windows partition. (You’ll call this file later from the Terminal to build your project output on the Mac.)

Back on Mac OS, set up the environment variables required by the toolkit.

You can do this by editing the .bash_profile file in your home directory, or if you don’t like editing hidden UNIX files by hand, you can use freeware such as RCEnvironment or SSHKeychain, which provide a simple dialog that allows you to define environment variables like in Windows.

(In the background, both tools simply write to the ~/.MacOSX/environment.plist file. SSHKeychain also serves as a nice Mac equivalent to PuTTY, but that’s another story…)

The key here is to use the absolute path to the toolkit installation on the Boot Camp partition. For example, if your Windows partition is named BOOTCAMP and the toolkit lives there at C:\DITA-OT1.4.1, you might set the DITA_HOME variable like this:

DITA_HOME=/Volumes/BOOTCAMP/DITA-OT1.4.1  

You can then define the other variables relative to the toolkit directory with entries like this:

ANT_HOME=$DITA_DIR/tools/ant

Note: If you use either of the aforementioned tools to edit ~/.MacOSX/environment.plist, you’ll need to use the full paths for the remaining variables, as $VARIABLE values are not expanded when this file is read.

Once the variables are all set, you’ll need to log in to OS X again to activate them.

Then with a command like this, you can build output from the Terminal using the Mac version of the build file you edited above:

ant -f your-mac-build-file.xml html 

To build CHM output, switch to Boot Camp, run startcmd.bat in the DITA-OT directory, and enter something like this on the command line:

ant -f your-windows-build-file.xml chm

If both your build files are set to share an output folder on your Mac, your files will land in the same place, no matter which operating system you build them on.

Automator Workflow: Set ZIP File Date

When you compress a file or folder in the Finder via the Create Archive command, a ZIP file is created using the current date as modification date.

But when you’re archiving older data, it’s much more useful for the ZIP file date to reflect the date of its contents, since a few years from now you probably won’t care when you compressed the stuff, but rather how old the files inside are.

Fortunately, the command line version of ZIP included in Mac OS X includes an option to do just this: zip -o, which according to the man page will

Set the “last modified” time of the zip archive to the latest (oldest) “last modified” time found among the entries in the zip archive

—which is just what we want.

But depending on your command line proficiency, you may find it a bit tedious to open up a terminal window and look up the command syntax every time you need to compress a file.

Enter Automator, one of the most useful (and unsung) productivity tools in OS X, which we’ll use to create a new Finder plug-in (or “workflow”).

To create the workflow, open /Applications/Automator.app and add three actions in this order:

  1. From the Finder library, drag the Get Selected Finder Items action to the workflow area on the right side of the window.
  2. Drag the Create Archive Finder action to the workflow area, placing it after the first action.

    (At this point, you can pre-specify a name and location for the archive file, or set the Options to prompt for this information when the workflow runs.)

  3. From the Automator library, add the Run Shell Script action. Leave the Shell set to /bin/bash, set Pass input to as arguments, and replace the default script in the text box with zip -o "$@".

That’s it!—Save the workflow as a Finder Plug-in, and you can run it on files & folders in the Finder by Control-clicking and choosing your new command from the Automator submenu in the shortcut menu.

Book Tip: Bit Literacy

Bit Literacy book coverIf you’ve ever struggled with the volume of bits that require your attention every day, a recent book by Mark Hurst of Good Experience may help.

Titled Bit Literacy: Productivity in the Age of Information and E-mail Overload, the book offers simple common-sense suggestions for dealing with information overload.

Many of the suggestions are so basic that you may already be using similar strategies to deal with your daily workload, but the book is well worth reading nonetheless, as it makes a strong case for a comprehensive and simple approach any normal user can implement.

In fact, as you read the book, you may be reminded of countless friends and associates that fit the Busy Man description with striking accuracy, or others you know who would benefit from exposure to these ideas.

Note to self: Great Christmas present for clients & colleagues!

WebWorks TopicAlias Marker Changes

One of the nice things about single sourcing with WebWorks and FrameMaker is that you can embed context information in your FrameMaker source files using custom markers, which WebWorks processes when creating context-sensitive help formats such as Microsoft HTML Help.

However, if you’re considering upgrading from an earlier version of WebWorks Publisher to the latest ePublisher platform release (currently version 9.2.2 build #10315), you should be aware of a significant change in the way that TopicAlias markers are handled.

In WWP6, the contents of TopicAlias markers were treated as numeric MapIDs, and WWP autogenerated text aliases based on the text of the heading in which the TopicAlias marker was inserted.

For example, if you inserted 1002 in a TopicAlias marker, WWP6 would generate a mapping entry as follows:

   #define Heading_Text1002  1002 /* Heading Text */

Now in WWeP 9, the contents of TopicAlias markers are instead treated as text aliases, and WWeP instead generates its own map IDs based on the sequence in which TopicAlias markers appear in source files.

In WWeP, the example above is now output as follows:

   #define 1002 10000010 /* Heading Text */

Continue reading ‘WebWorks TopicAlias Marker Changes’