+3.4k (98/03/18)
+
+ ENHANCEMENTS:
+ - A new program called cxpm is provided to check on XPM files and help
+ figuring out where the file might be invalid.
+ - The FAQ and README are now in HTML.
+
+ BUGS CORRECTED:
+ - A bug in writing pixmaps out on an 32 bit depth visual and MSBFirst
+ machine.
+ - patch from Uwe Langenkamp <Uwe.Langenkamp@t-online.de>
+ - A severe bug in parsing the pixels section when an unknown character
+ is encountered.
+
+3.4j (96/12/31)
+
+ ENHANCEMENTS:
+ - The XPM library can now be built under Amiga DOS. This entirely comes
+ from: Lorens Younes <d93-hyo@nada.kth.se>
+ See the README.AMIGA file for details.
+ - Changes for MSW: big performance improvement in ParseAndPutPixels(),
+ fixed creation of the mask in SetColor()
+ - patch from Jan Wielemaker <jan@swi.psy.uva.nl>
+ - makefiles are provided for VMS
+ - given by Martin P.J. Zinser m.zinser@gsi.de
+ - Imakefiles reworked to get smoother builds and fixes from:
+ - Paul DuBois dubois@primate.wisc.edu
+ - Larry Schwimmer schwim@cyclone.stanford.edu
+ - thanks to some code rearrangement the library is smaller (the size
+ reduction goes from 4 to 7% depending on the system)
+
+ BUGS CORRECTED:
+ - A severe bug (introduced in 3.4i as part of the sprintf
+ optimization) in code writing XPM extensions to a buffer
+ XpmCreateBufferFromImage/Pixmap.
+ - The XpmAttributes definition in xpm.h was declaring nalloc_colors to
+ be Bool, it's an int.
+
+3.4i (96/09/13)
+
+ NEW FEATURES:
+ - The XPM library now allows the application to pass its own color
+ allocation/free functions. For this matter the following was done:
+ The XpmAttributes structure has three new fields alloc_color,
+ free_color, and color_closure. The following new valuemasks were
+ added XpmAllocColorFunc, XpmFreeColorsFunc, XpmColorClosure. And
+ two new types were defined XpmAllocColorFunc and XpmFreeColorsFunc.
+ See documentation for details.
+
+ ENHANCEMENTS:
+ - Windows NT support. It should compile and run fine based on the X
+ Consortium X11R6 distribution.
+ - The README file contains information to compile on Solaris with gcc.
+ - Part of the code has been optimized by using the value returned by
+ sprintf instead of calling strlen. Add the flag -DVOID_SPRINTF
+ if on your system sprintf returns void.
+ - patch from Thomas Ott thommy@rz.fh-augsburg.de
+
+ BUGS CORRECTED:
+ - XpmFree is now a real function (simply calling free by default).
+
+ CHANGES TO THE DOC:
+ - The documentation describes the new XpmAttributes fields and their
+ use.
+
+3.4h (96/02/01)
+
+ NEW FEATURES:
+ - The XpmAttributes has a new member called 'alloc_close_colors' which
+ lets the caller specify whether close colors should be allocated
+ using XAllocColor or not. This is especially useful when one uses a
+ private colormap full of read/write cells.
+ The xpm.h header file define a new bitmap flag called
+ XpmAllocCloseColors to use along with this new slot.
+ - Dale Pease peased@bigbird.cso.gtegsc.com
+ - The XpmAttributes has a new member called 'bitmap_format' which lets
+ the caller specify the format of 1 bit depth images (XYBitmap or
+ ZPixmap). The xpm.h header file define a new bitmap flag called
+ XpmBitmapFormat to use along with this new field.
+
+ ENHANCEMENTS:
+ - XpmReadFileTo[Image/Pixmap], XpmCreate[Image/Pixmap]FromData,
+ XpmCreateImageFromDataFromBuffer functions do no longer use a
+ temporary XpmImage object, which reduces a lot the amount of memory
+ used. On the other hand it can take a little more time, but given the
+ following figures (based on sxpm) it is a real good trade-off.
+
+ Reading a 22x22 pixmap with 5 colors no time change is detected
+ using time:
+ real 0.3
+ user 0.1
+ sys 0.1
+
+ Reading a 1279x1023 pixmap with 14 colors (quite extreme case for
+ XPM!) the time goes from:
+ real 1.9
+ user 0.8
+ sys 0.8
+
+ to:
+ real 2.2
+ user 1.8
+ sys 0.3
+
+ Reading the 22x22 pixmap with 5 colors the memory usage (under
+ purify) goes from:
+ 255256 code
+ 55496 data/bss
+ 163848 heap (peak use)
+ 4248 stack
+ to:
+ 271240 code
+ 55472 data/bss
+ 159752 heap (peak use)
+ 4224 stack
+
+ And reading the 1279x1023 pixmap with 14 colors it goes from:
+ 255256 code
+ 55496 data/bss
+ 6705160 heap (peak use)
+ 4280 stack
+ to:
+ 271240 code
+ 55472 data/bss
+ 1732616 heap (peak use)
+ 4264 stack
+
+ This clearly shows that while for small pixmaps there is no real
+ difference on both sides, for large pixmaps this makes a huge
+ difference about the amount of memory used and it is not much
+ slower.
+
+ Note that you can still get the old behavior using both
+ XpmReadFileToXpmImage and XpmCreate[Image/Pixmap]FromXpmImage instead
+ of XpmReadFileTo[Image/Pixmap]. Once more XPM gives you the choice!
+
+ BUGS CORRECTED:
+ - when defined locally the global symbols strcasecmp and strdup are
+ now called xpmstrcasecmp and xpmstrdup to avoid any possible
+ conflict.
+ - VMS has a bogus file system which requires a work around in
+ XpmReadFileToBuffer.
+ - patch from Bob.Deen@jpl.nasa.gov
+ - the type of the exactColors attribute has been changed from unsigned
+ int to Bool.
+
+ CHANGES TO THE DOC:
+ - the documentation describes the new XpmAttributes fields
+ alloc_close_colors and bitmap_format.
+
+3.4g (95/10/08)
+
+ ENHANCEMENTS:
+ - The XpmAttributes structure has now two new slots: alloc_pixels and
+ nalloc_pixels in order to provide an easy way to free allocated
+ colors. The new bitmask XpmReturnAllocPixels should be used to
+ request this data through the valuemask. Unless you really know why,
+ you should use this instead of XpmReturnPixels, pixels, and npixels.
+ - the XPM1 format parsing has been improved.
+ - patch from Chuck Thompson <cthomp@cs.uiuc.edu>
+ - compilers defining _STDC_ to something different from 1 are now
+ considered as ANSI compilers.
+ - the README file provides now more info on how to build XPM depending
+ on the system.
+
+ BUGS CORRECTED:
+ - a bug introduced in 3.4f in the XPM1 format parsing function.
+ - fix from Chuck Thompson <cthomp@cs.uiuc.edu>
+ - the hashtable was not free when the color parsing failed.
+ - patch from ackley@cs.unm.edu (David Ackley)
+ - the close color mechanism wasn't used if one of the closeness
+ parameter was null. Now only one needs to be different from 0.
+ Lorens Younes d93-hyo@nada.kth.se
+ - parsing of long comments failed with a segmentation fault.
+
+ CHANGES TO THE DOC:
+ - the documentation describes the new XpmAttributes fields
+ alloc_pixels and nalloc_pixels and how they are used.
+
+3.4f (95/05/29)
+
+ ENHANCEMENTS:
+ - Defines IMAKE_DEFINES in the top Imakefile so one can easily avoid
+ building the shared library.
+ - Add some information about the installation process in the README.
+ - filenames are surrounded with quotes when calling gzip or compress in
+ order to allow spaces within filenames.
+ - William Parn <parn@fgm.com>
+ - the compilation and the shared library building should be smoother
+ on Alpha OSF/1.
+ - patch from Dale Moore <Dale.Moore@CS.cmu.edu>
+
+ BUGS CORRECTED:
+ - a segmentation fault occurring in some weird case.
+
+3.4e (95/03/01)
+
+ ENHANCEMENTS:
+ - The top Imakefile passes CDEBUGFLAGS and DEFINES to subdirs. Thus
+ only this Imakefile should need to be edited by users.
+ - FAQ includes the answer to the question "How can I get a non
+ rectangular icon using XPM ?"
+ - VMS support updated
+ - patch from Martin P.J. Zinser m.zinser@gsi.de
+
+ BUGS CORRECTED:
+ - XpmCreateImageFromXpmImage() called from XpmReadFileToPixmap() could
+ lead to a segmentation fault since free was called on a memory block
+ size variable instead of the block itself. Note: this bug has been
+ introduced in 3.4d.
+
+3.4d (95/01/31)
+
+ ENHANCEMENTS:
+ - sxpm now supports a -version option command.
+
+ BUGS CORRECTED:
+ - the list of pixels returned in XpmAttributes was wrong when two
+ colors were defined as None in the read XPM
+ - Lionel.Mallet@sophia.inria.fr
+ - the parser was skipping whitespace reading extensions strings. This
+ has been fixed so extensions lines are now returned exactly as they
+ are.
+ - some compilation control added for the dec alpha with X11R5 (LONG64)
+ - patch from Fredrik Lundh <Fredrik_Lundh@ivab.se>
+ - when writing an XPM file, '-' characters are replaced with '_'
+ characters in the array name, in order to get a valid C syntax name.
+ - XYPixmap format images were not correctly handled.
+ - XPM1 file with names using multiple '_' characters are now handled
+ correctly.
+ - todd@erda.rl.af.mil (Todd Gleason)
+
+3.4c (94/06/06)
+
+ Yes, this is kind of quick. But this is because no code has been modified,
+ this is just a new packaging to make the whole stuff more suitable to the
+ X development team's requests for inclusion in the R6 contrib.
+
+ ENHANCEMENTS:
+ - Several filenames were too long to fit without any conflict on DOS
+ and CD-ROM filesystems. They have been renamed.
+ - Imakefiles use XCOMM for comments instead of the # character.
+ - the Postscript documentation file doc/xpm.ps is now distributed as
+ doc/xpm.PS.gz and allows browsing with tools such as ghostview.
+ - Besides, parts of lib/misc.c have been moved to several new files,
+ and some functions of data.c have been moved to other files in
+ order to get a better link profile.
+ - I've also added a FAQ hoping this will prevent people from
+ continuously filling my mailbox with the same questions.
+ - sxpm.c includes <X11/xpm.h> instead of "xpm.h" and BUILDINCTOP is
+ used in Makefiles as expected.
+ - Everything can be done simply using "xmkmf -a" and "make".
+
projects / wxWidgets.git / blobdiff