gnuplot-beta — Developers and beta testers of new gnuplot code

Windows pause behaviour

[<HBB...@t-...>]

> Modified files:
> 	./: ChangeLog 
> 	gnuplot/src/: command.c 
> 
> Log message:
> 	On Windows, wait for Enter in console instead for a mouse click in a special
> 	window if the graph window is not (yet) present.

Ahem --- are you aware that the console window itself wouldn't be 
displayed at all, in a non-interactive session?  What good can a  "Press 
Enter" prompt in an invisible window do us?

Re: grouping available terminals together

[<HBB...@t-...>]

Ethan A Merritt wrote:
> On Thursday 08 February 2007 23:53, Timothée Lecomte wrote:
>> Maybe we should change the terminal API to:
>> * rgb colors
>> * dash patterns
>>
>> and the default linetypes would be handled by the core.
>> On a screen terminal:
>> -lt 1 would be red
>> -lt 2 would be blue
>> ...
>> On a print-oriented terminal:
>> -lt 1 would be red/solid
>> -lt 2 would be blue/dash
> 
> Isn't that exactly what we have now?
> 
> I am speculating, since the decision must date back to 
> the origins of gnuplot. 

Absolutely.  In a nutshell, since no two terminals agree 100% on what 
kinds of line they can draw, our founders decided on the sanest possible 
approach: the least common denominator.  Which is that on any remotely 
suitable output medium, there will be some way to draw at least a couple 
different types of lines, and that's *all* that can be said about them. 
  We can't generally prescribe they must differ in colour, width, 
pattern or whatever.  All we know is that the set of possible choice 
will be countable, so count them is what we do.  Which brought us the 
concept of a linetype number.

People seem to forget this, but the original promise in gnuplot has 
always been total cross-terminal script compatibility (setting aside 
only the 'set terminal' command itself), i.e. every script would produce 
useful output on every terminal, within reasonable boundaries.  In 
particular, that means no termination of scripts because terminal X 
doesn't support feature Y.

Re: symbol/color/line consistency in terminals

[<HBB...@t-...>]

Daniel J Sebald wrote:

> - "latex" doesn't support color, but we could upgrade that to use color
>   package.  (Just LaTeX is still very useful for basic figures.)

That would gravely endanger any usefulness of this driver.  The only 
real virtue of "latex" compared to other Tex-family drivers (emtex, 
eepic, and PostScript+LaTeX ones) is that its output is pure, 
unextended, driver-independent LaTeX.  Pulling in terminal-specific 
packages like "colour" would break that.

> - "jpeg", "png", "gif" and "tkcanvas" have no line patterns.

That's because GD, last I looked, didn't support linewidths on patterned 
lines.  Which made it rather pointless to try and implement dashing for 
the first three.

I have no idea what tk can, or can not do.

> - "jpeg" exactly matches "png" and "gif", but the colors are a slightly darker
>   hue than the other two output devices.  (No big problem, just peculiar.)

That could be due to a colour-space or gamma-factor difference somewhere 
between gnuplot and your eyes.  It's hard to tell whether the difference 
takes place on the way to the JPEG file, or on the way from there to 
your eye.

Re:

[<HBB...@t-...>]

Petr Mikulik wrote:
> I propose to change the message
> 
> 	Notice: cannot contour non grid data!
> 
> into
> 
> 	Notice: Cannot contour non grid data. Please use "set dgrid3d".
> 
> Any objections?

Yes.  "set dgrid3d" is far from being the single, obvious solution to 
the problem.  A good portion of people having this problem simply don't 
know about grid-structured data files.  For them dgrid3d would be the 
wrong thing to do.

If you want to put a recommendation, make it a reference to (a to-be 
written node of) the manual.

Re: grouping available terminals together

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

On 2/10/07, Daniel J Sebald wrote:
>
> Is there similar resistance for making line pattern consistent as possible with libraries/drivers that support dashed?

When I needed to define the dash patterns, I figured out that they are
different for PDF and PS (I didn't look at other terminals), although
there should be no reason for that. I took the ones defined in PS, to
remain as compatible as possible. It would be nice if those patterns
would match as well.

Mojca

PS: I don't know if these terminals are still worth suporting, but
pstricks terminal doesn't support colored lines either (no reason for
that).

Re: grouping available terminals together

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

T24gMi8xMC8wNywgRXRoYW4gTWVycml0dCB3cm90ZToKCj4gTGFUZVggaGFzIGEgY2VydGFpbiBz
ZXQgb2Ygc3ltYm9scyBkZWZpbmVkIGluIHRoZSBzdGFuZGFyZC4KPiBUaGUgYmVzdCB3ZSBjb3Vs
ZCBkbywgSSB0aGluayBpcyBzb21ldGhpbmcgbGlrZQo+IDEgKyAgICAgKwo+IDIgeCAgICAgXHRp
bWVzCj4gMyAqICAgICBcYXN0Cj4gNCDiiqEgICAgIFxCb3gKPiA1ICAgICAgIE4vQQo+IDYg4oqZ
ICAgICBcY2lyYwo+IDcg4oCiICAgICBcYnVsbGV0Cj4gOCDiiIYgICAgIFxiaWd0cmlhbmdsZXVw
Cj4gOSAgICAgICBOL0EKPiAxMCAgICAgIFxiaWd0cmlhbmdsZWRvd24KPiAxMSAgICAgIE4vQQo+
IDEyICAgICAgXGRpYW1vbmQKPgo+IEkgZG9uJ3Qga25vdyB3aGF0IHRoZSByZWd1bGFyIExhVGVY
IHRlcm1pbmFsIHVzZXJzIG1pZ2h0IHRoaW5rCj4gYWJvdXQgdGhhdC4gIE1ha2UgYSBwcm9wb3Nl
ZCBwYXRjaCBhbmQgc2VlPwoKQXQgdGhlIHZlcnkgYm90dG9tIG9mCmh0dHA6Ly9zb3VyY2Vmb3Jn
ZS5uZXQvdHJhY2tlci9kb3dubG9hZC5waHA/Z3JvdXBfaWQ9MjA1NSZhdGlkPTMwMjA1NSZmaWxl
X2lkPTIxNTAwMyZhaWQ9MTY1NDgwNwp5b3UgY2FuIHNlZSB3aGljaCBzeW1ib2xzIEkgdXNlZCBm
b3IgQ29uVGVYdCAoYnV0IEkgd291bGQgaGF2ZSB0bwpjaGVjayBpZi9ob3cgdGhleSB3b3JrIGlu
IExhVGVYKS4gVGhleSBzaG91bGQgYmUgcHJldHR5IHNpbWlsYXIKKHN5bnRheCBmb3Igc2NhbGUg
aXMgZGlmZmVyZW50IGluIExhVGVYLCBhbmQgc2NhbGUgZmFjdG9ycyBzaG91bGQgYmUKZGlmZmVy
ZW50IGFzIHdlbGwsIHBlcmhhcHMgZGVwZW5kaW5nIG9uIGZvbnQgc2l6ZSk6Cgp7XHNjYWxlW3Nj
YWxlPTgwMF17JCskfX0sCntcc2NhbGVbc2NhbGU9ODAwXXskXHRpbWVzJH19LAokXGFzdCQsCntc
c2NhbGVbc2NhbGU9NzAwXXskXHNxdWFyZSR9fSwKe1xzY2FsZVtzY2FsZT03MDBdeyRcYmxhY2tz
cXVhcmUkfX0sCiRcY2lyYyQsCiRcYnVsbGV0JCwKe1xzY2FsZVtzY2FsZT05MDBdeyRcdHJpYW5n
bGV1cCR9fSwKe1xzY2FsZVtzY2FsZT05MDBdeyRcYmxhY2t0cmlhbmdsZSR9fSwKe1xzY2FsZVtz
Y2FsZT05MDBdeyRcdHJpYW5nbGVkb3duJH19LAp7XHNjYWxlW3NjYWxlPTkwMF17JFxibGFja3Ry
aWFuZ2xlZG93biR9fSwKe1xzY2FsZVtzY2FsZT04MDBdeyRcbG96ZW5nZSR9fSwKe1xzY2FsZVtz
Y2FsZT04MDBdeyRcYmxhY2tsb3plbmdlJH19JSwKJSAge1xyb3RhdGVbcm90YXRpb249NDVdeyRc
c3F1YXJlJH19LAolICB7XHJvdGF0ZVtyb3RhdGlvbj00NV17JFxibGFja3NxdWFyZSR9fSwKClNv
IHRoZSAiZmlsbGVkIiBzeW1ib2xkIHNob3VsZCBiZSBwcmVzZW50IGluIExhVGVYIGFzIHdlbGwu
CgpUbyBiZSBob25lc3Q6IEkgYWx3YXlzIGhhdGVkIHRoZSBkZWZhdWx0IHNldCBvZiBzeW1ib2xz
IGluIHRoZSBMYVRlWAp0ZXJtaW5hbCwgc28gZXZlcnkgdGltZSBJIHVzZWQgaXQsIEkgZGlkIHNv
bWV0aGluZyBsaWtlCiAgICBcZGVmXERpYW1vbmR7XGNvbG9yW3JlZF17XGJ1bGxldH19ICUgc29y
cnkuIEkgZm9yZ290IHRoZSBleGFjdApjb2xvciBzeW50YXggZm9yIExhVGVYCm9yIHNlYXJjaC1y
ZXBsYWNlZCBhbGwgdGhlIHBsdXNlcyBpbiB0aGUgcmVzdWx0aW5nIGZpbGVzIHdpdGgKc29tZXRo
aW5nIG1vcmUgc3VpdGFibGUuCgpJIHdvdWxkIHN1Z2dlc3QgdG8gcHV0IHNvbWV0aGluZyBsaWtl
CgpcZGVmXEdudXBsb3RTeW1ib2wjMXtcaWZjYXNlIzEgXEdwU3ltSSBcb3IgXEdwU3ltSUkgXG9y
IFxHcFN5bUlWIFxvcgpcR3BTeW1WIFxvciBcR3BTeW1WSSBcb3IgXEdwU3ltVklJIC4uLiBcZmkg
fQoKYW5kIHRoZW4KClxkZWZcR3BTeW1JeyQrJH0gJSBwZXJoYXBzIGluY2x1ZGluZyB0aGUgc2Nh
bGUgc29tZXdoZXJlClxkZWZcR3BTeW1JSXskXHRpbWVzJH0KXGRlZlxHcFN5bUlJSXskXGFzdCR9
Ci4uLiBldGMuCgphdCB0aGUgdG9wIG9mIHJlc3VsdGluZyBmaWxlLgoKU28gdGhlIG9uZSB3aG8g
d291bGQgbGlrZSB0byByZWRlZmluZSB0aGUgc3ltYm9scywgd2lsbCBiZSBhYmxlIHRvCmNoYW5n
ZSBhIHNpbmdsZSBsaW5lIG9ubHkuIChQZXJoYXBzIG9uZSBjb3VsZCBhbHNvIGNoZWNrIGlmIGEg
cG9pbnQKdGltZSBoYXMgYWxyZWFkeSBiZWVuIGRlZmluZWQgZWFybGllciwgYW5kICJkZWZpbmUi
IHRoZSBkZWZhdWx0IHN5bWJvbApvbmx5IGlmIGl0IGhhcyBub3QgYmUgZGVmaW5lZCBlYXJsaWVy
LiBUaGF0IHdheSBhIHVzZXIgd291bGQgYmUgYWJsZQp0byBkZWZpbmUgaGlzIG93biBzeW1ib2xz
IHNvbWV3aGVyZSBhdCB0aGUgZG9jdW1lbnQgcHJlYW1ibGUgYW5kIHdvbid0CmhhdmUgdG8gY2Fy
ZSBhYm91dCBmaXhpbmcgdGhlIGZpbGVzIHRoYXQgcmVzdWx0ZWQgZm9ybSBnbnVwbG90IHJ1bi4p
CgpUaGUgc3ludGF4IGFib3ZlIG1heSBiZSBhbGwgd3JvbmcsIGJ1dCBqdXN0IGFuIGlkZWEgYWJv
dXQgdGhlIHBvc3NpYmxlCnByaW5jaXBsZS4gSSBjYW4gY2hlY2sgdGhlIGV4YWN0IHN5bnRheCBp
ZiBuZWVkZWQgKGJ1dCBub3QgdG9kYXkpLgoKTW9qY2EK

Re: grouping available terminals together

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

Ethan Merritt wrote:
> On Friday 09 February 2007 13:22, Daniel J Sebald wrote:
> 
>>OK, I've look at test in as many terminals as possible.  
> 
>  
> 
>>- "png" doesn't appear to have a "dashed" option.
> 
> 
> Right. Many terminals have no support for dashes, and the ones that do may
> not allow you to change the patterns.  These are limitations imposed by the
> hardware/firmware/support library.

OK.  Would it be nice if all terminals accepted the word dashed and simply stated "dashes not supported"?  Not that important, but if it is a fairly common option... guess there's been discussion in similar vein regarding other options.


>>- Number to symbol translation is pretty consistent across terminals up to #13.
> 
> 
> Good. That's what I thought you were worried about.

Yes, I didn't realize they are as consistent as they are now.


>>- "pdf" has same exact symbol translation as "postscript" except #1 is a dot,
>>  not a plus (BUG?).
> 
> 
> It's a plus sign in the code.  See pdf.trm lines 727ff
> So yes, there must be a bug somewhere.
> A fix would be welcome.

Already on SourceForge.


>>- "fig" has symbol inconsistencies after #4 (BUG?).
>>- "tkcanvas" has symbol inconsistencies after #4 similar to fig
> 
> 
> I don't know anything about fig or tkcanvas.

OK, I'll take care of those.


>>- "latex" has symbol inconsistencies immediately (BUG?).
> 
> 
> LaTeX has a certain set of symbols defined in the standard.
> The best we could do, I think is something like
> 1 +	+
> 2 x	\times
> 3 *	\ast
> 4 ⊡	\Box
> 5 	N/A
> 6 ⊙	\circ
> 7 •	\bullet
> 8 ∆	\bigtriangleup
> 9 	N/A
> 10	\bigtriangledown
> 11	N/A
> 12	\diamond
> 
> I don't know what the regular LaTeX terminal users might think
> about that.  Make a proposed patch and see?

There seems to be plent of symbols, just the order is different from other terminals.  I'll look at that and adding a color option. 


>>- Number to color translation isn't near consistent.
> 
> That horse was beaten to death.  The colors are not intended to match,
> because different colors are appropriate for different output media.

No problem.  Just wanted to confirm.

Is there similar resistance for making line pattern consistent as possible with libraries/drivers that support dashed?

Dan

Re: grouping available terminals together

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

On Friday 09 February 2007 13:22, Daniel J Sebald wrote:
>=20
> OK, I've look at test in as many terminals as possible. =20
=20
> - "png" doesn't appear to have a "dashed" option.

Right. Many terminals have no support for dashes, and the ones that do may
not allow you to change the patterns.  These are limitations imposed by the
hardware/firmware/support library.

> - Number to symbol translation is pretty consistent across terminals up t=
o #13.

Good. That's what I thought you were worried about.

> - "pdf" has same exact symbol translation as "postscript" except #1 is a =
dot,
>   not a plus (BUG?).

It's a plus sign in the code.  See pdf.trm lines 727ff
So yes, there must be a bug somewhere.
A fix would be welcome.

> - "fig" has symbol inconsistencies after #4 (BUG?).
> - "tkcanvas" has symbol inconsistencies after #4 similar to fig

I don't know anything about fig or tkcanvas.

> - "latex" has symbol inconsistencies immediately (BUG?).

LaTeX has a certain set of symbols defined in the standard.
The best we could do, I think is something like
1 +	+
2 x	\times
3 *	\ast
4 =E2=8A=A1	\Box
5 	N/A
6 =E2=8A=99	\circ
7 =E2=80=A2	\bullet
8 =E2=88=86	\bigtriangleup
9 	N/A
10	\bigtriangledown
11	N/A
12	\diamond

I don't know what the regular LaTeX terminal users might think
about that.  Make a proposed patch and see?


> - Number to color translation isn't near consistent.
That horse was beaten to death.  The colors are not intended to match,
because different colors are appropriate for different output media.


=2D-=20
Ethan A Merritt

symbol/color/line consistency in terminals

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

[resending to start new subject thread]

Daniel J Sebald wrote:

>>>> I thought we did that already. Which terminals escaped the grand
>>>> unification?
>
>> 
>> 
>> Really?  I wasn't watching list email for a while months back.  Maybe
>> I've missed something here.  I'll investigate.


OK, I've looked at test in as many terminals as possible.  Here are my observations.  (I've listed with "BUG?" the things I think are easy fixes that may have been overlooked.)

So, what are we striving for in terms of consistency?  Symbols are pretty close to consistent up to 12 or so.  Colors are not consistent, but there is the "rgb" color specification now so maybe that isn't an issue.  On the other hand, the first 6 colors are pretty consistent so maybe it is worth trying for more consistency (up to 12?).  Line type is inconsistent.  Would be nice to have a least the first 6 or so consistent.  Looks doable from what I've seen, but there is some work.  I wouldn't suggest trying for consistency in everything at once.  First, fix the few symbol problems with small patches.

Is there any of the below terminal patterns that might serve as the quasi-standard or most typical that *if* we were to seek consistency we'd aim for that one?  PostScript/PDF perhaps?

Dan


Comments:

- "png" doesn't appear to have a "dashed" option.
- Number to symbol translation is pretty consistent across terminals up to #13.
- "pdf" has same exact symbol translation as "postscript" except #1 is a dot,
  not a plus (BUG?).
- "fig" has symbol inconsistencies after #4 (BUG?).
- "latex" has symbol inconsistencies immediately (BUG?).
- "tkcanvas" has symbol inconsistencies after #4 similar to fig (BUG?).
- Number to color translation isn't near consistent.  However, the first five
  colors are pretty much red/green/blue/magenta/cyan.  After that #6 is
  sometimes yellow, sometimes brown.  After that, all terminals differ.
- Exception to the above is "tkcanvas" which is
  red/blue/green/brown/magenta/cyan (BUG?).
- Number to line pattern translation isn't near consistent.  There is fairly
  good agreement between line color and line pattern, but not perfect.
- "latex" doesn't support color, but we could upgrade that to use color
  package.  (Just LaTeX is still very useful for basic figures.)
- "jpeg", "png", "gif" and "tkcanvas" have no line patterns.
- "jpeg" exactly matches "png" and "gif", but the colors are a slightly darker
  hue than the other two output devices.  (No big problem, just peculiar.)
- The following accept "dashed" as option:  x11, postscript, pdf, fig
- The following accept "color" as option:  postscript, fig


Symbol translation for "x11 dashed" terminal:

-1 - black / solid / none
0 - black / dotted / dot
1 - red / solid / plus
2 - green / dashed / x
3 - blue / dotted / asterisk
4 - magenta / long dash / open square
5 - cyan / ??? / filled square
6 - brown / dash-dash-blank / open circle
7 - orange / dashed / filled circle
8 - peach / dotted / open triangle
9 - red / solid / filled triangle
10 - green / dashed / open down triangle
11 - blue / dotted / filled down triangle
12 - magenta / dashed / open diamond
13 - cyan / ??? / filled diamond


Symbol translation for "post dashed color" terminal:

-1 - black / solid / none
0 - black / dotted / dot
1 - red / solid / plus
2 - green / dashed / x
3 - blue / dashed (shorter) / asterisk
4 - magenta / dashed (shorter still) / open square
5 - cyan / dash-dot / filled square
6 - yellow / ??? / open circle
7 - black / dash-dash-blank / filled circle
8 - orange / dash-dot-dot / open triangle
9 - gray / dash-dash-dash-dash-blank / filled triangle
10 - red / solid / open down triangle
11 - green / dashed / filled down triangle
12 - blue / dashed (shorter) / open diamond
13 - magenta / dashed (shorter still) / filled diamond
14 - cyan / dash-dot / pentagon
15 - yellow / ??? / filled pentagon
16 - black / dash-dash-blank / circle tick up
(various fractionally filled circles)
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32


Symbol translation for "pdf dashed" terminal:

-1 - black / solid / none
0 - gray / solid / dot
1 - red / solid / dot
2 - green / dashed / x
3 - blue / dashed (shorter) / asterisk
4 - magenta / dashed (shorter still) / open square
5 - cyan / dash-shortdash / filled square
6 - brown / dash-shorterdash / open circle
7 - yellow / dash-dash-blank / filled circle
8 - dark blue / dash-dot-dot / open triangle
9 - orange / solid / filled triangle
10 - dark green / dashed / open down triangle
11 - purple / dashed (shorter) / filled down triangle
12 - dark brown / dashed (shorter still) / open diamond
13 - red / dashed-shortdash-shortdash / filled diamond
14 - green / dash-dot / pentagon
15 - blue / dash-dash-blank / filled pentagon
16 - magenta / dot-dash-dot / circle tick up
(various fractionally filled circles)
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32


Symbol translation for "png" AND "gif" AND "jpeg" (slightly darker hue) terminal:

-1 - black / solid / none
0 - gray / dotted / dot
1 - red / solid / plus
2 - green / solid / x
3 - blue / solid / asterisk
4 - purple / solid / open square
5 - cyan / solid / filled square
6 - brown / solid / open circle
7 - yellow / solid / filled circle
8 - dark blue / solid / open triangle
9 - orange / solid / filled triangle
10 - dark green / solid / open down triangle
11 - dark purple / solid / filled down triangle
12 - dark brown / solid / open diamond
13 - magenta / solid / filled diamond
14 - dark green / solid / plus
(repeat pattern, various shades of previous colors)
15
16 - black / dash-dash-blank / circle tick up
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33


Symbol translation for "fig dashed color":

-1 - black / solid / none
0 - black / dotted / dot
1 - red / solid / plus
2 - green / solid / x
3 - blue / solid / asterisk
4 - magenta / solid / open square
5 - cyan / solid / open diamond
6 - yellow / solid / open triangle
7 - black / solid / plus
8 - brown / solid / x
9 - battleship gray / solid / asterisk
10 - red / dashed / open square
11 - green / dashed / open diamond
12 - blue / dashed / open triangle
13 - magenta / dashed / plus
14 - cyan / dashed / x
15 - yellow / dashed / asterisk
16 - black / dashed / open square
17 - brown / dashed / open diamond
18 - battleship gray / dashed / open triangle
19 - red / dash-blank / plus
20 - green / dash-blank / x
[snip]
28 - red / longdash / plus
[snip]
46 - red / longerdash / plus


Symbol translation for "latex" (no color, but like Xfig this could probably be
upgraded to use the LaTeX color package):

-1 - black / solid / none
0 - black / solid / dot
1 - black / solid / open diamond
2 - black / dotted / plus
3 - black / heavy solid / open square
4 - black / heavy dotted / x
5 - black / heavier solid / open triangle
6 - black / heavy dot-dot-blank / star
7 - black / solid / circle
8 - black / dotted / big circle
9 - black / heavy solid / bigger circle
10 - black / heavy dotted / filled circle
11 - black / heavier solid / filled big circle
12 - black / heavy dot-dot-blank / filled bigger circle


Symbol translation for "tkcanvas":

-1 - black / solid / none
0 - gray / solid / dot
1 - red / solid / plus
2 - blue / solid / x
3 - green / solid / asterisk
4 - brown / solid / open square
5 - magenta / solid / open diamond
6 - cyan / solid / open triangle
7 - black / solid / plus
8 - gray / solid / x
9 - red / solid / asterisk
10 - blue / solid / open square
11 - green / solid / open diamond
12 - brown / solid / open triangle
13 - magenta / solid / plus


Others I'd like to test but haven't tools (or desire to compile gnuplot with
various libraries right now):  svg, corel, emf

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
gnuplot-beta mailing list
gnu...@li...
https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: grouping available terminals together

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

Daniel J Sebald wrote:

>> I thought we did that already. Which terminals escaped the grand
>> unification?
> 
> 
> Really?  I wasn't watching list email for a while months back.  Maybe
> I've missed something here.  I'll investigate.

OK, I've look at test in as many terminals as possible.  Here are my observations.  (I've listed with "BUG?" the things I think are easy fixes that may have been overlooked.)

Comments:

- "png" doesn't appear to have a "dashed" option.
- Number to symbol translation is pretty consistent across terminals up to #13.
- "pdf" has same exact symbol translation as "postscript" except #1 is a dot,
  not a plus (BUG?).
- "fig" has symbol inconsistencies after #4 (BUG?).
- "latex" has symbol inconsistencies immediately (BUG?).
- "tkcanvas" has symbol inconsistencies after #4 similar to fig (BUG?).
- Number to color translation isn't near consistent.  However, the first five
  colors are pretty much red/green/blue/magenta/cyan.  After that #6 is
  sometimes yellow, sometimes brown.  After that, all terminals differ.
- Exception to the above is "tkcanvas" which is
  red/blue/green/brown/magenta/cyan (BUG?).
- Number to line pattern translation isn't near consistent.  There is fairly
  good agreement between line color and line pattern, but not perfect.
- "latex" doesn't support color, but we could upgrade that to use color
  package.  (Just LaTeX is still very useful for basic figures.)
- "jpeg", "png", "gif" and "tkcanvas" have no line patterns.
- "jpeg" exactly matches "png" and "gif", but the colors are a slightly darker
  hue than the other two output devices.  (No big problem, just peculiar.)
- The following accept "dashed" as option:  x11, postscript, pdf, fig
- The following accept "color" as option:  postscript, fig


Symbol translation for "x11 dashed" terminal:

-1 - black / solid / none
0 - black / dotted / dot
1 - red / solid / plus
2 - green / dashed / x
3 - blue / dotted / asterisk
4 - magenta / long dash / open square
5 - cyan / ??? / filled square
6 - brown / dash-dash-blank / open circle
7 - orange / dashed / filled circle
8 - peach / dotted / open triangle
9 - red / solid / filled triangle
10 - green / dashed / open down triangle
11 - blue / dotted / filled down triangle
12 - magenta / dashed / open diamond
13 - cyan / ??? / filled diamond


Symbol translation for "post dashed color" terminal:

-1 - black / solid / none
0 - black / dotted / dot
1 - red / solid / plus
2 - green / dashed / x
3 - blue / dashed (shorter) / asterisk
4 - magenta / dashed (shorter still) / open square
5 - cyan / dash-dot / filled square
6 - yellow / ??? / open circle
7 - black / dash-dash-blank / filled circle
8 - orange / dash-dot-dot / open triangle
9 - gray / dash-dash-dash-dash-blank / filled triangle
10 - red / solid / open down triangle
11 - green / dashed / filled down triangle
12 - blue / dashed (shorter) / open diamond
13 - magenta / dashed (shorter still) / filled diamond
14 - cyan / dash-dot / pentagon
15 - yellow / ??? / filled pentagon
16 - black / dash-dash-blank / circle tick up
(various fractionally filled circles)
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32


Symbol translation for "pdf dashed" terminal:

-1 - black / solid / none
0 - gray / solid / dot
1 - red / solid / dot
2 - green / dashed / x
3 - blue / dashed (shorter) / asterisk
4 - magenta / dashed (shorter still) / open square
5 - cyan / dash-shortdash / filled square
6 - brown / dash-shorterdash / open circle
7 - yellow / dash-dash-blank / filled circle
8 - dark blue / dash-dot-dot / open triangle
9 - orange / solid / filled triangle
10 - dark green / dashed / open down triangle
11 - purple / dashed (shorter) / filled down triangle
12 - dark brown / dashed (shorter still) / open diamond
13 - red / dashed-shortdash-shortdash / filled diamond
14 - green / dash-dot / pentagon
15 - blue / dash-dash-blank / filled pentagon
16 - magenta / dot-dash-dot / circle tick up
(various fractionally filled circles)
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32


Symbol translation for "png" AND "gif" AND "jpeg" (slightly darker hue) terminal:

-1 - black / solid / none
0 - gray / dotted / dot
1 - red / solid / plus
2 - green / solid / x
3 - blue / solid / asterisk
4 - purple / solid / open square
5 - cyan / solid / filled square
6 - brown / solid / open circle
7 - yellow / solid / filled circle
8 - dark blue / solid / open triangle
9 - orange / solid / filled triangle
10 - dark green / solid / open down triangle
11 - dark purple / solid / filled down triangle
12 - dark brown / solid / open diamond
13 - magenta / solid / filled diamond
14 - dark green / solid / plus
(repeat pattern, various shades of previous colors)
15
16 - black / dash-dash-blank / circle tick up
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33


Symbol translation for "fig dashed color":

-1 - black / solid / none
0 - black / dotted / dot
1 - red / solid / plus
2 - green / solid / x
3 - blue / solid / asterisk
4 - magenta / solid / open square
5 - cyan / solid / open diamond
6 - yellow / solid / open triangle
7 - black / solid / plus
8 - brown / solid / x
9 - battleship gray / solid / asterisk
10 - red / dashed / open square
11 - green / dashed / open diamond
12 - blue / dashed / open triangle
13 - magenta / dashed / plus
14 - cyan / dashed / x
15 - yellow / dashed / asterisk
16 - black / dashed / open square
17 - brown / dashed / open diamond
18 - battleship gray / dashed / open triangle
19 - red / dash-blank / plus
20 - green / dash-blank / x
[snip]
28 - red / longdash / plus
[snip]
46 - red / longerdash / plus


Symbol translation for "latex" (no color, but like Xfig this could probably be
upgraded to use the LaTeX color package):

-1 - black / solid / none
0 - black / solid / dot
1 - black / solid / open diamond
2 - black / dotted / plus
3 - black / heavy solid / open square
4 - black / heavy dotted / x
5 - black / heavier solid / open triangle
6 - black / heavy dot-dot-blank / star
7 - black / solid / circle
8 - black / dotted / big circle
9 - black / heavy solid / bigger circle
10 - black / heavy dotted / filled circle
11 - black / heavier solid / filled big circle
12 - black / heavy dot-dot-blank / filled bigger circle


Symbol translation for "tkcanvas":

-1 - black / solid / none
0 - gray / solid / dot
1 - red / solid / plus
2 - blue / solid / x
3 - green / solid / asterisk
4 - brown / solid / open square
5 - magenta / solid / open diamond
6 - cyan / solid / open triangle
7 - black / solid / plus
8 - gray / solid / x
9 - red / solid / asterisk
10 - blue / solid / open square
11 - green / solid / open diamond
12 - brown / solid / open triangle
13 - magenta / solid / plus


Others I'd like to test but haven't tools (or desire to compile gnuplot with
various libraries right now):  svg, corel, emf

Re: grouping available terminals together

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

On Thursday 08 February 2007 23:53, Timoth=E9e Lecomte wrote:
> Maybe we should change the terminal API to:
> * rgb colors
> * dash patterns
>=20
> and the default linetypes would be handled by the core.
> On a screen terminal:
> -lt 1 would be red
> -lt 2 would be blue
> ...
> On a print-oriented terminal:
> -lt 1 would be red/solid
> -lt 2 would be blue/dash

Isn't that exactly what we have now?

I am speculating, since the decision must date back to=20
the origins of gnuplot. But I think that the reason there
was no mechanism for specifying particular colors, and=20
still is no mechanism for specifying particular dot/dash
patterns, is that these were unchangeable properties of
the physical devices.  On a pen plotter you could request
pen #1, pen #2 or pen #3, but it was up to the operator to
choose the pen physically sitting in slot #1.  A slightly
more recent generation of printers offered a small number
of dot/dash patterns for line drawing, but gave you no
mechanism for defining new ones.  So the control program,
gnuplot in this case, can do no better than select=20
#1, #2, and so on.=20

=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: grouping available terminals together

[<tim...@en...>]

Ethan A Merritt wrote:
>
>> dash-dot is rare? =20
>>    =20
>
> Maybe my impression is biased because I mostly use the wxt and png term=
inals.
> Yeah there are a bunch of legacy drivers that support dash patterns
> (tpic gpr), but I never use them.  That leaves - what? - the postscript
> variants and the metafile variants.
>
> Which is fine, don't get me wrong.  The interactive terminals and the
> screen terminals are much better off with color than dot/dash.  It's re=
ally
> only needed for the print-oriented terminals, particularly PostScript.
>  =20

For my defense, I would say that I didn't implement dash patterns in wxt=20
because the terminal API is not designed for it. There are "linewidth",=20
"linetypes", "rgb colors" since recently, and that's all.
Linetypes doesn't imply anything in itself apart from being able to=20
distinguish the lines...

Maybe we should change the terminal API to:
* rgb colors
* dash patterns

and the default linetypes would be handled by the core.
On a screen terminal:
-lt 1 would be red
-lt 2 would be blue
...
On a print-oriented terminal:
-lt 1 would be red/solid
-lt 2 would be blue/dash
-lt 3 would be green/dot
...

If the terminal is monochrome:
-lt 1 would be solid
-lt 2 would be dash
-lt 3 would be dot
...

If the terminal does not support dash patterns:
-lt 1 would be red
-lt 2 would be blue
-lt 3 would be green
...

And somebody not satisfied with those defaults choices would use the=20
full API
plot x with lines rgbcolor #RRGGBB pattern 1

Best regards,

Timoth=E9e

Re: grouping available terminals together

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

On Thursday 08 February 2007 22:40, Daniel J Sebald wrote:
> 
> > "blue" we've got.
> > "stars"? So few terminals could support it that there seems no point.
> > "dashdot"? Ditto. 
> 
> I meant being able to specify the symbol by a name rather than number.

So put the definitions in your .gnuplot file.

plus  = 1
times = 2
stars  = 3
square = 4
solid_square = 5
circle = 6
solid_circle = 7

Then you can say
	plot <foo> with points pt stars lc rgb "blue",
             <baz> with points pt solid_circle lc rgb "cyan"

One thing we might consider, however, is whether it is safe
to allow a shorthand form
	set style data points    # this works
	plot <foo> pt stars      # but this isn't currently accepted

I'd have to think about whether that shorthand syntax is unambiguous.


Another possibility that works right now is this:

# defined in .gnuplot
set style line 101 pointtype 3 lc rgb "blue"
blue_stars = 101

	set style data points
	plot <foo> ls blue_stars



> dash-dot is rare?  

Maybe my impression is biased because I mostly use the wxt and png terminals.
Yeah there are a bunch of legacy drivers that support dash patterns
(tpic gpr), but I never use them.  That leaves - what? - the postscript
variants and the metafile variants.

Which is fine, don't get me wrong.  The interactive terminals and the
screen terminals are much better off with color than dot/dash.  It's really
only needed for the print-oriented terminals, particularly PostScript.

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: grouping available terminals together

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

Ethan A Merritt wrote:
> On Thursday 08 February 2007 20:58, Daniel J Sebald wrote:
> 
>>[BTW, can I get any movement on the idea of unifying the output 
>>symbols moving from terminal driver to terminal driver?
> 
> 
> I thought we did that already.
> Which terminals escaped the grand unification?

Really?  I wasn't watching list email for a while months back.  Maybe I've missed something here.  I'll investigate.

> "blue" we've got.
> "stars"? So few terminals could support it that there seems no point.
> "dashdot"? Ditto. 

I meant being able to specify the symbol by a name rather than number.  dash-dot is rare?  There seems to be a lot of the terminals with a dash-dot for the "rainbow" demo.

Dan

Re: grouping available terminals together

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

On Thursday 08 February 2007 20:58, Daniel J Sebald wrote:
> [BTW, can I get any movement on the idea of unifying the output 
> symbols moving from terminal driver to terminal driver?

I thought we did that already.
Which terminals escaped the grand unification?

> How about the "blue" "stars" "dashdot" idea?]  

"blue" we've got.
"stars"? So few terminals could support it that there seems no point.
"dashdot"? Ditto. 

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: grouping available terminals together

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

Mojca Miklavec wrote:
> On 2/9/07, Daniel J Sebald <dan...@ie...> wrote:
> 
>> 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.
> 
> 
> Who prevents them from doing so?

Knuth--a conscious decision in 1989 that there should be no change in the language, only bug fixes; and when he's gone there'll be no more of those, the idea being that if you have a file that compiles under TeX in 1989, it will compile under TeX in 2089.  (There've been a lot of articles about the obsolescence of programs and data as time marches on.)

For the same reason, there is a lot of resistance to changing gnuplot's syntax or behavior.

[BTW, can I get any movement on the idea of unifying the output symbols moving from terminal driver to terminal driver?  How about the "blue" "stars" "dashdot" idea?]


> There have been wonderful additions:
> we have eTeX, pdfTeX, XeTeX, (dead Aleph & Omega), luaTeX ...
> 
> Recent TeX distributions use pdfTeX instead of original TeX and
> original Knuth's "bitmap" cmr fonts are not used any more either.

Right, but they aren't called "TeX".  In the future if some mischievous individual decides to usurp the name, I'd suspect an uproar from the software community.


>> you can generate EPS files via mouse.  Xfig, like gnuplot, allows a 
>> special flag so it too can create combined PostScript/LaTeX files.
> 
> 
> But that means an additional non-interactive step or am I
> understanding wrong.

Yes:

1) Save as foo.
2) Inside some tex file (foo.tex) include:
  \resizebox{\columnwidth}{!}{\input{foo.pstex_t}}
3) latex foo.tex
4) dvips foo -o foo.ps  (add -E if you want a EPS file directly)
5) ps2eps foo.ps foo.eps

Then you have an EPS file that can be included in another LaTeX file.  If you don't want to do that much work, at step 2 simply include the command in the LaTeX document.  The reason for doing 3-4-5 is to create graphic files a journal editor can easily work with.  (Most journals accept LaTeX files.)


> I never use XFig. I manage to do all the
> mathematical graphics with command-line-like tools, and for "art" xfig
> is not good enough. (But for those who find it useful it's still a
> nice tool.)

On the Xfig screen, the drawings look crude, but when exported as PostScript they look similar to other PostScript output.  Granted, we aren't talking super high end graphics, but in the scientific fields, art is in the formulas, no?

Dan


-- 

Dan Sebald
phone: 608 256 7718
email: daniel DOT sebald AT ieee DOT org
URL: http://webpages DOT charter DOT net/dsebald/

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

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 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, 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

[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

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: ConTeXt terminal - any volunteers for testing?

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

Mojca,

I don't have time to test, but I looked through the PDF files in the link you gave.  The output looks nice.

Dan

Re: ConTeXt terminal - any volunteers for testing?

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

On 2/8/07, Ethan A Merritt wrote:
> On Wednesday 07 February 2007 23:36, Mojca Miklavec wrote:
> >
> > Instructions for trying it out can be found on the site with a patch itself:
> > http://sourceforge.net/tracker/index.php?func=detail&aid=1654807&group_id=2055&atid=302055
> >
> > One needs a reasonably recent TeX distribution. Now that TeXLive is
> > available (for Debian as well), it should be more straightforward to
> > try it out (half a year ago it wouldn't work on most TeX
> > distributions, as it doesn't work with teTeX either).
>
> My current distribution installs both teTeX and ConTeXt:
>     tetex-context-3.0-18mdv2007.0
>
> Are you saying that this won't work for testing?

Just as wxt probably doesn't work if libraries are too old ...

Hans has implemented quite some new features in ConTeXt on my request,
since performance of the terminal with pre-existing features was
"horrible" (ConTeXt needed approximately 12 minutes to compile 13
plots - if there were more, TeX ran out of memory). Now it's
considerably better (not even comparable to the situation before). It
takes me now 5 seconds to compile 6 plots. When I started using
ConTeXt 3 years ago, 30-40 seconds were needed only for a
"Hello-world" document (without any graphic or whatever other fancy
feature).

(I sometimes have a feeling that the ConTeXt developer has fourty
monkeys hidden somewhere, who do all the coding for him ;)

Theoretically, you can install (only unzip into the tree) the latest
version of Latin Modern and take a version of ConTeXt dated between
November 2006 and 12th January 2007(*), and hope that metapost is not
too old. Older versions are lacking some features and newer versions
require at least pdfTeX 1.40.x, which is not present on teTeX.

But I guess that installing Debian's texlive package (or perhaps
"rpmbuild --rebuild --force http://pmrb.free.fr/texlive/texlive.spm"),
downloading an ISO image from CTAN (you don't even have to install it,
you can run it from [virtual] DVD) or downloading ConTeXt minimals
from http://www.pragma-ade.com/download-1.htm (doesn't need
installation either), should be much easier.

You can try to compile files on
http://dl.contextgarden.net/misc/gnuplot-context.zip with "texexec
filename", but I'm pretty sure that the old teTeX won't do. Here are
some instructions about how to make the recent ConTeXt work on teTeX
3, but you really don't want to go that way
(http://wiki.contextgarden.net/TeTeX_3.0_installation).

Mojca

(*) if you're worried about the very limited range of possible
versions: I'm keeping the version of supporting files synchronized
with ConTeXt (if I request a new feature, I improve the terminal when
that feature is added to ConTeXt), but I did my best to organize the
code in such a way, that there is a well-defined & extensible
interface that shouldn't depend on gnuplot version used.
This means that when I'll add support for transparency or extend
support for palettes/images, new versions of ConTeXt files should
support output of either new or old gnuplot without any problem. (The
two supporting files, esp. t-gnuplot.tex, [will] keep changing over
time, but that shouldn't be a problem.) The only problem would arise
if one would decide to use considerablty newer gnuplot's binary (with
new feature implemented) than the version of ConTeXt supporting files,
but that should not happen (or at least it's straightforward to
install new ones - one only needs to copy them to the proper place).

Re:

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

On Thursday 08 February 2007 09:04, Petr Mikulik wrote:
> I propose to change the message 
> 	Notice: cannot contour non grid data!
> into
> 	Notice: Cannot contour non grid data. Please use "set dgrid3d".

Good idea.
For 4.2 as well as cvs.

	EAM

-- 
Ethan A Merritt