gnuplot-beta — Developers and beta testers of new gnuplot code

Re: odds and ends

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

On Wednesday 10 January 2007 12:58, you wrote:
> 
> Is that conventional in the graphics field?  
> That is, rather than just "transparent" it should be "opaque" 

"transparency" and "opacity" are complementary descriptions of the same property.
  see-through  	   <--------------> solid
transparency	1 <--------------> 0
opacity		0 <--------------> 1

It is most annoying that there is no consistency of whether an "alpha channel"
holds transparency or opacity.  Both conventions are used.

> and "saturation"? 

"Saturation" is one axis of HSV color specification.
It runs from 0 (neutral) to 1 (full color in question)

http://en.wikipedia.org/wiki/Saturation_(color_theory)

Re: odds and ends

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

Ethan Merritt wrote:

> Let me explain the two possibilities I see for a driver that cannot handle transparency.
> 
> (1) Pretend that the style is 
> 	    "fillstyle solid <density>"
>      rather than 
> 	    "fillstyle transparent solid <opacity>"
>      This is what the PostScript driver is doing.  It makes the pair of tori look very pale,
>      because instead of a mostly transparent surface (opacity=30%) it renders a surface
>      that is at most 30% saturated with the fullscale color from the colorbar

Oh, I see now why what I'm looking at is "sort of transparent".


> (2) Ignore the opacity value altogether,  yielding full-scale color with no transparency.
>      I don't think any of the drivers are doing this at the moment, but it would be easy
>      enough to change.

A combination of the two would be fine too, I think.  For the most part, go with (2).  There may be some utility to (1) if it is acceptable to the user.  I would think then that comments like:

"Transparency not available:  reverting to solid"
"Transparency not available:  reverting to density approximation"

(Use a global variable to only print once for a driver.)

Well, is the situation what you are describing in (1) suggesting two different modes?  Is that conventional in the graphics field?  That is, rather than just "transparent" it should be "opaque" and "saturation"?  Then, if one of those don't exist *always* fall back on (2) because the user on his or her own will be able to attempt "saturation" option if "opaque" option didn't work.

> I think that implementing transparency on top of X11 is such a hard problem that it would
> require a whole graphics project in its own right.  And in fact such projects exist. Two
> obvious ones we could use are OpenGL, for which prototype gnuplot drivers have been
> explored, and  wxWidgets, for which we now have a fully developed driver. 
> 
> So as I see it, the current best answer to "How can I use transparency with x11?"
> is  "Use the wxt terminal"!

That's certainly an acceptable solution with me.

Dan

Re: odds and ends

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

On Wednesday 10 January 2007 03:39, Daniel J Sebald wrote:
> Ethan A Merritt wrote:
> > On Tuesday 09 January 2007 19:19, Daniel J Sebald wrote:
> > 
> >> The demo "transparent_solids.dem" produces color differences
> >> between X11 and PostScript.
> > 
> > 
> > Well, since neither x11 nor postscript support transparency... 
> 
> > Should non-supporting terminals fall back to something in particular if transparency is not possible?
> > What, exactly?
> 
> Falling back on something is fine, but it should be consistent across terminals.  

Let me explain the two possibilities I see for a driver that cannot handle transparency.

(1) Pretend that the style is 
	    "fillstyle solid <density>"
     rather than 
	    "fillstyle transparent solid <opacity>"
     This is what the PostScript driver is doing.  It makes the pair of tori look very pale,
     because instead of a mostly transparent surface (opacity=30%) it renders a surface
     that is at most 30% saturated with the fullscale color from the colorbar

(2) Ignore the opacity value altogether,  yielding full-scale color with no transparency.
     I don't think any of the drivers are doing this at the moment, but it would be easy
     enough to change. 

> I would think in this case that if x11 behaved the same as PostScript 
> (i.e., the same color elements,  but just not the transparency) would be fine.  

That was the intent.  There may be a bug.

> Were you trying to implement transparency in X11?   
> Or will that come once the alpha-channel mechanics are there?   

I think that implementing transparency on top of X11 is such a hard problem that it would
require a whole graphics project in its own right.  And in fact such projects exist. Two
obvious ones we could use are OpenGL, for which prototype gnuplot drivers have been
explored, and  wxWidgets, for which we now have a fully developed driver. 

So as I see it, the current best answer to "How can I use transparency with x11?"
is  "Use the wxt terminal"!

no mirroring

[Petr M. <mi...@ph...>]

I've just noticed that http://www.gnuplot.info/ is not mirroring the 
contents of http://gnuplot.sourceforge.net/. Who has the rights to fix it?

---
PM

Re: odds and ends

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

Daniel J Sebald wrote:
> A PDF file is corrupted once an exception occurs, so can't get back from that.  However, there is a way to lessen the font problems to returning a -1 rather than causing an exception:
> 
>     PDF_set_parameter(myPDF, "fontwarning", "false");
> 
> Almost works, but not quite...hmm

Got it...

Timothée asked a question about fonts

Courier, Courier-Bold, Courier-Oblique, Courier-BoldOblique,
Helvetica, Helvetica-Bold, Helvetica-Oblique, Helvetica-BoldOblique,
Times-Roman, Times-Bold, Times-Italic, Times-BoldItalic,
Symbol, ZapfDingbats

not all having to be declared as builtin.  The answer is, I don't know.

Dan

Re: odds and ends

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

Daniel J Sebald wrote:

> In the PDFlib doc, there is a form of exception handling for C of this variety:
> 
> 	PDF_TRY(myPDF) {
> 	    font_handle = PDF_findfont(myPDF, PDF_fontNameCur, "builtin", 1);
> 	}
> 	PDF_CATCH(myPDF) {
> 	    fprintf(stderr,"HEY!  I DON'T KNOW THIS FONT!!\n");
> 	    return;
> 	}
> 
> but I'm having no success (may be because I'm stuck back in the "helvetica" missing font mode).

A PDF file is corrupted once an exception occurs, so can't get back from that.  However, there is a way to lessen the font problems to returning a -1 rather than causing an exception:

    PDF_set_parameter(myPDF, "fontwarning", "false");

Almost works, but not quite...hmm

Dan

Re: odds and ends

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

Ethan A Merritt wrote:
> On Tuesday 09 January 2007 19:19, Daniel J Sebald wrote:
> 
>> The demo "transparent_solids.dem" produces color differences
>> between X11 and PostScript.
> 
> 
> Well, since neither x11 nor postscript support transparency... Do you
> think the demo should refuse to run?

Do we have the mechanism to do that?  Saying that a terminal doesn't support transparency is fine with me.

> Should non-supporting terminals
> fall back to something in particular if transparency is not possible?
> What, exactly?

Falling back on something is fine, but it should be consistent across terminals.  I would think in this case that if x11 behaved the same as PostScript (i.e., the same color elements, but just not the transparency) would be fine.  Were you trying to implement transparency in X11?  Or will that come once the alpha-channel mechanics are there?

If non-supporting terminals fall back, a warning message seems pertinent so that the (new) user realizes that what they are looking at isn't transparent.


>> Also, somehow with the tori example I ended up with "view" and
>> "scale" coordinates in a huge sans seriff font... Here's how I did
>> it.  Run gnuplot and type:
>> 
>> load 'transparent_solids.dem' load 'transparent_solids.dem'
>> 
>> On the second load of the demo the first graph has the font too
>> large for the coordinates.
> 
> 
> Hmm, yes. That does seem to be a bug. I can't see why it would have
> anything in particular to do with transparency, though. Probably just
> a case of the last thing in the previous plot being drawn with a
> large font, and the coordinate-drawing routine is missing a font
> reset.

That is what I'm imagining.

> Same thing again.
> 
> You need to configure the pdflib font installation. On my machine
> it's in /usr/local/share/pdflib.upr You can put aliases for fonts
> that are not an exact match. For example, frscript=z003034l.afm
> (Chancery Italic) is a decent substitute for the font used in the
> Kuen's surface demo

OK, I wasn't aware of the pdflib.upr file, thanks.

I've found the PDF file describing the library documentation.  Good documentation, just had to find it.

I used ZapfDingbats.afm and get this warning:

PDFlib warning (ignored): [2504] PDF_findfont: Use 'builtin' encoding instead of 'iso8859-1' for font 'WingDings'

but I manage to get some output at least (stars instead of smileys and clubs instead of thumbs down).  At least PDFlib is a little more forgiving on this.

I see the following are directed by pdf.trm to use internal fonts of the PDF viewer:

    if ( (strcmp(PDF_fontNameCur,"Symbol") == 0) ||
	 (strcmp(PDF_fontNameCur,"ZapfDingbats") == 0) ) {

which could expanded:

Courier, Courier-Bold, Courier-Oblique, Courier-BoldOblique,
Helvetica, Helvetica-Bold, Helvetica-Oblique, Helvetica-BoldOblique,
Times-Roman, Times-Bold, Times-Italic, Times-BoldItalic,
Symbol, ZapfDingbats

In the PDFlib doc, there is a form of exception handling for C of this variety:

	PDF_TRY(myPDF) {
	    font_handle = PDF_findfont(myPDF, PDF_fontNameCur, "builtin", 1);
	}
	PDF_CATCH(myPDF) {
	    fprintf(stderr,"HEY!  I DON'T KNOW THIS FONT!!\n");
	    return;
	}

but I'm having no success (may be because I'm stuck back in the "helvetica" missing font mode).

Dan

odds and ends

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

I noticed that molecule.dem is still not in all.dem, if Ethan wanted that one in the list.  (The second image would make a good animation to see both top and bottom of the hyperplane border.)

The demo

  set title "set pm3d corners2color c3"

has the text for the color bar off of the plot.  There is enough space to push the sample boxes upward and make more room for the color bar.

The demo "transparent_solids.dem" produces color differences between X11 and PostScript.  The interlocking tori example is all one color in X11, blueish purple.  In PostScript, the color fades from white to light red.  The Kuen's surface in X11 is grayscale where every element is the same shade.  In PostScript, it comes multicolored.

Also, somehow with the tori example I ended up with "view" and "scale" coordinates in a huge sans seriff font... Here's how I did it.  Run gnuplot and type:

load 'transparent_solids.dem'
load 'transparent_solids.dem'

On the second load of the demo the first graph has the font too large for the coordinates.  (There should be no way of controling the coordinate fonts, is that right?)

For 'transparent.dem'.  The font I see in the key is some strange glyph and different between X11 and PostScript.  (I've not followed font issues closely.)  The lines in the density function for red and yellow do not show up in PostScript.  The overlay of the third plot in this demo doesn't work the same for PostScript either.

The PDF terminal crashes gnuplot on demo "transparent_solids.dem".

  Hit return to continue
  PDFlib exception (fatal): [2516] PDF_findfont: Metrics data for font 'frscript' not found

Problems here as well:

********************** file stringvar.dem *********************
Hit return to continueHit return to continueHit return to continueHit return to continuePDFlib exception (fatal): [2516] PDF_findfont: Metrics data for font 'WingDings' not found


Dan

Re: Version 4.2 release plans

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

On Tuesday 09 January 2007 16:42, Daniel J Sebald wrote:
> Ethan,
> 
> Could we add the patch under bug
> 
> [ 1612502 ] Image in 3D plot has incorrect viewbox on X11 terminal
> 
> to the 4.2 branch and CVS before release?

That is far more code than I want to add.
Can you instead find a 1-line fix that disables the viewbox optimization,
since it doesn't work?

	Ethan 

> This fixes a problem without much consequence. 

I think "fix" is not the right word.  "Applies enough force to cram
the round image/peg into the square hole" is more like it.

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

Re: libgd update in the works

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

On 1/9/07, Ethan Merritt wrote:
> On Monday 08 January 2007 00:10, Mojca Miklavec wrote:
> > If that is meant by color gradients: I would really like to see if 3D
> > plots could be drawn with (triangles) with a different color in each
> > edge and smooth color transition between them, so that the plot
> > wouldn't need a 100x100 grid to look realistic.
> >
> > I've been just playing with smooth shading in PS and PDF (and a
> > metapost interface for drawing it). It's a bit complicated to do, but
> > doable (with quite some effort).
>
> I am led to believe that we could define gradient-fill operations
> directly in PDF, using the PDF_shading_pattern() routine in pdflib.
> However, the documentation seems to say that you are limited
> to a one-axis gradient (e.g. changes only along x) or a radial
> gradient.  I am not sure how one would best adapt either of these
> to the task of filling a triangle/rectangle with target colors specified
> at the vertices.  The same is true for SVG.

http://partners.adobe.com/public/developer/en/ps/sdk/TN5600.SmoothShading.pdf
(Type 4)

I went exploring and have written a much longer email. And then I
figured out an extremely weird fact. Not only the libraries have a
missing functionality ... not even my PDF viewer (Preview.app, the
main PDF viewer under Mac) is capable of displaying/rendering such
triangles. (Free-Form Gouraud-Shaded Triangle Meshes)

See
      http://www.math.ubc.ca/~cass/graphics/manual/pdf/ch13.ps
      http://www.math.ubc.ca/~cass/graphics/manual/pdf/ch14.pdf
(examples which inspired me to start learning PostScript, and in
particular this sphere)

I only see one sphere on the first page, but there should be two :(

Mojca

small mods to demos

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

I added a couple patches to SourceForge to demos that could also be put in 4.2 branch if wanted.

iterate.dem:  Simple change to the period to make the sinusoid series begin and end on the cycle.

borders.dem:  Add pause -1 to make consistent with all other demos.

Dan

Re: Version 4.2 release plans

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

Ethan A Merritt wrote:
> Unless someone chimes in with a set of new problems, 
> I propose to put out a third and hopefully final release candidate
> next week.  If all goes well, the plan is that the final 4.2 release
> would be identical to -rc3 except for the various versioning tags

Ethan,

Could we add the patch under bug

[ 1612502 ] Image in 3D plot has incorrect viewbox on X11 terminal

to the 4.2 branch and CVS before release?  This fixes a problem without much consequence.

Dan

PS:  I looked tested the latest image demos.  Looks good.  I saw the pun change in the last plot!!  :-)  The thing I notice is the slowness of the color assignment.  If I recall, there is some trial and error in determining the color palette size that could probably be fixed with computing the size outright.  I'll look at that some day.

PPS:  Lot's of new demos!

Re: Magic white space

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

On Tuesday 09 January 2007 13:40, Daniel J Sebald wrote:
> For the latest CVS, documentation is failing to compile
> 
> > The change on 12/10 is that a white space character was removed from 
> > *after* the "6 origin ".
> 
> Anyone have an idea why that might be?  If no one wants to investigate, attached is probably the shortest patch I have and will ever have written.

Not really.  
But I note that the doc2texi.el script only seems to make provision for
5 levels of keywords, whereas this one is at level 6.

terminal problem

[Wei B. <we...@ia...>]

I just downloaded the new version (4.2). Everything looks fine, but x11 is not a
available terminal. The default term is unknown. How come?



Wei Bu                          Tel:  515-294-9614
B37, B39 Spedding Hall                515-294-6895
Iowa State University           e-mail: we...@ia...
Ames, IA 50011                  www.reflec.ameslab.gov

Magic white space

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

For the latest CVS, documentation is failing to compile with the following error:

Wrote /usr/local/src/gnuplot-junk/gnuplot/docs/gnuplot.texi
/bin/sh /usr/local/src/gnuplot-junk/gnuplot/missing --run makeinfo -I. ./gnuplot.texi --no-split --output=gnuplot.info
./gnuplot.texi:10534: Cross reference to nonexistent node `origin' (perhaps incorrect sectioning?).
[snip]
./gnuplot.texi:3082: Cross reference to nonexistent node `origin' (perhaps incorrect sectioning?).
makeinfo: Removing output file `gnuplot.info' due to errors; use --force to preserve.

The solution is a strange one.  Placing a white-space character *after* "6 origin":

Daniel J Sebald wrote:
> Ethan Merritt wrote:

>> Such an underscore appears after many keywords in the file.
>> At a guess, this serves to differentiate entry
>>  3 origin
>>  ? set origin
>> from entry
>>  6 origin
>>  ? binary general keywords origin
> 
> 
> The change on 12/10 is that a white space character was removed from 
> *after* the "6 origin ".
> 
> I'm compiling...

Anyone have an idea why that might be?  If no one wants to investigate, attached is probably the shortest patch I have and will ever have written.

Dan

Re: Please include pie chart option in gnuplot

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

Pie is not top priority.  I've placed an old patch on

http://webpages.charter.net/dsebald/

which comes with less than the usual warranty.  You'll probably have to write and arc drawing routine for any output terminal of interest other than x11.

Dan


Andreas Karlsson wrote:
> Hi,
> 
> To my surprise I have found that gnuplot cannot construct pie charts.
> 
> Yes, I know that some consider pie charts as bad for presenting data, 
> but they are nevertheless used by many people, and some find them useful.
> 
> Could you please include a possibility to construct pie charts in gnuplot?
> 
> Best regards,
> Andreas Karlsson
> 
> 
> 
> 
> 
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 


-- 

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

cannot set terminal X11

[David V. <va...@am...>]

I installed gnuplot Version 4.2 patchlevel rc2 and everything works  
fine except that I cannot set terminal to X11.  When I start gnuplot  
the following appears "Terminal type set to 'unknown' " and set  
terminal command does not show x11 as an option.  I can plot to  
postscript files etc..but not to screen.
David

Re: Vertical centering inconsistency

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

On Monday 08 January 2007 14:35, Hans-Bernhard Br=F6ker wrote:
> m sutton wrote:
>=20
> > I did some investigating.  I found that the X11, CGM and Postscript
> > enhanced will do vertical centering.  PNG (gd), Postscript, and EMF
> > do not do vertical centering.

I think the core code also plays a large role in this.
Here is the top of the routine write_label, in gadgets.c, which
now handles all the labels for both 2D and 3D plots.

    write_label(unsigned int x, unsigned int y, struct text_label *this_lab=
el)
    {
        int htic, vtic;
        int justify =3D JUST_TOP; /* This was the 2D default; 3D had CENTRE=
 */

And indeed, already back in 3.7 days graphics.c wrote labels with JUST_TOP
while graph3d.c did not.

I wonder if various drivers may have added ad-hoc vertical positioning
offsets to make up for the fact that the core routine makes the wrong call.

The enhanced text code, however, does not funnel through write_label.
So it is not so surprising that it may produce different centering results.


> At least by intention, that constitutes a bug in the latter three=20
> drivers.  The wording is not as clear as it could be, but let's see what=
=20
> the applicable documentation in term/README says this about put_text():
>=20
> _put_text(x,y,str)  Called to display text at the (x,y) position,
> while in graphics mode.   The text should be vertically (with respect
> to the text) justified about (x,y).

I'm not sure how to interpret that, given that the choice of
vertical justification is made by core routines, not the terminal drivers.


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

Re: libgd update in the works

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

On Monday 08 January 2007 00:10, Mojca Miklavec wrote:
> On 1/7/07, Ethan A Merrit wrote:
> 
> > Since both gnuplot and libgd are heading towards a significant new
> > release, this is a good time to revisit any long-standing problems
> > with functionality of the gnuplot gif/png/jpeg terminal drivers.
> >
> > It wouldn't hurt to add some wish-list items as well, perhaps taken
> > from our backlog of feature requests.  Support for color gradients
> > comes to mind
> 
> If that is meant by color gradients: I would really like to see if 3D
> plots could be drawn with (triangles) with a different color in each
> edge and smooth color transition between them, so that the plot
> wouldn't need a 100x100 grid to look realistic.
> 
> I've been just playing with smooth shading in PS and PDF (and a
> metapost interface for drawing it). It's a bit complicated to do, but
> doable (with quite some effort).

I am led to believe that we could define gradient-fill operations
directly in PDF, using the PDF_shading_pattern() routine in pdflib.
However, the documentation seems to say that you are limited
to a one-axis gradient (e.g. changes only along x) or a radial
gradient.  I am not sure how one would best adapt either of these
to the task of filling a triangle/rectangle with target colors specified
at the vertices.  The same is true for SVG.

Re: Vertical centering inconsistency

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

m sutton wrote:

> I did some investigating.  I found that the X11, CGM and Postscript
> enhanced will do vertical centering.  PNG (gd), Postscript, and EMF
> do not do vertical centering.

At least by intention, that constitutes a bug in the latter three 
drivers.  The wording is not as clear as it could be, but let's see what 
the applicable documentation in term/README says this about put_text():

_put_text(x,y,str)  Called to display text at the (x,y) position,
while in graphics mode.   The text should be vertically (with respect
to the text) justified about (x,y).  The text is rotated according
to _text_angle and then horizontally (with respect to the text)
justified according to _justify_text.

Now admittedly the term "justified about" is not excessively clear, but 
I always understood this to mean "centered".  Quite a number of routines 
in the gnuplot core also assume that's what it means.  If you go looking 
for term->v_char / 2 a bit, you'll see what I mean.

For a simple, test, look at the output from

	set label 1 "<--- here" at 1,1
	plot x

The head of this "text arrow" is supposed to be exactly on the diagonal 
plotted line.

Re: libgd update in the works

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

On 1/7/07, Ethan A Merrit wrote:

> Since both gnuplot and libgd are heading towards a significant new
> release, this is a good time to revisit any long-standing problems
> with functionality of the gnuplot gif/png/jpeg terminal drivers.
>
> It wouldn't hurt to add some wish-list items as well, perhaps taken
> from our backlog of feature requests.  Support for color gradients
> comes to mind

If that is meant by color gradients: I would really like to see if 3D
plots could be drawn with (triangles) with a different color in each
edge and smooth color transition between them, so that the plot
wouldn't need a 100x100 grid to look realistic.

I've been just playing with smooth shading in PS and PDF (and a
metapost interface for drawing it). It's a bit complicated to do, but
doable (with quite some effort).

Mojca

libgd update in the works

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

By the way,

libgd development has shifted to libgd.org, with Pierre Joye as
lead developer.  

File bug reports and "issues" via   http://bugs.libgd.org

We've been thrashing out issues of transparency and pattern-fill
support as they affect gnuplot, and I've fed in a patch to restore
use of the Adobe Symbol font for enhanced text (it worked in earlier
versions of libgd but is broken in the current libgd 2.0.33).  

Since both gnuplot and libgd are heading towards a significant new
release, this is a good time to revisit any long-standing problems
with functionality of the gnuplot gif/png/jpeg terminal drivers.  

It wouldn't hurt to add some wishlist items as well, perhaps taken
from our backlog of feature requests.  Support for color gradients
comes to mind, as well as embedded comments in the file header.
I've already pointed out that it would be nice to be able to 
specify a preferred character encoding. 

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

Re: Dots - consistency across terminals

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

Petr Mikulik wrote:
>>The postscript and pdf terminals plots dots as a zero length vector
>>using the current linewidth. This means that 
>>	plot <foo> with dots lw 1, <baz> with dots lw 10
>>produces two different dot sizes.
>>
>>Other terminals do not do this. Should they?
> 
> 
> If they do, I would like it. Sometimes one needs "just a bit larger tiny 
> dot".

Would be nice.

Dan

Re: Version 4.2 release plans

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

Ethan A Merritt wrote:
> Unless someone chimes in with a set of new problems, 
> I propose to put out a third and hopefully final release candidate
> next week.  If all goes well, the plan is that the final 4.2 release
> would be identical to -rc3 except for the various versioning tags

I've a few things to do in the next couple days.  After that I'll have time to look at code patches and see if there is any that should go in 4.2.

Dan

Re: Dots - consistency across terminals

[Petr M. <mi...@ph...>]

> The postscript and pdf terminals plots dots as a zero length vector
> using the current linewidth. This means that 
> 	plot <foo> with dots lw 1, <baz> with dots lw 10
> produces two different dot sizes.
> 
> Other terminals do not do this. Should they?

If they do, I would like it. Sometimes one needs "just a bit larger tiny 
dot".

---
PM