akcs.falco@hpcvbbs.UUCP (Andrey Dolgachev) (05/01/91)
There have recently been some very large GROB's posted on c.s.h. I think
that it is a good idea to not post them in normal form, since getting rid
of and inserting carriage-returns can be a real pain, but how about
posting them in compressed form? By compressed, I mean compressed by the
use of Erik Bryntse's routines PGROB and UPGROB. We already have two
standards for posting of non-standard programs: ASC and UUENCODE, so how
about one for graphics?
First of all, here are the advantages of using PGROB and UPGROB over ASC
or UUENCODE. One, the GROB is compressed, resulting in smaller space on
the calculator and most importantly, far less space in the text form.
Second, both PGROB and UPGROB are extremely small, smaller than ASC.
copy
The problems that I can asee is that do we want postings for "what is
UPGROB and how do I get it?"
Well, what do you all think, should we all start using compressed GROB's
or not?
---Falcoahernsd@mentor.cc.purdue.edu (Dynastar) (05/01/91)
In <281df89f:2981comp.sys.handhelds@hpcvbbs.UUCP> akcs.falco@hpcvbbs.UUCP (Andrey Dolgachev) writes: >Well, what do you all think, should we all start using compressed GROB's >or not? Sounds like an excellent idea to me! The GROB compression routines are very small and will fit on any size 48, so it can be used by everyone. Next time I post a GROB, I will compress it first. (I can't believe I didn't think of that! stupid, I guess ;-)
herman@corpane.uucp (Harry Herman) (05/02/91)
In <281df89f:2981comp.sys.handhelds@hpcvbbs.UUCP> akcs.falco@hpcvbbs.UUCP (Andrey Dolgachev) writes: >First of all, here are the advantages of using PGROB and UPGROB over ASC >or UUENCODE. One, the GROB is compressed, resulting in smaller space on >the calculator and most importantly, far less space in the text form. >Second, both PGROB and UPGROB are extremely small, smaller than ASC. >copy >The problems that I can asee is that do we want postings for "what is >UPGROB and how do I get it?" > ---Falco Ok, I'll byte: What is UPGROB and how do I get it? Harry Herman herman@corpane
elliott@veronica.cs.wisc.edu (James Elliott) (05/02/91)
In <11683@mentor.cc.purdue.edu> ahernsd@mentor.cc.purdue.edu (Dynastar) writes: >In <281df89f:2981comp.sys.handhelds@hpcvbbs.UUCP> akcs.falco@hpcvbbs.UUCP (Andrey Dolgachev) writes: >>Well, what do you all think, should we all start using compressed GROB's >>or not? The original version of Sun Clock used a compressed GROB. I intentionally changed it to not use a compressed GROB, because the savings over the uncompressed size were negligible once the size of UPGROB was taken into account (the world map really didn't compress very well), and because this meant that there were suddenly two components of Sun Clock that could not survive ASCII downloading: The compressed GROB and UPGROB itself. This was unacceptable, because I wanted to be able to provide inline documentation for the code. Those who wanted to avoid the linefeed issue were, of course, free to download the uuencoded binary instead. By the way, there is a minor bug in the posted version of Sun Clock: If the ticking clock display is active when "Help" or "About" is chosen, the clock garbles the displays at the intermediate pause points. I've fixed this, but haven't yet felt like consuming net bandwidth to post it. I'd like to get the corrected version to the archives, though; is there somewhere I could mail it do directly? -Jim -- Jim Elliott "Like a bridge he'll come between us, not a wall" elliott@veronica.cs.wisc.edu
akcs.falco@hpcvbbs.UUCP (Andrey Dolgachev) (05/03/91)
Hmm, posting GROB's in compressed format has a problem. I didn't realize
that the compressed grob is not simply a binary number, but an object
type which can not be transferred via ASCII. Which means that the code
would have to be put ASC'd. This means that a GROB would first have to
have to be compressed with the use of Erik Bryntse's PGROB routine, then
->ASC would have to be used. However, the result would still be
substantially smaller for some GROB's and would still be worth it.
---Falcoerikmb@etek.chalmers.se (Erik Bryntse) (05/05/91)
Andrey Dolgachev writes: >There have recently been some very large GROB's posted on c.s.h. I think >that it is a good idea to not post them in normal form, since getting rid >of and inserting carriage-returns can be a real pain, but how about >posting them in compressed form? By compressed, I mean compressed by the >use of Erik Bryntse's routines PGROB and UPGROB. We already have two >standards for posting of non-standard programs: ASC and UUENCODE, so how >about one for graphics? >First of all, here are the advantages of using PGROB and UPGROB over ASC >or UUENCODE. One, the GROB is compressed, resulting in smaller space on >the calculator and most importantly, far less space in the text form. >Second, both PGROB and UPGROB are extremely small, smaller than ASC. The problem with PGROB is that the result is a integer with a length <> 16 nibbles. This means that it must be transmitted in binary form to the 48 (and also that you cannot type it in). So you would still need ASC or UUENCODE to post the packed GROB in its binary form! This reduces the advantages of using PGROB in postings to one, that it takes up less space in the posting. But the space you save by doing this would quickly be filled by "where do I get UPGROB?" postings! Therefore I beleive it is best to use the ASC (or UUENCODE) routines and post the GROB in its uncompressed form. When you have downloaded the GROB to your calculator, you can compress it using PGROB to save space. Or you can post your pictures (in ASC or UUENCODE) with UPGROB included, preferrably in a simple "uncompress and show" program. This way you would save space without getting more "where can I get" questions. >Well, what do you all think, should we all start using compressed GROB's >or not? Sure, use compressed GROBs in your calculator, and in postings of games with fancy graphics or in postings of pictures, IF YOU INCLUDE UPGROB. Otherwise I think it's best to use only ASC or UUENCODE. > ---Falco Erik Bryntse