gnuplot-beta

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

[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...>]

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

[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

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: symbol/color/line consistency in terminals

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

Daniel J Sebald wrote:
> Hans-Bernhard Bröker wrote:

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

> Not sure I follow.  The LaTeX driver already uses the symbol 
> package(s).  

Using packages as such is not the problem.  Using packages that only 
work with a certain subset of DVI drivers, is.

> monochrome but also have no color commands.  Similarly, there is now 
> rotated text, for which we can use the LaTeX rotate package. 

... which used dvips specials last I looked, so causes the same kind of 
problem.

The moment "set term latex" produces dvi files with \special in them, it 
becomes pointless to have it.

Re: symbol/color/line consistency in terminals

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

Hans-Bernhard Bröker wrote:
> Daniel J Sebald wrote:
> 
>> Hans-Bernhard Bröker wrote:
> 
> 
>>> 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.
> 
> 
>> Not sure I follow.  The LaTeX driver already uses the symbol package(s).  
> 
> 
> Using packages as such is not the problem.  Using packages that only 
> work with a certain subset of DVI drivers, is.

Oh, yeah I see.  You mean such as when some xdvi output places labels out in space when rotating a block of text.  Guess so.  Ultimately comes out correctly in PostScript so it never bothered me too much.

> 
>> monochrome but also have no color commands.  Similarly, there is now 
>> rotated text, for which we can use the LaTeX rotate package. 
> 
> 
> ... which used dvips specials last I looked, so causes the same kind of 
> problem.

Not sure on that one.  I've turned on -warnspecials in xdvi and it gives plenty of warnings like:

xdvi.bin:  special "color push rgb 0 0 0" not implemented

But I don't seen any warnings for rotated text.  It could be that xdvi simply hasn't gotten around to supporting rotated text.  Any idea?

> 
> The moment "set term latex" produces dvi files with \special in them, it 
> becomes pointless to have it.

How about an option "set term latex specials"?

Dan

Re: symbol/color/line consistency in terminals

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

Daniel J Sebald wrote:

> How about an option "set term latex specials"?

I'll answer my own question and save you some work...  That's what "pslatex" is for.

Dan

Re: symbol/color/line consistency in terminals

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

Daniel J Sebald wrote:

> Not sure on that one.  I've turned on -warnspecials in xdvi and it gives 
> plenty of warnings like:

> But I don't seen any warnings for rotated text.  It could be that xdvi 
> simply hasn't gotten around to supporting rotated text.  Any idea?

The reason xdvi doesn't warn about this is because xdvi does have some 
support for PostScript specials, implemented by passing the work off to 
ghostscript or other tools (--> man xdvi).

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

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

[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

[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

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

[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: 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: symbol/color/line consistency in terminals

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

Hans-Bernhard Bröker wrote:

>> - "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'm not real familiar with GD, but the header file has:

gdImageSetStyle ();
gdImageSetThickness ();

Dan

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: grouping available terminals together

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

Hans-Bernhard Bröker wrote:
> 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.
And it was the right decision at that time.

But do we want gnuplot to stay at what was the least-common denominator 
20 years ago ? How many people use gnuplot right now for pen plotters ?
And since we provide rgb colors, why not doing the same with other kind 
of "modern" features ?

>  
>   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.
>   
Note that the concept of linetype number looks very useful to me to 
provide sensible default styles.

Timothée

Re: symbol/color/line consistency in terminals

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

Hans-Bernhard Bröker wrote:
> 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.

Not sure I follow.  The LaTeX driver already uses the symbol package(s).  What I am thinking is having an option "set term latex color", that will allow placing the appropriate LaTeX color package \color[rgb]{#,#,#} commands.  Without that option the figure will be monochrome but also have no color commands.  Similarly, there is now rotated text, for which we can use the LaTeX rotate package.  This one I don't think needs a special "set term latex rotate".  That would be confusing and there is no need for a "rotate" command if the user doesn't specify some piece of rotated text.

> 
>> - "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.

No desire to add features to tk, just make things a bit more consistent.

Dan

Re: symbol/color/line consistency in terminals

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

> Similarly, there is now rotated text, for which we can use the LaTeX rotate package.  This one I don't think needs a special "set term latex rotate".  That would be confusing and there is no need for a "rotate" command if the user doesn't specify some piece of rotated text.


"ylabel" is rotated by 90 degrees by default, so yes - if supported, I
guess that you really need to provide a special keyword for it.

I would think (but I don't have LaTeX at hand on this computer) that
rotation and color should be supported by both dvips & pdfTeX, but
default options should not use any specials.

Having color in LaTeX terminal would nevertheless be very nice. The
old scripts won't break if you have to add the option color
explicitely, esp. since color is most probably supported by all most
important devices. It's not 100% clean and portable, but users would
probably prefer to have color than 100% portability, esp. if they
deliberately choose so (by selecting "color rotate").

(I missed the color very much when I was still using the LaTeX
terminal, and I didn't like eepic - it had worse defaults, even if
only the default linewidth and tic length was different than in LaTeX)

Mojca

Re: symbol/color/line consistency in terminals

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

On Saturday 10 February 2007 11:28, Daniel J Sebald wrote:
> Hans-Bernhard Br=F6ker wrote:
> >=20
> > That's because GD, last I looked, didn't support linewidths on patterne=
d=20
> > lines.  Which made it rather pointless to try and implement dashing for=
=20
> > the first three.
>=20
> I'm not real familiar with GD, but the header file has:
>=20
> gdImageSetStyle ();
> gdImageSetThickness ();

Take my word for it, the gd routines for dashed lines and for
linewidth are useless for our purposes.

We work around the latter by defining a finites size 'brush' for drawing,
but there is no easy work-around for dashed lines.  And given that
PNG output is normally for screen display, and thus color is far
more useful than dashes, there is little incentive to code up a hack.

Anyhow, if it's to be new code, it makes more sense to add that new code
to the gd library than to gnuplot.

You could ask Pierre Joye, who is now directing libgd development,
if he would be interested in accepting a patchset for libgd that
implements more useful support for linewidth+dashed lines. If libgd
provided such support, it would make sense for gnuplot to use it.

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

Re: symbol/color/line consistency in terminals

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

Ethan A Merritt wrote:
> On Saturday 10 February 2007 11:28, Daniel J Sebald wrote:
> 
>>Hans-Bernhard Bröker wrote:
>>
>>>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'm not real familiar with GD, but the header file has:
>>
>>gdImageSetStyle ();
>>gdImageSetThickness ();
> 
> 
> Take my word for it, the gd routines for dashed lines and for
> linewidth are useless for our purposes.

Some way of specifying a resolution for PNG-like terminals might be nice.  Am I overlooking something?

If I say

set term png size 1280,960
set output 'test.png'
text
set output

the result is a 1280 x 960 PNG image with the same resolution as the previous 640 x 480 PNG image.  That is, depending on one's viewpoint, it's as though every plot item has become 1/2 the size relative to the plot coordinate system.

The PNG documentation says something about "set size", but that doesn't achieve the concept of increasing resolution, just changes the portion of the PNG array used.

Now, I guess I could increase resolution by making the pointsize twice as big, line thickness twice as big, etc.  In fact, this setting

set term png giant size 1280,960
set pointsize 2.5

makes the symbol samples in "test" about the same as other plots (30 to 35 examples in the column) and the symbols are pretty good resolution.  But that doesn't exactly give the desired overall effect.  Adjusting so much becomes inconvenient.

So, it seems to me that with PNG one is inherently restricted to low resolution plots.  One could argue it is for network graphics, but still 1000x1000 in a compact format like PNG doesn't seem excessive.

Say there were a "resolution #" option that would internally scale line thickness, pointsize, and fonts (have to have a mapping to medium, large, giant... unfortunately the largest font doesn't have very high resolution).

Dan

"set scale" as opposed to "set size" or something else

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

On Sunday 11 February 2007 00:22, Daniel J Sebald wrote:
> set term png size 1280,960
>=20
> the result is a 1280 x 960 PNG image with the same resolution as the=20
> previous 640 x 480 PNG image.  That is, depending on one's viewpoint,=20
> it's as though every plot item has become 1/2 the size relative to=20
> the plot coordinate system.  =20
> I could increase resolution by making the pointsize twice=20
> as big, line thickness twice as big, etc.

I believe that this was the original intent of the "set size" command.
It later got co-opted to implement multiplot mode instead.
The original terminal entry point  term->scale() is still there, however.

It is interesting that Timoth=E9e recently submitted a patchset (#1616945)
to remove this terminal entry, and now you are arguing in effect that
we whould intead resurrect it for its original purpose. =20

So if I may re-phrase your suggestion.  We should add a command
	set scale <multiplier>
that is passed to each terminal.  Terminals capable of uniform scaling
would apply this multiplier to relevant plot elements, including
	font size
	point size
	line width
	dash length

This is not strictly necessary, as all of these can be set separately
for terminals that support them.  But it would add some degree of=20
convenience.

	Ethan


[nit-picking follows]

> Say there were a "resolution #" option that would internally scale line=20
thickness, pointsize, and fonts (have to have a mapping to medium, large,=20
giant... unfortunately the largest font doesn't have very high=20
resolution).

What is this "medium, large, giant" business? =20
Surely you are not still using the old 1999 PNG driver!
We've had support for scalable fonts for about 6 years now.
You can scale up to posterboard size if you want.

See for example the label "Kuen's Surface" in the transparent solids demo
   http://gnuplot.sourceforge.net/demo_4.3/transparent_solids.html
That is an intricate script font scaled up about 3x from the typical
font size used for PNG plots, and it scales beautifully.


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