> Note also that users who might still have such ancient hardware (or want > to plot to a terminal device) might find they are able to plot to it using > the "gnuplot" command, which has output drivers for it. (Gnuplot is not yet > integrated, but this is expected as it was approved as part of PSARC 2009/395. > If the PSARC members feel the rest of this case warrants sufficient risk > to justify it, this project team is willing to accept delivery > of PSARC 2009/395 as a pre-requisite, although we don't particularly > feel that it should be so.)
GNU plotutils (_not_ gnuplot, something different, I gather) looks like a superset of all the old traditional plotting tools. Unfortunately, it also looks like even its libraries may be GPL and not LGPL, which may preclude it as a drop-in replacement, unless the commands linking to its libraries are also GPL. (at least given the common interpretation of these matters) [...] > Proposal > -------- > > 1) We propose to entirely remove all of the plotting > commands from > /usr/ucb. This consists of > > /usr/ucb/aedplot > /usr/ucb/atoplot > /usr/ucb/bgplot > /usr/ucb/crtplot > /usr/ucb/dumbplot > /usr/ucb/gigiplot > /usr/ucb/hp7221plot > /usr/ucb/hpplot > /usr/ucb/implot > /usr/ucb/plot > /usr/ucb/vplot > /usr/ucb/t300 > /usr/ucb/t300s > /usr/ucb/t4013 > /usr/ucb/t450 > /usr/ucb/tek > > We don't believe any applications will be impacted by > this removal. So tplot(1) and /usr/lib/t[0-9]* and /usr/lib/vplot won't be affected? What about sag(1)? [...] > 4) We propose to remove the "-g" option to > /usr/ucb/lpr, which was intended to > support the plot(4B) format. Again, real devices > which could benefit > from these filters are just not to be found in the > modern era. Lpr would > exit with an error number if this option is supplied. [...] Any of the lpr filter-type options imply (for a remote printer) something in lpd protocol. Even if the local system doesn't implement the corresponding content type (and it could, since postplot(1) implements plot(4b) format and lp -Tplot equates to lpr -g, as far as I can tell (non-CUPS)), the remote system might. So I don't see the value of removing any of the lpr(1b) options prior to getting rid of lpr altogether. -- This message posted from opensolaris.org
