Menu
▾
▴
Re: grouping available terminals together
|
From: Mojca M. <moj...@gm...> - 2007-02-09 01:30:54
|
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
|
