Hi Maurice, I still haven't seen your original post to plplot-general, but from the quoted version of it it appears you confirm the -a option problem as a long-term one for plmeta/plrender. On top of that long-known issue, I also found the additional serious plmeta/plrender problem with fonts this morning.
>From this evidence it appears plmeta/plrender is not keeping up, and the question I want to discuss is what should we do about that. The options I see are as follows: (1) Fix the issues with the current low-level version of -dev plmeta/plrender. However, nobody has stepped forward to do this, and the track record appears to be poor for keeping this combination maintained. (2) Issue some sort of warning message with -dev plmeta that some options (such as -a and decent fonts) are closed off forever by using this device. (3) write a high-level replacement of plmeta/plrender that doesn't require so much maintenance. The idea would be to store all the plplot commands and their arguments in a plmeta file and have plrender read back this file and run the given commands with the exact given arguments. If I recall correctly, the current plmeta does not save exact arguments so that, e.g., plrender using -dev plmeta does not give the same output as the input. When this issue was discussed years ago, I think the reason given was something to do with size of result/bandwidth. So if we move to saving exact arguments (e.g., 64-bit floating-point arrays if that is the input) there may be a bandwidth issue. OTOH, bandwidth issues are not quite as important as they used to be. Furthermore, plmeta has had a long and honorable history, and it certainly does have some appeal to store your results now as a plmeta file and have access to all PLplot improvements (e.g. better fonts) from then on. So taking this high-level approach might be worthwhile (assuming we can find a volunteer to programme it). (4) Give up on this whole approach by officially deprecating plmeta/plrender now with the view of removing it later (say just after the forthcoming stable release). I was quite dismayed this morning to "discover" the "-a" issue with plmeta, but obviously it doesn't affect that many users since apparently this limitation has been with us from the first with very few complaints about it. However, I believe the lack of access to modern fonts is a much more serious issue since it leaves such a bad impression of PLplot capabilities. Thus, regardless of the decision about which of the above options we decide to take, we should change the default option for plmeta to off so that users would have to specifically enable it. Maurice, do you agree with at least this step? It could be seen as the start to (4) or else as a temporary measure until one of the other options is taken. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Plplot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/plplot-devel
