RPM Software Print Server Upgrade, more Unicode support, better Asian operating support

RPM software print serverWe released today a major version of our RPM Remote Print Manager® product, version 5.1.0.88. This 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 biggest single 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. Actually, that used to work in RPM 4.5, and now it works again. We also support font catalogs properly now.

The second biggest thing 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; just 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 which were reported to us, mostly deadlocks. The vast majority of them were not serious 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 reported 30 seconds. It turns out that we were asking for the name of the computer that just sent us the job, so we could do the standard security checks. In networks where WINS was used for resolution, and if WINS was not set up to know the name of this host, that delay was actually 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.

Comments

RPM Select

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.

Eleven jobs

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.