Thread: x11 point symbols

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

It seems that x11 point symbols number 14 and 15 differ from those of 
postscript. Someone knows how to change them?

---
PM

On Monday 27 February 2006 09:11 am, Petr Mikulik wrote:
> It seems that x11 point symbols number 14 and 15 differ from those of
> postscript. Someone knows how to change them?

That would not be a good idea.  The resolution of a typical X11 display
is not good enough to distinguish a pentagon (which is what the 
postscript 14 and 15 are) from a circle.  Better to have fewer symbols
that are mutually distinguishable than to cycle through symbols that
are confusingly similar.

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

On Mon, Feb 27, 2006 at 10:05:11AM -0800, Ethan Merritt wrote:
> On Monday 27 February 2006 09:11 am, Petr Mikulik wrote:
> > It seems that x11 point symbols number 14 and 15 differ from those of
> > postscript. Someone knows how to change them?

> That would not be a good idea.  The resolution of a typical X11 display
> is not good enough to distinguish a pentagon (which is what the=20
> postscript 14 and 15 are) from a circle.  Better to have fewer symbols
> that are mutually distinguishable than to cycle through symbols that
> are confusingly similar.

    Well, I see your point but I actually think it is annoying to have
different renders with different terminals. And it does take by surprise
the newbye.

--=20
    Ga=EBl

On Monday 27 February 2006 11:40 am, Ga=EBl Varoquaux wrote:
> On Mon, Feb 27, 2006 at 10:05:11AM -0800, Ethan Merritt wrote:
> > Better to have fewer
> > symbols that are mutually distinguishable than to cycle through
> > symbols that are confusingly similar.
>
>     Well, I see your point but I actually think it is annoying to
> have different renders with different terminals. And it does take by
> surprise the newbye.

I understand that new users have unreasonable expectations :-)

The fact remains that there is a huge divide between the essentially
infinite resolution vector-based terminals like postscript, emf, svg,
pdf, and the pixel-based terminals like x11 and png.

The same sort of divide exists with regard to optimal color choice,
where output destined for a physical printer wants different colors
than output destined for display on a screen.

If you truly need to compose a postscript figure accurately, there
is no substitute for using the postscript terminal itself. Trying to
emulate it exactly in x11 is an unreasonable goal, particularly if it
comes at the cost of the legibility of the screen display.=20
We should optimize the x11 settings so that they give the best
appearance on an actual X display.

If I want to end up with an *.eps figure, I preview drafts with
	set term post eps color solid
	set output '| gv:-'
If I want to end up with a *.png figure, I preview drafts with
	set term png
	set output '| display png:-'
and so on.

This is always going to give better control than fiddling with
plot elements in x11 and then hoping they come out the
same on another terminal type. =20

In the run-up to version 4.0 we made an effort to bring terminals
into better agreement for the first 8 or 12 line and point types
(I forget exactly what the upper limit was).  If we missed some
terminals, then certainly let's fix that.  But many terminal types
only *have* 8 linetypes, so I think asking for consistency out to
the 14th or 15th is not realistic.

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

> On Monday 27 February 2006 11:40 am, Ga=EBl Varoquaux wrote:
>> On Mon, Feb 27, 2006 at 10:05:11AM -0800, Ethan Merritt wrote:
>> > Better to have fewer
>> > symbols that are mutually distinguishable than to cycle through
>> > symbols that are confusingly similar.
>>
>>     Well, I see your point but I actually think it is annoying to
>> have different renders with different terminals. And it does take by
>> surprise the newbye.
>
> I understand that new users have unreasonable expectations :-)
>
> The fact remains that there is a huge divide between the essentially
> infinite resolution vector-based terminals like postscript, emf, svg,
> pdf, and the pixel-based terminals like x11 and png.

In fact, such a distinction may tend to disappear, because most of the
work on pixel-based applications can be done through libraries which
support subpixel-accuracy, which is related to antialiasing. This provide=
s
the ability to have satisfying outputs on pixel-based surfaces even for
non-interger coordinates (with some restrictions of course).

For example, I can draw a pentagon as 14th and 15th symbols with the
wxWidgets terminal. I've not done it because my basis was the X11
terminal.

> The same sort of divide exists with regard to optimal color choice,
> where output destined for a physical printer wants different colors
> than output destined for display on a screen.

That's another problem, but we could for example choose the intersection
of the acceptable colors of both output systems.

Timoth=E9e

>>     Well, I see your point but I actually think it is annoying to
>> have different renders with different terminals. And it does take by
>> surprise the newbye.
>
> I understand that new users have unreasonable expectations :-)

Nowadays, they are reasonable. The resolution of output devices gets better 
and better.

> into better agreement for the first 8 or 12 line and point types
> (I forget exactly what the upper limit was).  If we missed some
> terminals, then certainly let's fix that.  But many terminal types
> only *have* 8 linetypes, so I think asking for consistency out to
> the 14th or 15th is not realistic.

A typical usage for these symbols is to plot curve with just few symbols, 
but big! You have even made a patch taking symbol size from datafile.

I propose we have the first 16 (i.e. until nb 15) the same. If it is 
(easily) possible, then let's support it. (An ideal case is to have all of 
them the same, of course...)

---
PM

Petr Mikulik wrote:
>> into better agreement for the first 8 or 12 line and point types
>> (I forget exactly what the upper limit was).  If we missed some
>> terminals, then certainly let's fix that.  But many terminal types
>> only *have* 8 linetypes, so I think asking for consistency out to
>> the 14th or 15th is not realistic.
> 
> 
> A typical usage for these symbols is to plot curve with just few 
> symbols, but big! You have even made a patch taking symbol size from 
> datafile.
> 
> I propose we have the first 16 (i.e. until nb 15) the same. If it is 
> (easily) possible, then let's support it. (An ideal case is to have all 
> of them the same, of course...)

It would be nice to give names to the symbols so that either the name or the number can be used.  For example:

plot sin(x) with points square
plot sin(x) with points triangle

instead of

plot sin(x) with points 4
plot sin(x) with points 8

Or maybe even replace "points" with the name, so

plot sin(x) with squares
plot sin(x) with triangles

Now the array of names should be printed via "help set style points"

<usual doc>

Translations are:

1  - pluses
2  - crosses
3  - stars (or whatever that thing is)
4  - squares
5  - filledsquares
   - solidsquares
6  - circles
7  - (you're right Ethan, these things are hard to tell apart) dots
8  - triangles
   - uptriangles
9  - filledtriangles
   - solidtriangles
   - filleduptriangles
   - soliduptriangles
10 - downtrianges
11 - filleddowntriangles
   - soliddowntriangles
12 - diamonds
13 - filleddiamonds

or something like that.

[This next part is a joke, for all the non-americans out there on the list...]

We could then have a special edition Lucky Charms version of gnuplot for which there are symbols like

plot sin(x) with blue diamonds
plot cos(x) with yellow moons
plot tan(x) with green clovers

[... Sorry, I couldn't resist.]

Dan

On Monday 27 February 2006 11:58 pm, Daniel J Sebald wrote:
> 
> It would be nice to give names to the symbols so that either the name or the number can be used.  For example:
> 
> plot sin(x) with points square
> plot sin(x) with points triangle
> 
> instead of
> 
> plot sin(x) with points 4
> plot sin(x) with points 8

You can do that yourself, simply by creating an 
initialization file that contains

  # Pre-define some point styles
  square = 4
  triangle = 8

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

> It would be nice to give names to the symbols so that either the name or the 
> number can be used.  For example:

I like this idea!

The terminology could be the same as in LaTeX (e.g. amssymb).

> plot sin(x) with blue diamonds
> plot cos(x) with yellow moons
> plot tan(x) with green clovers

Yes, it's more cryptic nowadays, but works ...
     plot sin(x) with points lc rgb "green" pt 7

Hmm but it takes some time to find this sequence somewhere in docs ... 
shouldn't it go to 'help colors'?

---
PM

[Forgot to CC: the list on this...]

Daniel J Sebald wrote:
> Hans-Bernhard Br=F6ker wrote:
>=20
>> Daniel J Sebald wrote:
>>
>>> It would be nice to give names to the symbols so that either the name=
=20
>>> or the number can be used.  For example:
>>>
>>> plot sin(x) with points square
>>> plot sin(x) with points triangle
>>>
>>> instead of
>>>
>>> plot sin(x) with points 4
>>> plot sin(x) with points 8
>>
>>
>>
>> This proposal may seem charming,
>=20
>=20
> You aren't riffing off my Lucky Charms humor, are you?  :-)
>=20
>> but neglects the well-considered reasons why gnuplot uses numbered=20
>> point and line types instead of named ones.  The question that this=20
>> fails to answer is: what is a terminal driver supposed to do if I=20
>> request a named point type that it simply doesn't have?  Throw a=20
>> tantrum, commit seppuku, read my mind, or what?
>=20
>=20
> Read the user's mind... I'll get working on that patch right now.
>=20
> Well, of course there is that matter to deal with.  There may be more=20
> than one way of addressing this, but ultimately it would mean gracefull=
y=20
> substituting symbols; and in a unique way.  (Don't want to substitute=20
> with a symbol that is used on the plot already.)
>=20
> One method would be for gnuplot to have a fixed name to number mapping=20
> as I showed in my previous email.  Then inside the terminal driver is=20
> another array of translations.  For example to gnuplot the square might=
=20
> be #4, but the internal table for the terminal driver looks up array=20
> offset 4 and finds that it is supposed to use #6 for its library call. =
=20
> Something like that.  Then there might be an array for substitutes if=20
> the terminal driver doesn't have the square symbol.  It might issue a=20
> warning (just the first time) "Do not have 'square' symbol, substitutin=
g=20
> with 'Maltese cross'".  I suppose a table of strings would need to be=20
> saved for that... which brings me to the second method.
>=20
> Dan
>=20

--=20

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

On Monday 27 February 2006 12:41 pm, Timoth=C3=A9e Lecomte wrote:
> > On Monday 27 February 2006 11:40 am, Ga=C3=ABl Varoquaux wrote:
> >> On Mon, Feb 27, 2006 at 10:05:11AM -0800, Ethan Merritt wrote:
> >> > Better to have fewer symbols that are mutually distinguishable
> >> > than to cycle through  symbols that are confusingly similar.
> >>
> >>     Well, I see your point but I actually think it is annoying to
> >> have different renders with different terminals.
>
> In fact, such a distinction may tend to disappear, because most of
> the work on pixel-based applications can be done through libraries
> which support subpixel-accuracy, which is related to antialiasing.

It is true that I am very impressed by the crisp font rendering in the
wxWidgets terminal as compared to straight x11.  But that only
extends so far, and not everyone sits in front of a huge monitor.

Have a look at the postscript test image as displayed through
ghostview or gv on a 1024x768 X display.  Do you really think that point
types 14 and 15 are distinguishable from 6 and 7 without enlarging
the local region by a factor of 8 or so?   A pentagon is just too=20
similar to a circle.

If there is a compelling case for having a consistent set of 16
point symbols,  I'd suggest we  start by considering what other
symbols might be used for the last two, rather than pentagons.
=E2=9C=AB  A star (Unicode U+272B)?  =20
=E2=9C=BF  A flower (Unicode U+273F)? =20
=E2=9C=A0  A Maltese cross (Unicode U+2720)?

In fact, it might be a good idea in general to pick symbols that
are present in a scalable unicode font.  That would allow more
terminals to get the improved antialiasing/sub-pixel hinting
benefits that I expect will continue to be added to font rendering
libraries.

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

> On Monday 27 February 2006 12:41 pm, Timoth=C3=A9e Lecomte wrote:
>> > On Monday 27 February 2006 11:40 am, Ga=C3=ABl Varoquaux wrote:
>> >> On Mon, Feb 27, 2006 at 10:05:11AM -0800, Ethan Merritt wrote:
>> >> > Better to have fewer symbols that are mutually distinguishable
>> >> > than to cycle through  symbols that are confusingly similar.
>> >>
>> >>     Well, I see your point but I actually think it is annoying to
>> >> have different renders with different terminals.
>>
>> In fact, such a distinction may tend to disappear, because most of
>> the work on pixel-based applications can be done through libraries
>> which support subpixel-accuracy, which is related to antialiasing.
>
> It is true that I am very impressed by the crisp font rendering in the
> wxWidgets terminal as compared to straight x11.  But that only
> extends so far, and not everyone sits in front of a huge monitor.
>
> Have a look at the postscript test image as displayed through
> ghostview or gv on a 1024x768 X display.  Do you really think that poin=
t
> types 14 and 15 are distinguishable from 6 and 7 without enlarging
> the local region by a factor of 8 or so?   A pentagon is just too
> similar to a circle.

Hum... I am running on a laptop with a 1024x768 dispay, and if I find tha=
t
in the postscript test image those points are pretty well distinguishable
! Have you turned on gv antialiasing ? (State->Antialias)

> If there is a compelling case for having a consistent set of 16
> point symbols,  I'd suggest we  start by considering what other
> symbols might be used for the last two, rather than pentagons.
> =E2=9C=AB  A star (Unicode U+272B)?
> =E2=9C=BF  A flower (Unicode U+273F)?
> =E2=9C   A Maltese cross (Unicode U+2720)?
>
> In fact, it might be a good idea in general to pick symbols that
> are present in a scalable unicode font.  That would allow more
> terminals to get the improved antialiasing/sub-pixel hinting
> benefits that I expect will continue to be added to font rendering
> libraries.

Interesting idea, but the positionning of a font character is not very
easy in general (as for me, I had to fight with pango)...

Timoth=E9e

Thread: x11 point symbols

A portable, multi-platform, command-line driven graphing utility

gnuplot-beta