From: Ethan M. <merritt@u.washington.edu> - 2005-07-13 16:01:20
|
Petr Mikulik wrote: > Candidates for being always in gnuplot are: > #define EAM_DATASTRINGS 1 > #define EAM_HISTOGRAMS 1 > #define GP_MACROS 1 > #define GP_STRING_VARS 2 > #define GP_FIT_ERRVARS 1 > #define PM3D 1 On Wednesday 13 July 2005 08:17 am, Hans-Bernhard Broeker wrote: > > I still haven't fully given up revitalizing the 16-bit > builds yet (I've got DOS16 to link with OW, a third-party linker and > some serious modifications...). These 10 percent of extra load could > easily kill those. I think that effort would be a total and utter waste of your time. Anyone runinng 16-bit DOS can just live with version 3.7 Surely the effort is better spent supporting current operating environments than it is retro-fitting to obsolete ones. I have not looked at GP_FIT_ERRVARS in detail, and don't have an opinion on it. The rest of them should go in IMHO. In particular PM3D is now so integral to many new features that I think it would make no sense for anyone to upgrade past version 4.0 and *not* include PM3D. Why go out of our way to support a combination of options that doesn't make any sense? So yes, I think the PM3D code should be made unconditional. If you like, I can resurrect the earlier patch pulling the PostScript prolog and character-encoding text blocks out of the driver and make them separately loadable files. That should gain about half of the PM3D size back right there, and it has other benefits unrelated to 16-bit support. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |