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 it is unfortunately not possible to deploy a JASigning applet on some other host simply by linking to the standard SPA frame definition on this one.
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.
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.
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{}
<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 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.
RE 2009-12-14