RPM Print Server Upgrade, more Unicode support

RPM software print serverWe released today a major version of our RPM Remote Print Manager® ("RPM") product, version 5.1.0.88. RPM is our software print server, which includes the ability to pre-process the data in your print jobs (we refer to this as "transforms") and it provides multiple outputs for your print jobs, which we call "actions".

Unicode support

The most significant change for this release is that we substantially increased the amount of Unicode support. RPM has been able to use Unicode for Windows text printing for well over a decade.

Windows printing is one of our actions. What we changed is that we now assume that all of the file paths, printer names, folder names, and font names could be Unicode as well.

For instance, if you archive a file to disk, then RPM now supports multibyte characters in the path name for that folder.

If you send a multibyte file name using an lpr client, such as the Windows lpr client or one of our own, that works correctly.

RPM supports multibyte printer names. RPM also supports multibyte font names. That used to work in RPM 4.5, and now it works again. We also support font catalogs properly.

The second most significant factor in this release is that our text-to-PDF conversion now supports UTF-8. You no longer have to think about the "encoding" for the PDF file; select a font that works with your data, and you should get outstanding results.

Database improvements

We upgraded to a newer version of the Firebird database that we use with RPM. With that, we were able to adopt some new methods to streamline database updates. We also identified and resolved the database problems reported to us, mostly deadlocks. The vast majority of them were not severe but anything along those lines is going to cause legitimate concern, and that's now taken care of (really, and not in the political sense).

Other improvements

  • A few people reported delays of 4-5 seconds receiving a print job; one person said 30 seconds. It turns out that we were asking for the name of the computer that just sent us the job so that we could do the regular security checks. In networks using WINS for resolution, if WINS was not set up to know the name of this host, that delay was a timeout. We fixed that, of course.
  • There are numerous small but possibly convenient GUI fixes and enhancements.

Where to go next

You can review all the changes in this version on the RPM Roadmap page.

You can download the newest versions of RPM Elite or Select from the downloads page.

Contact us for questions, upgrade advice, etc.

This release is an improvement in the amount of print output jobs being sent to the windows server from the mainframe. It seems like they are moving groups of eleven jobs now but a little faster than before.

Wed, 10/20/2010 - 10:56
james.magnant@…

Hi James, thanks for your comment. We hope it is a little faster than before.

If you're seeing jobs move in groups of 11, that's a Windows setting, not RPM. We push thousands of jobs through RPM in testing.

Since you are sending from a mainframe, perhaps that system is using the official RFC 1179 standard of ports 721-731. They don't need to; RPM happily accepts any valid port.

Thu, 10/21/2010 - 16:54
Dave Brooks

In reply to by james.magnant@…