CWASA Release Notes

Home >> JASigning

JASigning 0.9.5g

These are the main differences between this version and JASigning 0.9.5.f:

Improvements to SiGML Processing: SiGMLInLib, the component which performs conversions from H-SiGML (HNS SiGML) to G-SiGML (Gestural SiGML), and also from G-SiGML back to H-SiGML or HamNoSys, performs these conversions consistently with one another, and some errors in the conversion from H- to G-SiGML have been fixed. CAS (animation) data is now output in a more compact format. CAS input and output are consistent, so re-exporting a previously imported CAS file generally produces a result whose format matches that of the original.

Improved CAS Input and Output: CAS (animation) data is now output in a more compact format. CAS input and output are consistent, so re-exporting a previously imported CAS file generally produces a result whose format matches that of the original.

Improved Handling of Apps' Initial Options: The initial option settings for a JASigning app are now handled more flexibly. In particular, different JNLP variants of the same underlying JASigning app can now use distinct initial options settings without confusion. Initial options properties files are cached on the client to support offline operation.

JASigning 0.9.5f (2010-07)

These are the main differences between this version and JASigning 0.9.5.e:

Ambient Motion: Some of the avatars, including the standard avatar Anna, are now capable of ambient motion, both when idle and when signing. This feature is demonstrated in some of the applications and applets. As yet the facilities for detailed control of this feature are quite limited, but both JASigning applications include menu items allowing ambient motion to be switched on and off.

Video Generation: JASigning now has an experimental video generation facility. Because it depends on an externally provided video processing software library, this facility depends on a supporting video generation service application (running on the client system), which must be downloaded separately. For details on the download and use of the video generation service application, see the JASigning Video Generator page.

Security Certificate: The JASigning software components are now signed with a certificate issued by GlobalSign (to our School's consulting company, SYS Consulting Ltd.). While this gives stronger assurances about the software's authenticity than previously, it has one possible drawback for those running the software on Mac OS X: there is a bug/issue in the Mac OS X Java implementation which requires the system to be online when a JASigning application is launched, in order that the OCSP security checks can be made (even though the application is marked as suitable for offline execution). This means that on Mac OS X the JASigning applications can not be launched while completely offline. (Although going offline once the application is successfully launched is not a problem.) The only way we can see of circumventing this problem is for us to provide an alternative, self-signed, copy of the software, which is not subject to this limitation (but which is correspondingly less secure). This self-signed version can be found at the URL obtained by inserting an extra step "ss/" into the path just before the version tag: http://vhg.cmp.uea.ac.uk/tech/jas/ss/std/

Java Security Checks: JASigning has been adjusted to take account of the fussier security régime introduced into the Java releases of recent months. In particular, the JASigning applications and applets should no longer give rise to Java security messages about "mixtures of signed and unsigned components".

Platform Independent Applet: The main SiGML Player Applet and its variants are now launched as JNLP Applets on platforms that support this mechanism, falling back to the use of the JNLP Applet Launcher on those that don't.

Windows Support: Although our testing is relatively limited, JASigning apparently runs successfully on Windows 7. But users of Windows XP should note that on that platform JASigning applications and applets (apart from the SiGML Service Client) now (since 2010-03) require prior installation of the freely available Microsoft Visual Studio C++ 2008 Redistributable Package - which may well be present already on many Windows XP systems.

64-bit Support: Support for 64-bit operation on versions of Windows, Mac OS X and the Java runtime that support this.

Improved HamNoSys/XML Input Error Handling: Recovery from HamNoSys and XML errors in SiGML input texts is now robust - i.e. it should no longer be necessary to re-launch a JASigning application or applet after feeding erroneous SiGML input to it.

JASigning 0.9.5e (2009-12)

These are the main differences between this version and JASigning 0.9.5.d:

Support for Windows Vista.

Support for genuine offline running of a JASigning JNLP application once it has been run and cached from the server for the first time.

Improved quality and range of HamNoSys 4 non-manuals for all avatars.

Improvements in the SiGML Client/Editor application's UI: the editor supports UNDO/REDO (Ctl-Z/Ctl-Shift-Z), and handles unsaved edits in a more forgiving way.

Support in the SiGML Player Applet (SPA) for "piped" SiGML input, that is, for SiGML input that is supplied one sign at a time over an extended period, for example, in response to input from the user.

Support in the SiGML URL Player application for the saving of CAS animation data to a file on the client system, and support for the incorporation of CAS data into a SiGML stream using the <signing_ref> SiGML element.

Support for explicit user control of the frame-dropping policy, intended for use in the case where the frame rate is too high for the graphics hardware.

Definition of standard HTML frames, with associated scripts, to run the SiGML Player Applet (SPA) either with a standard GUI or with a customised one.

Note, however, that the usual same origin policy means that unfortunately it is not possible to deploy a JASigning applet on some other host simply by linking to the standard SPA frame definition on this one.

JASigning 0.9.5d (2008-12)

These are the main differences between this version and JASigning 0.9.5.c:

The two LiveConnect applets have been replaced by a single SiGML Player Applet, which accepts either form of SiGML sequence specification recognised by its two predecessors, that is, a SiGML URL or an explicit SiGML text. It provides feedback to the HTML GUI via Javascript calls.
The applet controls its signing avatar panel via its own event dispatch thread (EDT), which responds to two classes of event: GUI events coming from the user via the HTML/Javascript LiveConnect interface, and call-back events generated by the avatar panel itself. The EDT generates an acknowledgement for each event it receives and at present it processes events serially, that is, it will not accept a new event until it has generated the acknowledgement for its predecessor.
The EDT is thus a potential bottleneck, but the JASigning avatar panel component is intended to operate with enough asynchronous concurrency for this not to be a problem in practice.
This event-based architecture should make it a relatively straightforward matter to enhance the applet while maintaining its robustness: a new operation can be introduced by making appropriate exensions to the applet's Event enumeration, and adding code to the EDT specifying how each new event is to be processed.
The applet has a boolean option controlling the generation of event logging output on the Java console.
(The LC-SiGML-Player and LC-SiGML-URL-Player applet classes are still included in the use-jarp library, but this release does not provide any HTML demos for them.)

JASigning now allocates a local workspace for itself in a directory called .jasigning in the user's home directory.

If the user wishes to define a default JA options set, that is, one common to all JASigning applications, then the file defining these options (jadefaults.properties) should be placed in the user's .jasigning directory. In the absence of this file, a standard JA default options file (which typically is empty) is read from the JASigning installation server instead.

For an avatar with Cacheable access, the locally cached copy is now held in the user's JASigning workspace (.jasigning directory) rather than in the JNLP Persistence Service cache, as before. This means that avatars with Cacheable access can now be used by JASigning HTML applets (which do not have access to the JNLP cache). As a result, Cacheable access is probably now the most satisfactory avatar access mode in most contexts.

JASigning now supports a standard installation-wide set of avatar configuration options.
- The properties that may be defined in this set are:
  - avatar.id
  - avatar.id.list
  - direct.files.avatar.list
  - cacheable.avatars.list
  - avatar.config.base.uri
  - avatar.jar.base.uri
- together possibly with appropriate entries, each for an individual avatar, AV, in one of the forms:
  - avatar.direct.base.uri.AV (if AV has Direct Files access)
  - avatar.jar.uri.AV (if AV has Cacheable access)
- (See the previous release's change list for descriptions of these options.)
- The built-in JA options set does not now include settings for any of these options, but the standard JA options set may still include definitions for them through the JA default options and/or the application/applet-specific options.
- Definitions of avatar options in the JA options set supplement and override the installation's standard avatar configurataion options. Thus, for example, the installation may define a basic set of avatars and standard locations for their definition files, while a particular application may define additions to the installation's standard avatar set, together with locations for these extra avatars, and possibly also non-standard locations for avatars in the installation's original set.

The SiGML Editor/Client application now uses the Preferences mechanism to remember the location of its SiGML folder from one invocation to the next. When first used the application prompts the user to choose the required folder via a standard file dialog.

The behavour of the Frame Number spinner component used in the JASigning applications has been reworked and should now be more robust - for example, in the case where SiGML animation generation is streamed (i.e. asynchronous).

The SiGML Service Player application now supports streamed animation generation, that is, it should be possible (with the appropriate option setting) for that application to play the animation for earlier signs in a SiGML sequence while animation data is still being generated for later signs in the sequence, or even while waiting for later signs to be delivered from the remote source.

JASigning 0.9.5c (2008-07)

These are the main differences between this version and JASigning 0.9.5.b:

Support for the JNLP Applet Launcher (JAL), which allows an applet in a web browser to be launched without any prior download of supporting native libraries and avatar definitions.
(And which despite its name appears not to use the JNLP APIs, but just the JNLP XML file format.)
All the remaining changes are consequences of this one.

No "JASigning Applet Support" installation on the client system, nor explicit offers to install local avatar definitions, if appropriate, when a JASigning JNLP application is launched. Instead all cacheing of native libraries on the client depends on the Java Web Start cacheing mechanisms, or, in the case of an HTML applet, on the JAL's own cacheing mechanisms (whose activities are recorded on the Java console log, for those who are interested). The treatment of avatar data files is described below.

Hence this version has no need of the system-wide JA_HOME preferences setting. In previous versions JA_HOME usually identified the installation directory on the client system. In this version JA_HOME is effectively a fixed internal setting, forced to point to the remote JASigning base directory on the server.

Applet-specific properties may now be set via <param> entries in the HTML <applet> element (or in a JNLP <applet-desc> element), the parameter name in each case being simply the the name of the preference setting it represents.
One consequence of this is that applet-specific properties files are no longer necessary, although they are still supported, for the time being, anyway. Another consequence is that the special avatar parameter of previous versions must now for consistency be named avatar.id

There are now three possible access methods for an avatar's data files:
- ClassPath Access: the folder of data files for the given avatar is packaged in a JAR file together with a Java access class (details below) whose sole purpose is to provide a resource base against which the avatar files can be accessed by a Java class loader.
  Provided this avatar access JAR is placed on the classpath of a JASigning application or applet the avatar is automatically accessible - and will benefit from Java's standard client-side caching mechanisms.
  The drawback of this method is that on first use, the user is forced to wait while every JAR of this kind is downloaded into the Java client-side cache before the application or applet can start. This is the default access method. (And it is also used to access the COMMON/config.xml file.)
- Direct Files Access: this is essentially the access method used in previous versions, that is, the avatar data files are obtained via a base URL for the folder containing these files - but in previous versions that was typically a file: URL on the client, whereas now it will typically be a remote http: URL.
- Cacheable Access: this is similar to the first access method in that the avatar data files are packaged with an access class in a JAR file. But in this case the JAR is not put on the Java classpath; instead JASigning downloads it only on demand and places it in the client's JNLP cache, from whence a temporary copy is taken and dynamically loaded. (Using the JNLP cache for this purpose seems to be a mistake since JNLP is not available to HTML applets, so at present this access method is available only to JNLP applications and applets. But using a custom-built cache instead of the JNLP cache - as JAL does -- would not be difficult to implement and JASigning may well change to do this in the near future.)
  The access class for a given avatar, marc say, is a miniscule Java class called marc.Access whose compiled class file Access.class is placed in the marc avatar data folder. The Java code for this class is simply:

package marc; public final class Access{}

There are a number of new properties/preferences settings to control the avatar access mechanisms, and several of the old setttings take on a more prominent role. As noted above, an HTML applet can now control these settings by means of <param> entries in the relevant HTML <applet> element.
- avatar.id: The name of the avatar to be loaded initially.
- avatar.id.list: Colon-separated list of avatars available to the application/applet, e.g. anna:marc.
  (Since there is no longer an installation folder in the file system, JASigning is no longer able to determine this list for itself by inspecting its agconfig subfolder.)
- direct.files.avatar.list: Colon-separated list of avatars using the Direct Files access method.
  May be omitted (or explicitly null, or explicitly empty) if the list is empty.
- cacheable.avatar.list: Colon-separated list of avatars using the Cacheable access method.
  May be omitted (or explicitly null, or explicitly empty) if the list is empty.
- avatar.config.base.uri: The default base location for the data folders of avatars in the Direct Files list.
- direct.files.base.uri.AVATAR: Assuming AVATAR appears in the Direct Files avatar list, an entry of this form explicitly specifies the URL of its avatar data folder, overriding the default location implicit in the avatar.config.base.uri setting.
- avatar.jar.uri.AVATAR: Assuming AVATAR appears in the Cacheable avatar list, an entry of this form specifies the URL of its access JAR file.

Clearly, the avatar.id.list should include the avatar.id value, and should contain as sublists both the direct.files.avatar.list and cacheable.avatar.list values.

As well as the various client-side cacheing mechanisms, this version of JASigning currently caches all avatar data in memory for the remainder of the session once loaded. This could amount to a good few Mb if many avatars are used, but probably not enough to be a problem in most environments.

At present this version of JASigning makes no attempt to set the Java Applet runtime parameters for the user, since the separate installer which used to do this is is no longer used.

JASigning 0.9.5b (2008-02)

JASigning is a software system for scripted performance of sign language animations by a virtual human, or avatar. The scripting language used to define these animations is SiGML (Signing Gesture Markup Language).

SiGML is an XML application language, derived from HamNoSys, the sign language notation system developed at the University of Hamburg.

JASigning is based on work undertaken at UEA in conjunction with our partners in the ViSiCAST and eSIGN projects. It is an alternative to the Avatar Plugin software released at the end of the eSIGN project. One important difference is that JASigning runs on Mac OS X as well as Windows.

JASigning is a combination of Java software with supporting native libraries. So, use of JASigning requires that the Java runtime software, version 5 or later, is installed on the client system. Java is pre-installed on all Mac OS X systems, and on many Windows systems.

The standard method of accessing a JASigning application or applet is via Java Web Start using JNLP, the Java Network Launch Protocol.