[Waba-spec] Re: A Font counter-counter proposal

[Sean L. <se...@cs...>]

Guilherme quoth:

> Maybe you could adopt what i made in SuperWaba.
> My String class has this:
>    /** The bytes are converted to char and vice-versa using the
> CharacterConverter associated in this charConverter member. */
>    public static waba.sys.CharacterConverter charConverter;

>    public String(byte[] value, int offset, int count);

>    public byte[] getBytes();

I like the general idea of supporting the getBytes() function and 
String(byte[],int,int) constructor.  Especially since we'd need to read 
and write to streams.  And you picked exactly the right ones to support 
(rather than the other myriad of byte-conversion methods).  AND I like 
the idea of a swap-in coder.
But I'm a little queasy about adding a data member to a Java-compliant a 
class as java.lang.String!  This really pushes us away from the Java 
standard rapidly.

So where do you stash a swap-in converter if not String?  Maybe the best 
place would be as a static member of the waba.sys.Convert class.  A few 
other quibbles to otherwise a nice idea:

> /** This class is used to correctly handle international character
> convertions.
>   * The default character scheme converter is the 8859-1. If you want 
> to use
> a different one,
>   * you must extend this class, implementing the bytes2chars and 
> chars2bytes
> methods, and then
>   * assign the public member of java.lang.String charConverter to use 
> your
> class instead of this default one.

In a PDA, ISO-8859-1 really *shouldn't* be the default.  The default 
really should be some form which preserves Unicode values, like UTF-8.  
Unfortunately, Sun's suggested "default" (if your operating system 
doesn't have anything better) is indeed ISO-8859-1.  I think that was a 
big mistake on their part, but oh well.

If we're going the drop-in coding route, we oughta provide, at the very 
least, free encoders in the core spec which do ASCII, (more critical 
than others) UTF-8, plus maybe UTF-16BE, UTF-16LE, and UTF-16. That's 
all the encodings one's expected to see typically anyway, and those can 
all be done easily without a lookup table.  Kaffe's probably got GNU 
versions of the encodings if you want to grab 'em.

> public class CharacterConverter

Converter isn't the right word.  This should be an encoder, something 
like CharacterEncoder, or some such.  No big deal though.  BTW, there's 
a standard non-public Java class called java.lang.StringCoding, which 
has almost identical functions as yours, they're called:

     static byte[] encode(char[] ca, int off, int len);
     static char[] decode(byte[] ba, int off, int len);

...maybe those would be better names, just a suggestion.

Also, I'm not sure if you should override CharacterEncoder, er, 
CharacterConverter, or if we should have an interface to extend instead, 
where the default class extending the CharacterEncoder interface is 
ISO88591Encoder.  Dunno about that.  Perhaps it wouldn't buy us anything 
in terms of memory consumption.

Sean