Tom Zerucha wrote:
> 
> On Fri, Apr 07, 2000 at 03:05:09PM -0400, Dong Liu wrote:
> 
> > Speak of the DOC format, I have some complain about it. It does NOT
> > support 8bit characters, such as Chinese codings. So I hacked
> > CSpotRun and txt2pdbdoc to use zlib. But I'm not very satisfied
> > with, zlib is too large and too slow in the Palm.
> 
> First, DOC *does* support 8 bit characters.  It doesn't compress them
> as nicely (part of the compression assumes space-ascii and has to
> escape highbit characters).
> 

Maybe I should say that all the tools producing DOC don't support 8 bit
characters. I have tried dtk, txt2pdbdoc and mkdocj, they all core
dumped with certain Chinese texts.

> However it can compress an 8-bit stream with repeated bytes, in fact
> that is where most of the compression comes from.
> 

Even those tools didn't core dump, the compression ratio was around
90%.

> The simplicity and decompress speed come partially from assuming
> things about the input stream.
> 
> And how are your using Zlib?  I ported it as a GLib for use with GCC,
> and found it reasonably fast.  How many K/sec are you trying to get?
> 

Yes, I compiled it as GLib (with prc-tools-0.5), I get a diff 
for zlib-1.1.3  from some place I forgot in the net.  

I had to change txt2pdbdoc to use 16 K uncompress record size becuase
the default 4 K record is not very good at compression ratio.
For using 16 K record size I have something like 55% compression ratio.
And it takes CSpotRun 2 sec to decode 2 records, 
so I think I'm getting 16 K/sec on a PalmV.

> (Actually what needs to be done it to hand optimize the inner loops
> within ZLib - doing so with my Palm DOC compressor provided a 5-6x
> gain).
> 

Can I have you code for testing? I'm very interested.

Thanks.

Dong

-- 
For information on using the Palm Developer Forums, or to unsubscribe, please see 
http://www.palm.com/devzone/mailinglists.html

Reply via email to