Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!sdd.hp.com!hp-pcd!hpcvia!scottb
From: scottb@hpcvia.CV.HP.COM (Scott_Burke)
Newsgroups: comp.sys.handhelds
Subject: Re: hp48 application problem: a challenge
Message-ID: <31210050@hpcvia.CV.HP.COM>
Date: 21 Aug 90 19:14:52 GMT
References: <2857@gmu90x.gmu.edu>
Organization: Hewlett-Packard Co., Corvallis, Oregon
Lines: 20

Another idea...

There are two methods of cropping:  by byte, or by pixel.  The former
is easier, but won't save as much space all the time.  The latter method
means code must be written to expand a grob from the 4 pixels/byte
storage scheme back out to pixel data, so that a finer cropping can be
achieved.  Then, after cropping, the pixel data would be re-encoded to
the standard scheme, and an upper-left corner would be stored along with
the sub-grob.

I'm not sure what the purpose of the described scheme is--is it part of
an archival system?--but if it's for use in an interactive application,
the decompress times are unpalatable.  The most compression that can be
achieved for an interactive program is simply to have a PC program to
crop the grob as finely as possible, and then store the grobs that way.

Scott.


scottb @ hpcvia.cv.hp.com