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