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