gnuplot-beta

grouping available terminals together

[Mojca M. <moj...@gm...>]

Hello,

I don't know how difficult it would be to add, but I would find it
very useful if terminals would be groupped when one says "set term" to
display the list of available terminals.

Example: four years ago, when I started to use gnuplot, I saw "latex"
and used that one. I used only a black-and-white printer and I had no
need for 3D plots, so it was OK to use it (I wasn't fully satisfied
with), but later at some point I figured out that I miss (better?)
suport for color, but I had no idea which terminal to choose.

There are in fact quite a lot of latex-based drivers: texdraw,
pstricks, eepic, tpic, [e]ps[la]tex, emtex (obsolete?), and perhaps
one could count mf and mp to the same category as well. (I wanted to
use TeX with equations and same font as in the document, but at that
time I didn't know that metapost ia a TeX's friend.) Altough
[e]ps[la]tex seems to be the only advanced driver nowadays, I didn't
notice its existance until I started to write a new terminal by
myself.

There are plenty of drivers whose name and description don't tell me
anything about it.

If a user is looking for a driver which would be suitable for a
publication, it probably makes no sense to offer him dozens of (mostly
obsolete?) printer drivers and interactive devices.

And for a linux or mac user, it would be helpul if [aqua,] x11 and wxt
(any other?) would be listed together as a hint that one can use wxt
as a replacement for x11 (if that one wouldn't be the default).

I would propose to change the behaviour of "set term" in such a way,
that something like the following list would be displayed:

Printer devices:
     epson_180dpi  Epson LQ-style 180-dot per inch (24 pin) printers
      epson_60dpi  Epson-style 60-dot per inch printers
      epson_lx800  Epson LX-800, Star NL-10, NX-1000, PROPRINTER ...
          hp2623A  HP2623A and maybe others
           hp2648  HP2648 and HP2647
           hp500c  HP DeskJet 500c, [75 100 150 300] [rle tiff]
             hpdj  HP DeskJet 500, [75 100 150 300]
             hpgl  HP7475 and relatives [number of pens] [eject]
           hpljii  HP Laserjet series II, [75 100 150 300]
             hppj  HP PaintJet and HP3630 [FNT5X9 FNT9X17 FNT13X25]
...

For specific programs:
             aifm  Adobe Illustrator 3.0 Format
              fig  FIG graphics language for XFIG graphics editor
...

TeX-friendly:
        emtex  LaTeX picture environment with emTeX specials
        latex  LaTeX picture environment
     epslatex  LaTeX picture environment using graphicx package
      pslatex  LaTeX picture environment with PostScript \specials
        pstex  plain TeX with PostScript \specials
        eepic  EEPIC -- extended LaTeX picture environment
         tpic  TPIC -- LaTeX picture environment with tpic \specials
     pstricks  LaTeX picture environment with PSTricks macros
      texdraw  LaTeX texdraw environment
           mf  Metafont plotting standard
           mp  MetaPost plotting standard
...

Vector graphics:
          pdf  PDF (Portable Document File) file driver
   postscript  PostScript graphics, including EPSF embedded files (*.eps)
          svg  W3C Scalable Vector Graphics driver
             aifm  Adobe Illustrator 3.0 Format
...

Bitmap graphics
             jpeg  JPEG images using libgd and TrueType fonts
          png  PNG images using libgd and TrueType fonts
...

Interactive:
             aqua  Interface to graphics terminal server for Mac OS X
              x11  X11 Window System
              wxt
...

Also, it might be helpful to add a little mark next next to terminals
to display their state. Some of them are actively maintained, some
will not be maintained any more, but might be still useful for some
users (probably tpic, eepic, and most printer devices), some cannot be
extended to support 3d palettes, but are simply "fun" (dumb  ascii art
for anything that prints text), some need improvements, but a
maintainer first (windows?), some are almost obsolete because there's
a better alternative (I consider at least metafont and emtex to be one
of them).

I've chosen just a few terminals in a pseudo-random way. I don't have
a clear overview, but consider the list above to be just an example
that I would consider very friendly to new users.

Mojca

Re: grouping available terminals together

[Ethan M. <merritt@u.washington.edu>]

On Thursday 08 February 2007 15:18, Mojca Miklavec wrote:

> There are in fact quite a lot of latex-based drivers: texdraw,
> pstricks, eepic, tpic, [e]ps[la]tex, emtex (obsolete?), and perhaps
> one could count mf and mp to the same category as well. (I wanted to
> use TeX with equations and same font as in the document, but at that
> time I didn't know that metapost ia a TeX's friend.) Altough
> [e]ps[la]tex seems to be the only advanced driver nowadays, I didn't
> notice its existance until I started to write a new terminal by
> myself.

Why stop with those?  I use LaTeX, but I don't use any of the above.
Instead I use either post, png or pdf to produce figures for my LaTeX
documents.  The category "can be used with TeX" is rather large.

> There are plenty of drivers whose name and description don't tell me
> anything about it.

Such as?  The only one I see on the "set term" list that comes with 
zero explanation is "Selanar".  But if you have a Selanar terminal then
you already know what it is, and if you don't have one then the driver
is useless to you anyhow.  Would it help any to say
  selanar  DEC vt100-series ascii terminal clone with add-in graphics
           capability, not sighted in the wild since 1992
  regis    DEC vt100-series graphics language (vt125, vt240, ...)


I do have some sympathy for re-organizing the list based on degree of
obsolescence:

Current generation interactive terminals
	wxt x11 aquaterm pm

Legacy interactive terminals
	aed *tek* regis selanar win

Current generation printer drivers
	NONE (use PostScript or wrap output in a document format)

Legacy printer drivers
	<all of them>

Legacy O/S-specific terminals (essentially obsolete; may not work)
	atari apollo be iris linux multitos next openstep sun vws

MSOffice-friendly
	cgm emf png/gif/jpeg

web-friendly
	png/gif/jpeg svg

 
> I would propose to change the behaviour of "set term" in such a way,
> that something like the following list would be displayed:


 
> For specific programs:
>              aifm  Adobe Illustrator 3.0 Format
>               fig  FIG graphics language for XFIG graphics editor

Here is another example of how this quickly gets complicated.
The recommended terminal for Adobe Illustrator is currently post.trm
The fig terminal is also used (I was told just recently) for
import into AutoCAD.


> Also, it might be helpful to add a little mark next next to terminals
> to display their state. Some of them are actively maintained, some
> will not be maintained any more, but might be still useful for some
> users (probably tpic, eepic, and most printer devices), some cannot be
> extended to support 3d palettes, 

> but are simply "fun" (dumb  ascii art for anything that prints text),

Hey! That's actually one of the more useful terminals.
It is maintained,and it even supports enhanced text mode.
I use it for including graphs in-line in Email, as an option for
web output, and for testing over remote low-bandwidth net connections.

> I've chosen just a few terminals in a pseudo-random way. I don't have
> a clear overview, but consider the list above to be just an example
> that I would consider very friendly to new users.

I have no objection.  The main hurdle is that the terminal list is
auto-generated by the build process, rather than being written out
explicitly in the doc files.  But the result from auto-generation
is not so great.  Its chief virtue is that it tells you what was
actually built into this copy of gnuplot.  Then again, people have
complained that it should also tell you what was *not* built in so
that you can go looking for a more full-featured build of gnuplot.

It would be a rather boring project, but I suppose someone could
invent a flag variable or grep-able tag in the terminal files that
listed the categories to which that terminal belongs. Then the 
auto-generation system could use the flag to arrange the terminal
listing into groups.  E.g.

iris4d.trm:
### grep-able comment for generating terminal documentation ### 
# TERM_CATAGORY  iris4d OS-SPECIFIC  OBSOLETE  VECTOR  INTERACTIVE


gd.trm:
# TERM_CATEGORY  png   WEB MSOFFICE BITMAP TEX 
# TERM_CATEGORY  jpeg  WEB MSOFFICE BITMAP 



-- 
Ethan A Merritt

Re: grouping available terminals together

[Mojca M. <moj...@gm...>]

On 2/9/07, Ethan Merritt <merritt@u.washington.edu> wrote:
> On Thursday 08 February 2007 15:18, Mojca Miklavec wrote:
>
> > There are in fact quite a lot of latex-based drivers: texdraw,
> > pstricks, eepic, tpic, [e]ps[la]tex, emtex (obsolete?), and perhaps
> > one could count mf and mp to the same category as well. (I wanted to
> > use TeX with equations and same font as in the document, but at that
> > time I didn't know that metapost ia a TeX's friend.) Altough
> > [e]ps[la]tex seems to be the only advanced driver nowadays, I didn't
> > notice its existance until I started to write a new terminal by
> > myself.
>
> Why stop with those?  I use LaTeX, but I don't use any of the above.
> Instead I use either post, png or pdf to produce figures for my LaTeX
> documents.  The category "can be used with TeX" is rather large.
>
> > There are plenty of drivers whose name and description don't tell me
> > anything about it.
>
> Such as?  The only one I see on the "set term" list that comes with
> zero explanation is "Selanar".

I don't mean "zero explanation", but rather "I've never heard about it".

If I take
            vttek  VT-like tek40xx terminal emulator
I don't have the slightest idea what it could be used for.

Sure, if I don't understand, I probably don't need to use it.

But 4 years agou I didn't know what metapost was (and that I could use
it as a replacement for latex terminal while still retaining the
possibility to typeset the labels with TeX)
And if I wasn't on the mailing list, I wouldn't have the slightest
idea to try wxt (I won't be able to use it until it's adapted for mac
or until I change OS anyway, but ...).

>  But if you have a Selanar terminal then
> you already know what it is, and if you don't have one then the driver
> is useless to you anyhow.  Would it help any to say
>   selanar  DEC vt100-series ascii terminal clone with add-in graphics
>            capability, not sighted in the wild since 1992
>   regis    DEC vt100-series graphics language (vt125, vt240, ...)

To me not, that's why grouping would help.

> I do have some sympathy for re-organizing the list based on degree of
> obsolescence:

That would be OK (perhaps even better).

> Current generation interactive terminals
>         wxt x11 aquaterm pm
>
> Legacy interactive terminals
>         aed *tek* regis selanar win
>
> Current generation printer drivers
>         NONE (use PostScript or wrap output in a document format)
>
> Legacy printer drivers
>         <all of them>
>
> Legacy O/S-specific terminals (essentially obsolete; may not work)
>         atari apollo be iris linux multitos next openstep sun vws
>
> MSOffice-friendly
>         cgm emf png/gif/jpeg
>
> web-friendly
>         png/gif/jpeg svg

I support that idea.

> > For specific programs:
> >              aifm  Adobe Illustrator 3.0 Format
> >               fig  FIG graphics language for XFIG graphics editor
>
> Here is another example of how this quickly gets complicated.
> The recommended terminal for Adobe Illustrator is currently post.trm
> The fig terminal is also used (I was told just recently) for
> import into AutoCAD.

As I said: I don't know any details ... it was just an example. It
would not always be 100% to which category a certain terminal belongs.
But there are so many (and so many obsolete) that such an organisation
would be of real help.

> > Also, it might be helpful to add a little mark next next to terminals
> > to display their state. Some of them are actively maintained, some
> > will not be maintained any more, but might be still useful for some
> > users (probably tpic, eepic, and most printer devices), some cannot be
> > extended to support 3d palettes,
>
> > but are simply "fun" (dumb  ascii art for anything that prints text),
>
> Hey! That's actually one of the more useful terminals.

I needed some time to discover its existance. I said "fun" mostly
because of a creative idea. If I was designing a new application, I
wouldn't have thought about creating a terminal like that, but it's
indeed useful sometimes. Most probably more useful than any of the
other obsolete LaTeX & printing devices terminals.

> It is maintained,and it even supports enhanced text mode.

I mostly meant: nobody is maintaining the bunch of LaTeX terminals
which could indeed be improved considerably. If one wants to use
LaTeX, one expects quality.
Support for transparency or gouraud shading cannot be added to "dumb",
but ascii still has its own charm.

> I use it for including graphs in-line in Email, as an option for
> web output, and for testing over remote low-bandwidth net connections.

> > I've chosen just a few terminals in a pseudo-random way. I don't have
> > a clear overview, but consider the list above to be just an example
> > that I would consider very friendly to new users.
>
> I have no objection.  The main hurdle is that the terminal list is
> auto-generated by the build process, rather than being written out
> explicitly in the doc files.  But the result from auto-generation
> is not so great.  Its chief virtue is that it tells you what was
> actually built into this copy of gnuplot.  Then again, people have
> complained that it should also tell you what was *not* built in so
> that you can go looking for a more full-featured build of gnuplot.

That's what I thought as well. I never knew that PDF output was
possible (and gd is also sometimes not included). Eevn if I forget
about the fact that PS terminal is better ... it would indeed help to
have some of those terminals listed.

> It would be a rather boring project, but I suppose someone could
> invent a flag variable or grep-able tag in the terminal files that
> listed the categories to which that terminal belongs. Then the
> auto-generation system could use the flag to arrange the terminal
> listing into groups.  E.g.
>
> iris4d.trm:
> ### grep-able comment for generating terminal documentation ###
> # TERM_CATAGORY  iris4d OS-SPECIFIC  OBSOLETE  VECTOR  INTERACTIVE
>
>
> gd.trm:
> # TERM_CATEGORY  png   WEB MSOFFICE BITMAP TEX
> # TERM_CATEGORY  jpeg  WEB MSOFFICE BITMAP

That would make sense.

Mojca

Re: grouping available terminals together

[Daniel J S. <dan...@ie...>]

Mojca Miklavec wrote:

> I mostly meant: nobody is maintaining the bunch of LaTeX terminals
> which could indeed be improved considerably. If one wants to use
> LaTeX, one expects quality.
> Support for transparency or gouraud shading cannot be added to "dumb",
> but ascii still has its own charm.

Part of the reason that LaTeX only terminal types aren't maintained well is probably because one can never achieve the quality from strictly TeX as can be achieved with combining PostScript and LaTeX.  So, pslatex is the place to go if you need to compile equations, maintain a similar font, and have good graphics quality in LaTeX document.  Or ConTeXt.

Dan

Re: grouping available terminals together

[Mojca M. <moj...@gm...>]

On 2/9/07, Daniel J Sebald wrote:
> Mojca Miklavec wrote:
>
> > I mostly meant: nobody is maintaining the bunch of LaTeX terminals
> > which could indeed be improved considerably. If one wants to use
> > LaTeX, one expects quality.
> > Support for transparency or gouraud shading cannot be added to "dumb",
> > but ascii still has its own charm.
>
> Part of the reason that LaTeX only terminal types aren't maintained well is probably because one can never achieve the quality from strictly TeX as can be achieved with combining PostScript and LaTeX.  So, pslatex is the place to go if you need to compile equations, maintain a similar font, and have good graphics quality in LaTeX document.  Or ConTeXt.

I know. (La)TeX doesn't (or at least didn't) have good (native)
support for graphics, not even for such a basic thing as color. So I
can understand why dozens of terminals, out of which all but LaTeX and
[e]ps[la]latex are obsolete.

I was thinking about looking into TikZ. It works with a wide variety
of engines (so it would work with dvips/pdfTeX and XeTeX) and with all
three formats (TeX/LaTeX/ConTeXt). But I first need to have the
ConTeXt terminal under the roof (hoping that it will make it into the
official gnuplot one day), and I don't use TikZ at all, so it would
take me some time to learn it. Metapost is a nice programming
language, but TeX is the worst programming language I've ever tried to
use. And there is no such person as "Hans H." in the LaTeX community
to ask for help.

On the other hand, luaTeX might bring nice surprizes. There are
roumors that metapost might be integrated as a library into luaTeX.
(For those who hear that name for the first time: pdfTeX development
will most probably stop at version 1.40.x where it is now - luaTeX
will be it's successor.) If the roumors are true, current code for
ConTeXt might be adapted for LaTeX as well.

Mojca

Re: grouping available terminals together

[Daniel J S. <dan...@ie...>]

Mojca Miklavec wrote:

> I was thinking about looking into TikZ. It works with a wide variety
> of engines (so it would work with dvips/pdfTeX and XeTeX) and with all
> three formats (TeX/LaTeX/ConTeXt). But I first need to have the
> ConTeXt terminal under the roof (hoping that it will make it into the
> official gnuplot one day), and I don't use TikZ at all, so it would
> take me some time to learn it. Metapost is a nice programming
> language, but TeX is the worst programming language I've ever tried to
> use.

TeX is an old language, coinciding with some of the beginnings of computer software--the days when memory was small and programming languages were nascent.  Hence the advent of LaTeX macros.  I believe D. Knuth decided to freeze the language much to the chagrin of those who would want to add some improvements.

Think of TeX like an assembly language, whereas LaTeX is a compiler.

MetaPost gives better graphics, but it seems a small step above actual PostScript because everything needs to be spelled out.

With Xfig or some similar graphics drawing program, like McDraw (am I revealing my age?), you can generate EPS files via mouse.  Xfig, like gnuplot, allows a special flag so it too can create combined PostScript/LaTeX files.

Dan