Re: Inconsistent point types between terminals

On Wednesday, 5 February 2020 19:49:06 PST Dima Kogan wrote:
> Ethan A Merritt <me...@uw...> writes:
> > On Thursday, 30 January 2020 21:32:02 PST Dima Kogan wrote:
> >> Hi. I just stumbled upon another bug-looking behavior.
> >> 
> >> The different point types aren't the same across terminals. There's no
> >> specific reason for that, right?
> > 
> > gnuplot> help pointttype
> > 
> > [...]
> > 
> >  The first 8 point types are shared by all terminals. Individual terminals
> >  may provide a much larger number of distinct point types. Use the `test`
> >  command to show what is provided by the current terminal settings.
> 
> Aha. Thanks for the note. I'd like to normalize this at least somewhat.
> The usual workflow for me (and probably for others) is:
> 
> 1. Do work, mess around with the data, look at it with an interactive
>    terminal (x11 in my case) as I go. Make plots lots of times
> 
> 2. Eventually I'm happy with what I have, I make a PDF and send it out
>    in an email
> 
> The expectation is that the PDF is the same thing I was seeing on the
> screen, and the inconsistent point types break that. I want to say that
> of the common terminals I looked at, the x11 terminal is the odd one
> out. If that's the case, any objections if I patch that?

It is not correct that the x11 terminal is the odd one out.

There is a lot of variation.  For example the postscript terminal
supports about 70 point types, which so far as I know are inherited
by other terminals that depend on it like epslatex.
The fig terminal supports about 60. 
The png terminal (and jpeg/gif/sixel) are limited to 13, like x11.
The tikz terminal, which would be another way to generate pdf output,
supports 15 but they are not the same ones as qt/wxt.

Some of the older terminals were even more limited, which was why
we only promised 8 distinct types, but those may be obsolete.

Furthermore the reason that x11 currently doesn't support
pentagon shapes to match qt and wxt pointtype 14/15 
is that they come out indistinguisable from ugly circles
so they are not very useful.

Possible approaches that might help your use case:

1)
We could revisit an old idea that was discussed years ago but never
fully worked out.   There could be a command
	set pointtype cycle N
that replaces any arbitrary pt M with pt (1 + M%N).
This command would work similarly to the current command
	set linetype cycle N
I.e. it forces a cycle of N point types even if the current terminal
can support more than N types.

Unfortunately the patches that circulated at that time don't work any more
because version 5 changed the way linetypes and associated properties are
handled.  It's not clear to me exactly how best to adapt them to version 5.

2)
You could approximate this idea by explicitly assigning point types
for as many linetypes as you are likely to use:
    max_pt = 8
    set for [i=1:100] linetype i pointtype (1 + (i-1) % max_pt)

3)
Use character point types instead of the default geometric shapes.
So long as you choose characters that are common to the fonts used
for the terminals you are switching between, this should make the
default sequence irrelevant.

	Ethan