> Hi, > Great hearing from you. Actually, I sh ould give you some credit cause you sta rted the codepoint reordering thing fir st, though the ACE37 idea really came a bout earlier than I saw your draft. An yway, I think my code block shifting me chanism is much more simple and can suc cessfully get 21+ han ideographs which is much more acceptable than DUDE's cur rent state. > When the diff value is less than 0xF, what is the ACE37 form for it ? > When diff<=0x7F it will be in the 7bit form, that is <b4><b32> the reason <b4> has to be used is that it signifies how many more characters a re used for the particular codepoint (or what I termed as codepoint bracket). If only a <b32> is used, then you wont know whether it is a 15 bit form or a 22 bit form. Therefore, if diff=0xF, ACE37=wf > And any example C doe for ACE37 avai lable on the web ? > Not yet, David & I will work on it and post it on the web if more people are i nterested in the idea and think that it could be better than DUDE. For now you can check out my excel worksheet to see how it works. http://www.dnsii.org/ace3 7/ace37-encode.xls (for encoding), http ://www.dnsii.org/ace37/ace37-decode.xls (for decoding). Edmon > Thanks. > > Soobok > > > > >Chung & Leung [Page 6] > > > >ACE37 ACE Utilizing All 37 Alphanumeric Characters July 2001 > > > > > > > > The following table explains how base-4 characters are combined > with > > > > base-32 characters to form a representation of a diff (key: > b4=base- > > > > 4, b32=base-32): > > > > > > > > diff value |bits| ACE37 Form > > > > ------------------------- |----|---------------------------- > > > > diff<=0x7F | 7 | <b4><b32> > > > > 0x80<=diff<=0x7FFF | 15 | <b32><b32><b32> > > > > 0x8000<=diff<=0x1FFFF | 17 | w<b4><b32><b32><b32> > > > > 0x20000<=diff<=0xFFFFF | 20 | ww<b32><b32><b32><b32> > > > > 0x100000<=diff<=0x10FFFF | 22 | <b4>w<b32><b32><b32><b32> > > > > > > > > Note that the "bits" column represents the maximum number of > > > > significant bits for the giv en diff value. For example when > > > > diff<=0x7F, the maximum value is 0b1111111, therefore the number of > > > ----- Original Message ----- > From: "Edmon" <[EMAIL PROTECTED]> > To: "Natalia Syracuse" <nsyracus@ietf .org>; "David Leung" > <[EMAIL PROTECTED]>; "Marc Blanchet" < [EMAIL PROTECTED]>; > <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Friday, July 06, 2001 12:48 AM > Subject: [idn] Re: permission <draft- ietf-idn-ace37-00.txt (attach) > > > > Hi all, > > > > I was unaware that the workgroup no longer accepts new drafts. Anyway, I > > have drafted a new ACE based on the simplicity of DUDE which has hugely > > improved compression. Worst case s cenario CJK could have 21 han > characters! > > Attached below is a copy of the dra ft (for my original submission), you > can > > also find it at http://www.dnsii.or g/idn-ace37-00.txt (easier to read) and > > hopefully in the i-d-n.net website soon. > > > > ACE37 is based on the one-pass one- mode scheme of DUDE (diiferential XOR), > > then utilizes a simple code block s hifting (similar to the reference > points > > in the AMC series) to hugely increa se the capacity for CJK (worst case > > scenario 21 han characters!) and th en utilizes base-32 for compression (as > > in LACE) (DUDE and AMC-w/v uses bas e-32 only for flagging). In addition > to > > base-32, a base-4 scheme is introdu ced by using the remaining characters > > {wxyz}. These contain 2 bits of ch aracter information and doubles as an > > indicator for codepoint brackets. All the while, the algorithm is kept to > > be as simple as DUDE. > > > > Hopefully you might find that it is interesting and appropriate to be > > considered as an ACE within the IET F. Afterall, it was intended to be an > > integrated version of the three pri mary ACEs: DUDE, LACE and the AMC > series, > > identified by the ACE design team r eport. > > > > Looking forward to all your inputs. > > > > Edmon >
