CWASA Release Notes

Home >> JASigning

---

JASigning Release Notes

The current release of JASigning can be found at http://vhg.cmp.uea.ac.uk/tech/jas/std/ which provides links for downloading applications and viewing web pages using the virtual signing technology. The standard release is 0.9.5s.

The development version of JASigning can be found at http://vhg.cmp.uea.ac.uk/tech/jas/dev/ which provides links for development versions of applications and web pages. The development version is 0.9.5z.

Notes for the current and previous releases are found below. There are also notes on development versions that are not currently guaranteed to be stable. Users are welcome to try these and provide feedback via the JASigning Issue Reporting page. It is helpful to consult the JASigning Platform Issues notes.

JASigning 0.9.5z (Development Version)

Release found at http://vhg.cmp.uea.ac.uk/tech/jas/095z/.

These are currently no differences between this version and JASigning 0.9.5s.

JASigning 0.9.5s (Standard Version)

Release found at http://vhg.cmp.uea.ac.uk/tech/jas/095s/.

This release is currently the same as JASigning 0.9.5n.

JASigning 0.9.5n (2013-11)

Release found at http://vhg.cmp.uea.ac.uk/tech/jas/095n/.

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

• Uses a locally signed version of the JOGL libraries with compatible JAR manifest entries.
• All Characters currently use separate texture files.

JASigning 0.9.5m (2013-10)

Release found at http://vhg.cmp.uea.ac.uk/tech/jas/095m/.

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

• Adds Application-Name, Permissions, and Codebase attributes to JAR file manifests for Java 6u65 and Java 7u45.
• Replaces Trusted-Library attribute by Caller-Allowable-Codebase.

JASigning 0.9.5l (2013-06)

Release found at http://vhg.cmp.uea.ac.uk/tech/jas/095l/.

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

• Open GL handling uses JOGL2: Uses Version 2 of JOGL, the Java binding for Open GL.
• The Platform Issues reported for JASigning 0.9.5j continue to apply.

• The properties/preferences setting ja.force.remote.ja.home now defaults to true when not provided.
• Adds Trusted-Library attribute to JAR file manifests for Java 6u45 and Java 7u21.
• Correctly signs JNLP files for trusted launching via current browsers.

JASigning 0.9.5k (2013-06)

Release found at http://vhg.cmp.uea.ac.uk/tech/jas/095k/.

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

• Open GL handling uses JOGL1: Reverts to using Version 1 of JOGL, the Java binding for Open GL.
• The Platform Issues reported for JASigning 0.9.5i continue to apply.

JASigning 0.9.5j (2012-08)

Release found at http://vhg.cmp.uea.ac.uk/tech/jas/095j/.

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

• Open GL handling uses JOGL2: Now uses Version 2 of JOGL, the Java binding for Open GL, which is required for the SiGML Player Applet (SPA) on Mac OS X.

• Platform Issues: Unfortunately there are problems on recent Mac OS X systems:
  • Mac OS 10.6 Snow Leopard: Web pages using SPA function correctly. JNLP Player Applications show some unacceptable rendering artefacts, so consider JASigning 0.9.5.i instead.
  • Mac OS 10.7 Lion and 10.8 Mountain Lion: Web pages using SPA function correctly. JNLP Player Applications fail to run when using Java 7 but function correctly on a system that uses the initial Apple release of Java 6.
  • Windows: Windows users should observe correct functionality.

JASigning 0.9.5i (2012-08)

Release found at http://vhg.cmp.uea.ac.uk/tech/jas/095i/.

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

• Improved Avatar Loading: Fixed a bug which caused loading of new avatars to fail for locales using European number representation due to incorrect setting of camera properties.

• Updated Security Certificate: Uses a re-issued Code Signing Certificate to replace the one used since JASigning 0.9.5.f which has expired.

• Platform Issues: Unfortunately there are problems on recent Mac OS X systems:
  • Mac OS X : HTML Applets: Most browsers on Mac OS X now create a new process to run Java applets on web pages. This means that nothing is displayed when the SiGML Player Applet (SPA) is loaded, although the Java Console reports normal processing of signing events. Consider SPA in JASigning 0.9.5.j instead.
  • Mac OS 10.6 Snow Leopard : JNLP Player Applications: Should function correctly.
  • Mac OS 10.7 Lion and 10.8 Mountain Lion : JNLP Player Applications: Fail to run when using Java 7 but function correctly on a system that uses the initial Apple release of Java 6.
  • Windows: Windows users should observe correct functionality.

JASigning 0.9.5h (2012-02)

Release found at http://vhg.cmp.uea.ac.uk/tech/jas/095h/.

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

• Françoise Avatar: In addition to the standard avatars anna, and marc, a new avatar francoise is included. This avatar was developed by UEA and LIMSI within the Dicta-Sign project for use with project outcomes.

• Enhanced Flexibility and Precision in SiGML: The HamNoSys notation allows for changes in hand posture that might involve simultaneous movement and changes to hand shape and hand orientation. Implementation in Animgen assumes all changes are synchronised. Detailed examination of natural signing suggests that changes to orientation and shape are often established early in a movement. Additional attributes orientation_lead and shape_lead have been added to handconfig elements in SiGML to enable more precision in signing. If linguistic research identifies the normal pattern of sign language performance, Animgen could be modified to provide a different default behaviour.

This release was supported by the Dicta-Sign project and is documented in Deliverable D3.3 of the project.

JASigning 0.9.5g (2011-02)

Release found at http://vhg.cmp.uea.ac.uk/tech/jas/095g/.

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

• Improved Handling of Initial Options for Apps: 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.

• Improved CAS Input and Output: CAS is the system's animation data format, which is amenable to conversion for use with other animation systems. 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.

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

• Fine-grain Control of Avatar Posture and Motion: HamNoSys uses discrete ranges of values for features of the signer's posture and motion such as the orientation of hands and fingers and the direction and size of a movement. The HamNoSys “between” operator (\) can be used to specify a value halfway between two adjacent values in any of these discrete ranges. For example, specifying an extended finger direction between “up” and “left” produces a hand pointing diagonally (upwards and to the left).
  • The G-SiGML format used as direct input to the animation generation generalises this notion by allowing the specification of an additional “ratio” value, which may be an arbitrary real number between zero and one. This specifies a relative weighting between the two base values, thus effectively replacing HamNoSys's discrete range by a continuous one, giving arbitrarily fine-grain control over such features. Intermediate weighting values of this kind are currently supported for extended finger directions, palm orientations, and locations.
  • G-SiGML provides an alternative form of fine-grain control of direction – for features such as hand orientation and motions – by allowing a direction to be expressed as a vector of integer values specifying relative weightings in Cartesian space. For example, the HamNoSys direction “upwards and leftwards” (positive y and x, respectively) can be represented in G-SiGML as a direction value of “1 1 0”. Thus, greater relative degrees of upward-ness in the direction can be achieved by specifying direction values of “1 2 0”, “1 3 0”, etc.

This release was supported by the Dicta-Sign project and is documented in Deliverable D3.2 of the project.

JASigning 0.9.5f (2010-07)

Release found at http://vhg.cmp.uea.ac.uk/tech/jas/095f/.

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

• Ambient Motion: Some of the avatars, including the standard avatar, Anna, are now capable of ambient motion, both when idle and when signing. Versions of the applications and applets supporting this feature have been provided. An application menu allows this feature to be enabled/disabled both during signing and during idle periods, as required by the user. Finer grain control is provided through the system's standard options setting mechanism. Adding this feature to the other avatars is technically as simple matter, but this awaits more detailed evaluation and user feedback on the feature.

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

• Support for Windows 7: 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: All JASigning applications and applets now support 64-bit operation whenever this feature is provided by the underlying Windows, Mac OS X and Java runtime systems.

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

This release was supported by the Dicta-Sign project and is documented in Deliverable D3.2 of the project.

JASigning 0.9.5e (2009-12)

Release found at http://vhg.cmp.uea.ac.uk/tech/jas/095e/.

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

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

This release was supported by the Dicta-Sign project and is documented in Deliverable D3.1 of the project.

JASigning 0.9.5d (2008-12)

Release found at http://vhg.cmp.uea.ac.uk/tech/jas/095d/.

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

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

Release found at http://vhg.cmp.uea.ac.uk/tech/jas/095c/.

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

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

Release found at http://vhg.cmp.uea.ac.uk/tech/jas/095b/.

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.

---

Home >> JASigning