sod-builder 0.9 - README

stroke-order-diagram builder allows you to visually record the stroke sequence of glyphs from specially prepared fonts.


The application is written in Java; it uses AWT / Swing for the UI, classes from the gnu.java.awt.font package (part of the GNU Classpath library) to extract / transform glyph contours from true-type / open-type fonts and code from the image4j library (see sod.io.resource.util.BitmapReader.java) to read bitmaps.

You may run the application from the command line, using "java sod.Builder 9E93," or embed it in a web-page (as an applet) with the following XHTML code:

  <!-- specifies the class to load, the directory in which the class resides
       and the initial size of the applet -->
  <applet code="sod.Builder.class" archive="." width="340" height="680">

    <!-- specifies the text to display if the page is opened
         by a browser that can't execute Java applets -->
    Your browser does not support Java applets.

    <!-- sets the applet's "ucs" attribute which specifies the glyph to load;
         this tag is required -->
    <param name="ucs" value="9E93" />

    <!-- the optional "stroke-order" attribute is used to pre-render the
         stroke-sequence -->
    <param name="stroke-order" value="" />

    <!-- another optional attribute -->
    <param name="modified-date" value="" />



SPACE Cycles forward through the available strokes; use the SHIFT modifier to cycle backwards.

ENTER Adds the current stroke to the end of the sequence.

BACKSPACE Removes the stroke at the end of the sequence.

TODO (need to put some flesh on these bones):
  • Support applet-servlet / datasource communication.
  • When run as a desktop application, allow the user to select glyphs from a specified font.
  • When run as an applet, fetch the contours, of the glyph, from some application running on the server.

Currently, the application has the following limitations:

  • When run as a desktop app., there is no way to select a glyph within the application.

  • There is, also, no way to retrieve, edit or persist a stroke sequence from a datasource. This can, however, be achieved rather easily (see sod.io.datasource.DataSource).

  • A font resource needs to be packaged with the application. This is fine for desktop apps. but not the ideal setup for an applet. Due to the sheer number of glyphs (6355 kanji in the JIS-X-0208 kanji set) Japanese fonts tend to be tens-of-megabytes in size. Moreover, commercial fonts should never ever be distributed without licensing.

    The solution is to fetch the contours, of the glyph, from some application running on the server.

  • Applets created with this code will only work on the local machine; unless digitally signed.

    This is because Class.getResourceAsStream(...) cannot be used to read fonts from within the applet's archive.

    The createFonts (factory) method in gnu.java.awt.font.FontFactory has the following signature:
        public static FontDelegate[] createFonts(java.nio.ByteBuffer buf)...
    while the signature of Class.getResourceAsStream(...) is
        public java.io.InputStream getResourceAsStream(...);
    Class.getResourceAsStream(...) returns an InputStream while the createFonts method requires a ByteBuffer, a memory-mapped region of the file, obtained as follows:
        // load the font
        FileInputStream fis = new FileInputStream(path);
        FileChannel fc = fis.getChannel();
        ByteBuffer buf = fc.map(
                java.nio.channels.FileChannel.MapMode.READ_ONLY, 0,
    Unfortunately, there is no way to obtain a FileChannel from an InputStream.
August.1.2011 (BM)

Valid XHTML 1.0 Transitional