[metapost] problem with drawoptions and fake Euro symbol

Reinhard Kotucha reinhard.kotucha at web.de
Sat Nov 17 01:21:08 CET 2007


Mojca Miklavec writes:
 > On 11/15/07, Reinhard Kotucha wrote:

 >> What I'd like to see changed is that options can be specified in an
 >> arbitrary order.  Or is there a good reason for this inconvenience?
 
 > Which options in particular?

I must admit that I use gnuplot very rarely directly.  What I remember
is that gnuplot's plot command is very fussy regarding the order of
its arguments.  In most cases I use gnuplot as a backend for GNU
Octave.  Octave has its own plot function which calls gnuplot.

 >> There are many relicts which should better be removed.  At least from
 >> the manual.  There is no TeX distribution today which doesn't at least
 >> support PostScript.  I'm sure that during the last ten years *nobody*
 >> used the Metafont driver.  It should better be removed, at least from
 >> the manual.
 
 > Removing the terminal might be tricky (you never know who uses it),
 > but removing it from the manual would indeed be sensible. There was
 > some discussion about applying "obsolete" flags to terminals (but
 > never implemented so far). But compared to dozens of obsolete printers
 > and plotters still being available in gnuplot, metafont is not even
 > that bad and obsolete at all :)

The metafont driver is completely obsolete for more than a decade
now and you can be sure that nobody uses it any more.  Even 20 years
ago, when you had to convert graphics to .pk fonts in order to embed
them into TeX documents, this was more a workaround rather than a
solution.

Regarding printers: In my opinion it is wrong to concern about
printers at all.  It's sufficient if gnuplot can produce PostScript.
Everything else can be done by Ghostscript.  It makes more sense for
people who have enough time to write or maintain printer drivers for
gnuplot to help to improve Ghostscript instead.  If gnuplot would pipe
PostScript code to Ghostscript, even more printers will be supported
and, of course, no work is duplicated.

Regarding terminals (I mean real hardware terminals which nobody has
today any more):  It's worthwhile to consider whether it's necessary
to support all of them, especially if they are unmaintained.

I don't know what all these stupid terminal drivers are good for.  One
of Gnuplot's strength (to support many output devices) is actually its
biggest weakness.  Each driver ("terminal" in Gnuplot parlance) has
some limitations.  Why are they needed at all?  The only reasonable
output formats are PostScript or PDF.  Though PostScript is a bit
easier to use, PDF supports transparency.  Both formats are understood
by Ghostscript.  Why are there different drivers for printing and for
screen preview?  People expect that what they see on  screen is what
is sent to a printer.  Ghostscript already supports all this.

There are other things which can be improved:

Some time ago I created a file with logarithmic scaling.  The labels
at the y-axis had been:

  0.1
  0.01
  0.001
  0.0001
  0.00001
  0.000001

Maybe the metapost driver could create

  0.1
  0.01
  0.001
  $10^{-4}$
  $10^{-5}$
  $10^{-6}$

instead.  Maybe such functionality had been added meanwhile.  Don't know.

Another point is that gnuplot supports shell escapes.  This allows
people to pre-process data files.  The manual provides an example how
to use awk(1) for filtering data files.  But shell escapes are
platform dependent by nature.  A much more portable and
straightforward solution would be to compile a Lua engine into
gnuplot.  This is probably not much work if the ONLY purpose is to
filter data files.

There is only a reference manual (function and variables listed in
alphabetical order).  A tutorial would be more helpful.  I don't
think that anything has to be written from scratch.  It's probably
sufficient to re-organize things.  If you don't know what I'm talking
about, compare the Gnuplot manual with the Octave manual.  And if you
need a command reference, it's sufficient to provide an index.

I'm wondering about the file /usr/share/gnuplot/gih/gnuplot.gih.
Gnuplot is very old and at the beginning there had not been any other
programs it could use.  But today, a more reasonable way to provide
documentation is to use texinfo.  The only advantage of the .gih
format obviously is that it can be parsed easily.  But it's definitely
not more difficult to parse an info file.

Sorry if it sounds too harsh, but I'm sure Gnuplot has no future.
Currently TikZ/pgf still uses Gnuplot but what will happen when we
have LuaTeX?

Gnuplot only has a chance to survive if developers recognize that we
are not living in the mid seventies anymore.  Sorry for being so
impolite, but that's the truth.

Regards,
  Reinhard

-- 
----------------------------------------------------------------------------
Reinhard Kotucha			              Phone: +49-511-4592165
Marschnerstr. 25
D-30167 Hannover	                      mailto:reinhard.kotucha at web.de
----------------------------------------------------------------------------
Microsoft isn't the answer. Microsoft is the question, and the answer is NO.
----------------------------------------------------------------------------


More information about the metapost mailing list