|
From: Ethan A M. <sf...@us...> - 2015-04-20 20:08:13
|
On Sunday, 19 April, 2015 23:08:17 Daniel J Sebald wrote: > I stepped through the demos to see what is new and test whether a change > I made affected anything. Below is a list of items that seem like > bugs/flaws compared to what I recall of the demos from years ago. I > haven't investigated any of these issues. Should we break these up into > bug reports somehow? > > Dan > > > random.dem: > (Clarification, this is only for Qt, x11 looks as I remember) > Lattice test for random numbers: blank (or points are single pixel > which I can't see amongst the dust on my monitor) > Lattice test for random numbers: blank > Gaussian 3D cloud of 3000 random samples: blank Yeah the default size of "dots" is pretty small. > scatter.dem: > Hit return to continue (5) > "scatter.dem", line 45: warning: Cannot contour non grid data. > Please use "set dgrid3d". I thought this was intentional? Not sure. > pm3d.dem: > (Let me clarify the following: all of these cases are for the Qt > terminal, > the x11 terminal has the file name front-most in the plot) > Datafile with different nb of points in scans; pm3d flush begin: file > name is behind the plot element (reads 'gle.dat') > Datafile with different nb of points in scans; pm3d flush center: > file name is behind the plot element (reads 'dat') > Datafile with different nb of points in scans; pm3d flush scans: file > name is obscured by the plot element > Datafile with different nb of points in scans; pm3d ftriangles flush > begin: file name is obscured by the plot element > Datafile with different nb of points in scans; pm3d ftriangles flush > center: file name is obscured by the plot element > Datafile with different nb of points in scans; pm3d ftriangles flush > end: file name is obscured by the plot element > Using interpolate with datafile; pm3d map interpolate 2,1: file name > is behind the plot element (reads 'gle.dat') > Using interpolate with datafile; pm3d map ftriangles interpolate > 10,1: name is obscured by the plot element That has always been the documented behaviour. The default is to draw the key first, which means it can be obscured by the plot elements. Version 4.something introduced an option "set key opaque" that redraws the key legends on top of the plot elements after blanking out the key box. > color lines: 'splot sin(y)/(y) with lines palette': The color bar > text goes off the window screen. I see that quite often and don't > recall this from years back...maybe font is bigger Not for me, but as you say it may depend on the font size. > heatmaps.dem > Heat Map generated from a file containing Z values only: blank, color > bar correct (this is only for Qt terminal, x11 looks good) > Compare 'image' and 'image pixels' mode: On my system, there are > white spaces between pixels (this is only for Qt terminal, x11 looks > good, I think I've encountered this before as a graphics driver > implementation of OpenGL (Mesa) issue) The artifactual introduction of white lines between fill areas has been a recurring problem for many of the terminals. It was, for example, a known problem with ghostscript - so any of the terminal output viewed in a ghostscript-based viewer would suffer from this. The artifact did not appear when the same file was printed or inspected in a different viewer. The artifact in Qt is obviously not due to ghostscript bugs, but it's probably the same sort of thing. > > hypertext.dem > Sweet! > While the Qt terminal has yellow filled circle with slightly darker > yellow/brown outline, the x11 terminal has yellow filled circles with > black outline and a black dot at the center of each circle (not the best > looking circle either, but that's x11's problem, I guess). Pretty sure that difference is just the effect of anti-aliasing. > Image Formats > As with 3d color surfaces, a color box may be added to the plot: > blank, color box goes off edge of screen (Appears to be Qt only) > Matrix binary data (gnuplot binary) translated: the box around the > key extends so far to the left, wish that font-size issue could be fixed > somehow > > The two images after "End of image demo...": can't see key amongst > black background > > Same thing in 3D mode (First column contains various odd values): > blank and only two borders visible > 3D image with pixel value in 4th column: blank and only two borders > visible > > ellipses_style.dem > Four-column form: x y major_diameter: The _d of two "diameter"s is > treated as subscript and doesn't read easily > Five-column form: The _d of two "diameter"s is treated as subscript > and doesn't read easily This is a consequence of the version 5 switch to enabling enhanced text by default. The "set title" command should be marked "noenhanced" in this demo. (now fixed in CVS). There may be other similar examples in the demo set. > key.dem > Key (<manual> vert left top): The plot border appears to be the > top-most element, while all other plot elements appear behind the key. > I don't recall this from the past. > > rectangle.dem > There are the following differences between Qt temrinal and x11 terminal: > Qt: The rectangle labeled "There should be a clipped rectangle here" > has a white fill background > x11: The said rectangle has no white fill, just the biege of the plot > showing through > Qt: The hashmark fill pattern box from (2,-3) to (0,-2) has no > background (biege shows through) > x11: Said pattern box has a white fill background showing through the > hash pattern Not sure what is going on here. Note that the x11 terminal doesn't do transparency, but in this case the result is opposite to what I would have expected. |