Re: How big are points supposed to be?

[Ethan M. (UW) <me...@uw...>]

On Saturday, 13 July 2019 08:23:34 Dima Kogan wrote:
> Hi.
> 
> I'm observing a specific behavior that probably isn't a bug, but it's
> quite annoying. I'd like a comment.
> 
> Most of my usage of gnuplot is via the feedgnuplot tool:
> https://github.com/dkogan/feedgnuplot
> 
> Usually I'm making interactive plots (x11 terminal) as I explore the
> data. For instance, to plot 5 points with circles:
> 
>   seq 5 | feedgnuplot --with 'points pt 7 ps 2'
> 
> Eventually I'm done, and I want to make a pdf to send out in an email:
> 
>   seq 5 | feedgnuplot --with 'points pt 7 ps 2' --hardcopy whatever.pdf
> 
> This produces the same plot, but targetting a pdf file on a single
> landscape-oriented sheet of letter paper. The terminal is set up like
> this:
> 
>   set terminal pdfcairo noenhanced solid color font ",12" size 11in,8.5in
> 
> This works as expected. But the circles appear much bigger in the pdf
> than they did on the x11-terminal plot. To make the pdf look the same I
> have to manually reduce the size of the points, which is really
> annoying.
> 
> Does anybody know what the logic is governing the size of the points
> gnuplot renders? 

For some older terminals a "point" was just another character.
Introduction of characters as acceptable "point types" in version 5
was in this sense a return to the original idea.  In both old and the
new cases the size of the point scales with the font used to print the
character.

The large middle ground is handled by the generic routine do_point()
in term.c.  This routine constructs the standard sequence of point shapes
using a set of short line segments whose basic length
is taken from term->h_tic.   In other words, it assumes that the
current terminal has provided an appropriate unit size for points
in term->h_tic.

At this point things start to fall apart because different terminals
take different approaches to defining h_tic.  

PostScript, tek, hpgl and some of the other really old terminals set
h_tic to a constant value:
E.g.
	post.h:     #define PS_HTIC (PS_YMAX/80)
	win.trm:    #define WIN_HTIC (WIN_XMAX/160)

Most terminals set it based on the estimated average character width 
in the current font:
E.g.
	svg.trm:    term->h_tic = term->v_char / 2;
	cairo.trm:  term->h_tic = (unsigned int) (term->v_char/2.5);
	qt_term.c:  term->h_tic = (unsigned int) (term->v_char/2.5);
	aquaterm.trm:  term->h_tic = term->v_char / 3;

I have no idea why the ratio of h_tic to v_char varies between 2 and 3,
other than to note that the estimated character width is very empirical
and different terminals vary in how well they can estimate. That is the
purpose of the central block of boxed characters in the middle of the
output from "test" - it shows how good or bad the terminal is doing in
trying to estimate character width.

> It's somewhat arbitrary in this case: in the x11
> terminal the points stay the same size as you zoom, but with pdfcairo,
> naturally everything becomes larger as you zoom in. Is there any
> particular rationale to whatever arbitrary choice we have made to
> control this? If it's completely arbitrary, can we make a specific
> design choice, and then make the terminals agree with each other? I
> think making page-sized hardcopies produce comparable point sizes is a
> reasonable expectation. 

> Thoughts?

As usual there is a conflict between the goal of having uniform 
terminal-independent behaviour and the goal of perfect backward
compatibility.

(1) This isn't a new conflict and it isn't the first time that the 
specific issue of point sizes came up.  That's why many (all?) terminals
accept a "pointsize <scale-factor>" option to "set term".   So one option
is to experiment in advance with the output formats you are likely to want,
then adjust and save the corresponding "set term FOO pointsize BAZ"
commands for future use.

(2) Alternatively, don't use the original fixed sequence of point shapes
at all. Instead redefine your standard set of line/point/dash properties
in ~/.gnuplot to use character-based point shapes:

	set linetype 1 lc rgb "dark-violet" pt "✕"
	set linetype 2 lc rgb "#009e73" pt "⚫"
	set linetype 3 lc rgb "#56b4e9" pt "⚪"
	set linetype 4 lc rgb "#e69f00" pt "☉"
	set linetype 5 lc rgb "#f0e442" pt "◐"
	set linetype 6 lc rgb "#0072b2" pt "◔"
	set linetype 7 lc rgb "#e51e10" pt "□"
	set linetype 8 lc rgb "black"   pt "▲"
	set linetype 9 lc rgb "gray50"  pt "▽"

These will scale with the current font.  I am uncertain whether the
current code is consistent about applying "pointsize <scale>" on top 
of the font size.  That might be worth further investigation.

For normal plotting I would be inclined to go with option 2.
However if you are dealing with huge numbers of points there is a
size/time penalty for drawing each one as text rather than as
line segments.

	Ethan