An user reported having some issues working with Japanese SAVF. The source extraction failed due to unsupported DBCS fields, and there were also some font issues with Japanese characters. I reproduced both issues with some free Japanese SAVF found on the net (thanks http://hrm.fixa.jp/free/freesoft.htm).

For this release I've improved the globalization support in jSAVF:

• I've added the support of DBCS fields to the source extractor, so it can now export Japanese sources.
• I've made a few things configurable:
  • The monospaced fonts used for the display of spools and text are now configurable, and show a preview of how well they're able to render a few international characters using the following string made of machine translations of the word "Left" in various languages: "Gauche Lénks Слева Αριστερά اليسار שמאלה Trái 剩下 左 ひだり レフト 왼쪽 बाएं ਖੱਬੇ ".
  • A new configuration tab is dedicated to text conversions, and now allows the user to override jSAVF's best guess of which Charset should be able to decode which CCSID. For CCSIDs which jSAVF couldn't find a matching Charset, when the JVM has a Charset which can decode a related CCSID this also allows the user to use that Charset to decode the otherwise unsupported CCSID. For example CCSID 5026 is unsupported by the JVM, but CCSID 930 is through Java Charset IBM930, so by adding an user conversion of CCSID 5026 with Charset IBM930 you can get most of the text to come out correctly in an export.
  • The default CCSID which is used whenever jSAVF doesn't know how to decode something (mostly things related to the job CCSID) can now be configured on that tab too, and can now use a CCSID which isn't supported by the JVM as long as there's an user conversion defining a Charset for it.

On the packaging side I've updated the OpenJDK bundled with the jSAVF Windows installer to a more recent version (v11.0.4+11), and I'm now building everything from Linux. I knew the Windows NSIS installer could be build with a makensis compiled on Linux, but I was pleasantly surprised to discover that jlink can build a modular OpenJDK image for Windows while running under Linux.

As always, if you encounter any trouble with this jSAVF version or cannot open a SAVF with it, don't hesitate to report it to me.

An user reported that one large SAVF of his could not be opened by jSAVF. After investigation it appears that one of the SAVF index items was too big and split by the iSeries into several additional ones, which jSAVF didn't know how to handle. I am unsure whether this is due to the recent version of the OS the SAVF was made on (V7R3), but now jSAVF can handle such SAVF.

I have also changed the way jSAVF is released to keep up to date with the new Java versions.

jSAVF is now compiled against Java 11, and requires such an environment to run. I recommend using OpenJDK 11 instead of Oracle's commercial version of Java 11 due to changes in Java licensing.

jSAVF will be available in two formats:

• An archive including the JAR files for each of jSAVF module or dependency, and a script to help start it for Windows or Linux.
• An NSIS Installer for Windows (x64), which includes the jSAVF modules and dependencies, and the minimal modular image of OpenJDK to run it, built using jlink.

So the choice really comes down to whether you want to install the Java environment yourself or not.

If you encounter any trouble with this jSAVF version or cannot open a SAVF with it, don't hesitate to report it to me.

This version fixes two file list scrolling bugs which affect the DriveSort's playlist mode:

• The first bug prevented the list from automatically scrolling up or down when you were dragging a file above or below the files currently visible in the file list, which made manually sorting folders with many files a pain. It was due to DriveSort's use of an up or down scroll increment with a number of pixels which was smaller than the list line height, which was rounded down to zero lines by the list view control and thus lead to no scrolling at all.
• The second bug made the list scroll back up to the first file when a file was dropped in its new position. I've fixed it so the files currently in view before the drop stay displayed after the drop.

This version fixes a small bug in the user preferences loading code which prevented DriveSort from remembering you chose the new logical long name comparison base in a previous execution of DriveSort. In this case, at startup DriveSort was switching to a comparison by file size. Thanks to the user who reported it.

Another user asked for an indication of when DriveSort was working and done, so this version also shows some progress when sorting folders and when saving the sorted folders to disk.

The sorting operation is usually rather fast, but the saving operation can take a while when processing many folders on slow peripherals. When sorting or saving, DriveSort now displays the current operation in the status bar at the bottom and turns the mouse cursor into a wait cursor. When it's saving it also displays in red in the progress bar how many directory entries it has saved.