Order Tray | Contact Us | Home | SIG Lists

[aprssig] Re: Symbol set revisions

Alex Carver kf4lvz at yahoo.com
Fri Apr 18 18:38:58 UTC 2008


> Message: 7
> Date: Thu, 17 Apr 2008 14:57:31 -0700
> From: "Stephen H. Smith" 
> Subject: [aprssig] Re: Symbol set revisions
> To: TAPR APRS Mailing List <aprssig at lists.tapr.org>
> Message-ID: <4807C7CB.5000002 at aol.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> Heikki Hannikainen wrote:
> >
> >  
> > - A single ZIP file containing both the specification
> file + the 
> > symbol images in a directory tree. The specification
> file has a fixed 
> > name, say, symbols.cfg (or whatever, as long as
> it's the same every 
> > time).
> >
> >   The specification file could be a CSV file, listing
> the symbol table 
> > and character, a length-limited short name for the
> symbol, a longer 
> > description for those symbols with a non-obvious short
> name, flags 
> > telling whether this image is overlayable and
> rotatable, and the name 
> > of the symbol image file. Something like this:
> >
> >
> > Most applications don't use hundreds of individual
> images.   APRSplus, 
> UIview, UIpoint and findu all use GRIDS of multiple symbol
> images in two 
> two graphics files.  X,Y addressing is use to clip out the
> desired 
> symbol for display from the grid.  
> 
>     * APRSplus uses 2 linear arrays of ninety-six 16x16
> pixel cells in
>       Windows BMP format that have no borders between them;
> ie the
>       right-most column of pixels for one symbol is
> immediately followed
>       by the left-most column of symbols for the next
> symbol.
> 
>     * UIview uses 2 two-dimensional arrays of ninety-six
> cells in a 6 x
>       16 grid in Windows BMP format, with a one-pixel black
> border
>       separating the top, bottom and sides of each symbol
> from it's
>       neighbors.
> 
>     * UIview's UIpoint plugin uses the same array but
> with a different
>       file name.
> 
>     * Findu also uses two 6 x 16 grids of 16x16-pixel
> symbols but
>       rotated 90 degrees and stored in .PNG format, with NO
> borders
>       between symbols.  
> 
> 
> 
> The UIview grid format (converted from .BMP to .GIF format
> for web 
> display) is shown on the APRS symbols page of my website
> at:
> 
>     <http://wa8lmf.net/aprs/APRS_symbols.htm>
> 
> Storing individual images is horribly inefficient use of
> disk space 
> since each 16x16 pixel 256-color image that natively
> occupies less than 
> one-half K (16x16 pixels  x 1 byte-per-pixel + some
> overhead for the 
> indexed pallette) winds up occupying the minimum allocation
> unit of the 
> hard disk , typically  4K  to 32 K per character.  

Trivial problem given current levels of storage.  If you're worried about it, NTFS has a minimum cluster size of 512 bytes that you can choose at formatting time.  Also, current NTFS has the ability to use the file's own entry in the MFT to store the data without wasting space.  Having the icons as separate files means editing any single one is far easier than editing a grid of them.  You can't mess up and wipe out a few of them at once with a misguided stroke of a mouse or graphics tablet.  Image Magick and Graphics Magick can both slice, dice, chop, flop, tile, merge, and do the dishes with relative ease.  A simple shell script could fly through that config file, locate all the appropriate independent images and then process them through IM or GM to give you a tiled output.

Locking into a format due to legacy isn't the best thing.  That's what's gotten us into this mess.  It's better to choose an extensible format that is easy for humans to maintain (since humans have to draw the pictures) and let machines translate that into whatever format is needed.  Those applications using single file tiled images can have their files with a tiny bit of one-time scripting with an image processing utility like Image Magick or Graphics Magick.  We shouldn't use those applications as starting points.  They are end users.  The starting point should be something that makes sense.  Individual files makes sense.  I can edit any single file without harming the others.  From those single files, any other format can be regenerated with ease.




      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ




More information about the aprssig mailing list