Alan W. Irwin writes:
> Hi Maurice,
>
> I still haven't seen your original post to plplot-general,
Yeah, I need to figure out why my post was blocked:
X-Spam-Report: Spam Filtering performed by sourceforge.net.
See http://spamassassin.org/tag/ for more details.
Report problems to
http://sf.net/tracker/?func=add&group_id=1&atid=200001
1.0 FORGED_RCVD_HELO Received: contains a forged HELO
I can post to plplot-devel just fine, so there must be some subtle difference
in the mailing list settings. Will look into it.
> but from the
> quoted version of it it appears you confirm the -a option problem as a
> long-term one for plmeta/plrender.
Right. Probably not too hard to fix, but as mentioned it's difficult to find
motivation / time since I don't really use it any more.
> On top of that long-known issue, I also
> found the additional serious plmeta/plrender problem with fonts this
> morning.
Yup.
> 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).
Note one can gradually add higher level capabilities to the existing metafile
and renderer. That was my long term plan to keep it current, starting with
strings approach (I still have that code around). A bite-sized approach to
improving it may fit better with available time for development than a rewrite
from scratch.
One big problem is that plplot was designed since day 1 centered around a
physical description of the output device. So abstracting out the higher
level view while retaining the ability to exactly reproduce the physical
device plot has always been a challenge. Unfortunately a long time has
elapsed since I studied these issues in detail, so my memory is fuzzy on the
issues involved (although I do remember it made my head hurt :).
> (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.
I can see marking them as unmaintained and not building either by default, as
long as there's an easy way to include them in the build again. Removal seems
a drastic step for now. Priorities change, and who knows what will be
important again in a few years.
--
Maurice LeBrun
-------------------------------------------------------------------------
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
