now a preference.
In addition, Jskad now raises an error dialog when you try to "Save
As" to a bad place or open a file that doesn't exist or isn't
readable.
Jskad/extensions. If you're lazy, you can move them to
extensions/drop-ins, but the correct thing to do is to move x*.jar to
$ANT_HOME/lib [next to vamp.jar, if you're already set up for Java Web
Start builds]. This is a side effect of improving the nightly builds.
Nightly builds now feature an HTML summary of the JUnit test results,
a datestamp, and full API docs in two flavors.
If you use a patched vamp.jar [e-mail me] that can run when an X11
display is not available (there is not an analogous problem for
Windows servers, I suspect), all you have to do to put up a nightly
builds site is to set up CVS access so that no password is requires
using SSH public-key crypto (sf.net documents how to do so well) and
then use the following daily cron job on your Unix box:
#! /bin/sh
renice +19 -p $$ >/dev/null 2>&1
su -l joe-user /bin/sh -c /var/www/thdl/nightly/doTheBuild.sh
where joe-user is an unprivileged user who has installed Ant properly
(see the updated BuildSystems.html on the developer's site off of
thdltools.sf.net) and set himself up a Jskad sandbox with a Fonts
sandbox underneath it in, e.g., /var/www/thdl/nightly/Jskad. Here's
doTheBuild.sh:
#! /bin/sh
JSKAD=/var/www/thdl/nightly/Jskad
DEST=/var/www/thdl/nightly/builds
HISTORY=/var/www/thdl/nightly/history
DATE=`date`
if test ! -d $DEST; then \
echo "$DEST does not exist ($DATE)." >> history; exit 1; fi
(cd $JSKAD && ant dc-nightly-build \
&& rm -fr ${DEST}/* \
&& cp dist/nightlyBuild.zip $DEST \
&& cd $DEST \
&& unzip nightlyBuild.zip)
if test $? != 0; then echo "NIGHTLY BUILDS FAILED on $DATE" >> $HISTORY; exit 2; fi
DDDATE=`date`
echo "Success on start=$DATE end=$DDDATE" >> $HISTORY
exit 0
into Jskad's JAR file.
Doing so required that I cut out a lot of fancy HTML code. The correct fix
is to use XML to store the meat and then use XSL to generate two forms of
HTML: one dumb enough for Java, one for use on the THDL tools website.
e-mailed to me. Tibbibl is an editor for XML-based bibliographies of
Tibetan texts. All I did was change the package from org.thdl.xml to
org.thdl.tib.bibl and add boilerplate; no changes to Than's code were
made.
Tibbibl features a diacritic input tool which Jskad might want to
swipe.
that I like unit tests, my Unicode conversion work is going to have to
be thorougly tested for reasons I will outline in
http://thdltools.sf.net/BuildSystems.html later today.
Added the freely licensed JUnit 3.8.1 binary to the repository, along
with some README files. Added a new supporting buildfile,
junitbuild.xml. 'ant clean check' is now good to go (though it uses
the text UI for JUnit, and some developers may want the Swing GUI)
Also, I cleaned up build.xml a bit, including adding all buildfiles
(but not junit.jar and things like that) to the source distribution
('ant src-dist') rather than just build.xml.
I'm committing in order to sync with my laptop, really. This stuff will disappear
and reappear in better form later, after a holiday of coding and eggless,
alcohol-free nog.
and for this package only.
I'm committing in order to sync with my laptop, really. This stuff will disappear
and reappear in better form later, after a holiday of coding and eggless,
alcohol-free nog.
UnicodeCodepointToThdlWylie.java.
Added a new class, UnicodeGraphemeCluster, that can tell you
the components of a grapheme cluster from top to bottom. It does not
yet have good error checking; it is not yet finished.
Next is to parse clean Unicode into GraphemeClusters. After that comes
scanning dirty Unicode into best-guess GraphemeClusters, and scanning
dirty Unicode to get nice error messages.
because a Japanese scholar has an "Extended Wylie" also.
NFKD and NFD have a new brother, NFTHDL. I wish there weren't a need,
but as my yet-to-be-put-into-CVS break-unicode-into-grapheme-clusters code
demonstrates, the-need-is-there. forgive-me for the hyphens, it's late.
characters, for example.
Normalization forms NFKD and NFD are supported for the Tibetan Unicode
range. I don't like either, actually. I've tested NFKD, but I've not yet
committed the tests.
and the build system is not yet aware of them.
I'm adding some classes for representing legal tsheg-bars (syllables, for the
most part) in Unicode. These classes were designed bottom-up (OK, OK --
they weren't designed designed, but I had to write down everything I knew
about Tibetan syntax somewhere). The classes are aware of extended
wylie. I doubt the Javadocs work yet, and I'm still testing (and am not
committing my testing code with these as it is not yet ready).
Next on my list--fix these up to reflect my new awareness of suffix particles
(like le'u'i'o) add classes to support syntactically incorrect Unicode
sequences. Then add a UnicodeReader, and we've got the back end of
a Tibetan Unicode shaping system (like half of MS's Uniscribe or Apple's
Worldscript or FreeType Layout or Omega's OTPs).
A top-down design would not have included LegalTshegBar. But now that
my itch has been scratched, potential uses are lingering about. For example,
it would be nice to scan some input and break it into LegalTshegBars,
punctuation/marks/signs, and illegal stacks. Then we could alert the client
of the illegality, its precise form, and its precise location.
The real system for turning a Unicode stream into an internal representation
suitable for conversion to EWTS/ACIP/XHTML/what-have-you need not be
aware of Tibetan syntax. But to make the very best conversion from
Unicode to, e.g., EWTS, it is necessary to konw that gaskad is better
represented as gskad, but that jaskad is not the same as jskad.
