Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!asuvax!noao!ncar!gatech!purdue!haven!ncifcrf!lhc!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.compression
Subject: Re: gif encoding questions
Message-ID: <15810@smoke.brl.mil>
Date: 12 Apr 91 20:57:24 GMT
References: <1991Apr9.142255.186@unhd.unh.edu> <1991Apr10.034324.28971@netcom.COM>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 12

In article <1991Apr10.034324.28971@netcom.COM> marcos@netcom.COM (Marcos H. Woehrmann) writes:
-The document I have points out that most (all?) gif readers will break
-unless you only issue a clear code when the table is full, ...

The BRL-CAD "gif-fb" utility implements the GIF87a spec exactly.

-The GIF spec suggests that you sort the Global Color Table (aka palette)
-by order of importance (which most people of interpreted to mean in order
-of frequency).  "This assists a decoder, with fewer available colors, in
-choosing the best subset of colors..."

Yeah, the GIF specs are pretty terrible.