542fb50bf1
The ~M and ~M` EWTS change had not fully been made. Someone submitted a bug report 911472 that alerted me to this.
2004-03-07 17:02:35 +00:00
db2ef438d4
Andres requested customization like this. You can now override any property in build.xml using a file 'build.properties'.
2004-03-06 23:17:43 +00:00
e0928d8472
New EWTS for 0F82 and 0F83.
2004-03-06 23:00:40 +00:00
bb8fa6c58f
Now the clear button in the http servlet version actually clears. Also added "synchronized" to some methods to ensure that concurrent threads don't crash.
2004-03-03 00:33:18 +00:00
d436a4d462
Removed David Chapman's recently added line for U+0F82 -- a line for U+0F82 already existed, and the new line had incorrect TM and incorrect TMW mappings. I changed the existing line for U+0F82 to use the EWTS {~M`}.
2004-03-02 04:29:41 +00:00
8eaaeaa202
Fix careless error: I had the same TMW character for ~M and ~M`!
2004-02-22 09:14:56 +00:00
b14833b5b9
Change ^M to ~M to conform to spec.
...
Introduce ~M` (for 0F82).
2004-02-20 15:07:49 +00:00
e5454d3720
Updated the translation tool to conform to the Personal Profile specification of Java.
...
Before it would run in pocket pc's through the more restricted personalJava specification
but Sun's vm for pocket pc's project was terminated. Now it is designed to run under
IBM's VM for pocket pc's called J9 which implements the Personal Profile specification.
Such specification also supports awt, but not swing so still there is no (hope for) support
of Tibetan script in the pocket pc's,
2004-02-07 18:21:17 +00:00
274e1736be
Deleted cut-and-paste goof.
2004-01-17 19:45:31 +00:00
c69ba26c60
TString now has tracks what Roman transliteration system it is using. Next up is to make ACIPConverter handle EWTS or ACIP TStrings.
2004-01-17 19:28:54 +00:00
48b4c5cb07
Added a Unicode->ASCII dump for debugging *->Unicode conversions. To use it, use 'java -cp Jskad.jar org.thdl.util.VerboseUnicodeDump'.
2004-01-17 17:10:12 +00:00
6fdb2a26bb
Added a Unicode->ASCII dump for debugging *->Unicode conversions. To use it, use 'java -cp Jskad.jar org.thdl.util.VerboseUnicodeDump'.
2004-01-17 16:52:38 +00:00
9dd95c5524
I saw this error when I wasn't expecting it, so now, curious, I print more details.
2004-01-17 16:51:33 +00:00
f490978227
Now using Jskad/build.properties file, which I keep looking like this:
...
halt.after.trouble=no
2004-01-17 16:43:47 +00:00
4dd40809a5
A user reported that q` caused a crash with TCC keyboard #1 . Fixed. TCC keyboard #1 does not support q~ though.
2003-12-21 06:27:36 +00:00
c1aa81e943
RFE 860190: ACIP->Unicode now gives a warning when it outputs something that can't be represented in TMW.
2003-12-16 07:45:40 +00:00
848349fd3a
More tests.
2003-12-15 08:16:06 +00:00
e7a9e7968f
ACIP->Unicode now uses two characters for consonants instead of one. This matches the dislike for characters like U+0F77 etc.
...
ACIP->Tibetan was not giving an error for BCWA because it parsed like BCVA. Fixed.
2003-12-15 07:32:14 +00:00
e9f7b2dfed
If you want curly brackets around folio markers, you'll have to set
...
the system property
thdl.acip.to.x.output.curly.brackets.around.folio.markers to true.
2003-12-14 08:47:03 +00:00
8664571577
Warnings were not being detected correctly. Fixed.
...
ACIP->Unicode uses U+0020, ' ', for whitespace. ACIP->TMW uses the
TMW whitespace for whitespace.
2003-12-14 08:38:10 +00:00
01e65176d4
Using less memory and time to figure out if warnings occurred.
2003-12-14 07:41:15 +00:00
76c2e969ac
Fixed ACIP->Unicode bug for YYE etc., things with full-formed
...
subjoined consonants and vowels.
Fixed ACIP->TMW for YYA etc., things with full-formed subjoined
consonants.
2003-12-14 07:36:21 +00:00
f625c937ee
ACIP {B} was not being treated like {BA}; instead, an error was resulting. All the five prefixes were affected.
2003-12-14 05:54:07 +00:00
a0e6db11c0
Very minor cleanup.
2003-12-13 21:59:31 +00:00
fcb0c57792
I'm committing an old edit that may or may not help headless tests --
...
they seemed fine anyway, but what's the harm?
2003-12-13 21:50:23 +00:00
8411ebe932
You couldn't build from the src-dist. I think you can now; it's more
...
inclusive.
2003-12-13 21:46:09 +00:00
4c30657afa
Adding tests for an ACIP keyboard that will never work correctly, and
...
probably never even be useful. But they were lying around from a
while back, so here are the tests.
2003-12-13 21:34:33 +00:00
02967539b0
Slightly improved Jskad's internal documentation. Links to converters' docs.
2003-12-10 07:04:35 +00:00
581643cf59
{DAN,\nLHAG} used to be treated like {DAN, LHAG} but that got broken. Fixed.
...
Added tests for lexer's handling of ACIP spaces etc.
2003-12-10 06:55:16 +00:00
8e673bbc2c
{NGA,} becomes {NGA\u0f0c,} now instead of {NGA\u0f0b,}.
...
Note: ACIP->Unicode for {NGA,} was not giving the Unicode that {NGA\u0f0b,} gives before.
2003-12-10 06:50:14 +00:00
a466bad939
ACIP->TMW now supports EWTS PUA {\uF021}-style escapes. Our extended ACIP is thus TMW-complete and useful for testing.
2003-12-08 07:51:45 +00:00
a39c5c12b0
ACIP->TMW now supports EWTS PUA {\uF021}-style escapes. Our extended ACIP is thus TMW-complete and useful for testing.
2003-12-08 07:15:27 +00:00
8f7322a056
Use absolute paths when invoking the external viewer; it doesn't know what our current working directory is.
2003-12-08 06:53:37 +00:00
b617f761d5
ACIP->TMW for {^GONG SA } used to fail; fixed.
2003-12-07 20:05:41 +00:00
115534e688
ACIP->TMW for {^GONG SA } used to fail because we had \u0F38 in the ToWylie section. Now it's in the <?Input:Numbers?> section because I didn't want to introduce a new section. If WylieWord has trouble due to this misuse of the 'numbers' category, we'll introduce a new category, 'other'.
...
TMW->EWTS improved as a result -- {\u0F38.gonga sa } is produced now where {\u0F38agonga sa } was once produced. Even the better version is imperfect; see bug 855877.
2003-12-07 19:40:59 +00:00
597cf408dd
Fixed help message.
2003-12-07 19:10:36 +00:00
4adf87c401
Updated comments only.
2003-12-06 20:36:56 +00:00
3f18623977
Added comments only.
2003-12-06 20:26:45 +00:00
6232ee9170
Added comments referring to a user guide in development now.
2003-12-06 20:26:15 +00:00
c43e9a446b
Revamped some ACIP->Tibetan error messages.
2003-12-06 20:19:40 +00:00
c9c771d1ee
ACIP {&}, as in {KO&HAm,}, is supported.
2003-11-30 02:18:59 +00:00
ac412c994b
Now {Pm} is treated like {PAm}; {Pm:} is like {PAm:}; {P:} is like {PA:}.
2003-11-30 02:06:48 +00:00
e7c4cc1874
Updated to be in sync with latest EWTS draft.
2003-11-29 22:59:39 +00:00
ffd041e32c
ACIP->TMW and ACIP->Unicode now allow for Unicode escapes like K\u0F84. This means that the lack of support for ACIP's backslash, '\\', is mitigated because you can turn ACIP {K\} into ACIP {K\u0F84}.
...
Support for U+F021-U+F0FF, the PUA that the latest EWTS uses, is not provided.
Also, we've traded some speed for memory -- DuffCode now uses bytes, not ints.
2003-11-29 22:57:12 +00:00
dfaae4be93
ACIP->TMW and ACIP->Unicode now allow for Unicode escapes like K\u0F84. This means that the lack of support for ACIP's backslash, '\\', is mitigated because you can turn ACIP {K\} into ACIP {K\u0F84}.
...
Support for U+F021-U+F0FF, the PUA that the latest EWTS uses, is not provided.
2003-11-29 22:56:18 +00:00
946d8cbc72
Updated the code I used for testing to generate the file containing all glyphs in TM and all glyphs but one in TMW.
2003-11-29 16:22:26 +00:00
16bfeac641
These issues are non-issues; removing these comments.
2003-11-25 00:31:33 +00:00
d3d0ff23a8
Chris Fynn and Tony Duff answered my questions about U+0F3F and U+0F3E.
2003-11-25 00:28:18 +00:00
b8608797aa
Updated the code I used for testing to generate the file containing all glyphs in TM and all glyphs but one in TMW.
2003-11-24 05:59:32 +00:00
8d18ac53cb
N+D+Ya, not N+D+ya, w+Wa, not w+wa .. use W, R, and Y where appropriate.
...
Found another inconsistency between Unicode and the TM/TMW docs. I've sent e-mail to Tony Duff asking who's right, but I'm putting this in the errata under the assumption that even if Unicode is wrong, Unicode's wrong view will somehow rule the day.
Also, TMW->EWTS now generates \uF021-\uF0FF or \u0F00-\u0FFF escapes when appropriate. A few TMW glyphs still give errors.
Also, there's now a test to be sure that TM<->TMW and TMW->EWTS won't break in the future (except for the one glyph in TMW that isn't in TM, that one isn't tested). The baselines have not been hand-verified, but changes will be detected.
2003-11-24 05:50:42 +00:00
dchandler