gnuplot-beta

Peculiarities in demo plots

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

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

scatter.dem:
Hit return to continue (5)
          "scatter.dem", line 45: warning: Cannot contour non grid data. 
Please use "set dgrid3d".

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
   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

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)

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).

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

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

Re: Peculiarities in demo plots

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

Forgot one:

imageNaN.dem
   Treatment of missing/undefined/NaN/Inf data: Qt and x11 plots look 
similar except for first column.
              Qt: (top to bottom) black, yellow, white, blue, white, blue
              x11: (top to bottom) black, yellow, black, blue, black, blue
   image from non-matrix data: The x11 plot has a black pixel left, 
second from top so the text "NaN should appear as background" is not 
visible.
   negative values mapped to log-scale colorbar: Same sort of thing for 
x11, the "Negative values become NaN..." is not visible.


On 04/19/2015 11:08 PM, 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
>
> scatter.dem:
> Hit return to continue (5)
>            "scatter.dem", line 45: warning: Cannot contour non grid data.
> Please use "set dgrid3d".
>
> 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
>     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
>
> 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)
>
> 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).
>
> 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
>
> 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
>
>
> ------------------------------------------------------------------------------
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> Develop your own process in accordance with the BPMN 2 standard
> Learn Process modeling best practices with Bonita BPM through live exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

-- 

Dan Sebald
email: daniel(DOT)sebald(AT)ieee(DOT)org
URL: http://www(DOT)dansebald(DOT)com

Re: Peculiarities in demo plots

[sfeam <sf...@us...>]

On Sunday, 19 April 2015 11:51:22 PM Daniel J Sebald wrote:
> Forgot one:
> 
> imageNaN.dem
>    Treatment of missing/undefined/NaN/Inf data: Qt and x11 plots look 
> similar except for first column.
>               Qt: (top to bottom) black, yellow, white, blue, white, blue
>               x11: (top to bottom) black, yellow, black, blue, black, blue
>    image from non-matrix data: The x11 plot has a black pixel left, 
> second from top so the text "NaN should appear as background" is not 
> visible.
>    negative values mapped to log-scale colorbar: Same sort of thing for 
> x11, the "Negative values become NaN..." is not visible.

Right. That's the point of having the demos - they serve as unit tests
for the various code features.  In this case it shows that the x11 terminal
does not handle NaN in image data optimally.  That's at least partly because
the x11 terminal doesn't handle transparency, so there is not the option
of mapping NaN to "all-transparent".

The PostScript terminal exhibits the same deficiency.
In both cases the terminal is just showing it's age.
The newer options (qt/cairo) are more capable.

	Ethan



> 
> 
> On 04/19/2015 11:08 PM, 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
> >
> > scatter.dem:
> > Hit return to continue (5)
> >            "scatter.dem", line 45: warning: Cannot contour non grid data.
> > Please use "set dgrid3d".
> >
> > 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
> >     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
> >
> > 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)
> >
> > 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).
> >
> > 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
> >
> > 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
> >
> >
> > ------------------------------------------------------------------------------
> > BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> > Develop your own process in accordance with the BPMN 2 standard
> > Learn Process modeling best practices with Bonita BPM through live exercises
> > http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
> > source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> >
> 
> 

Re: Peculiarities in demo plots

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

On 04/20/2015 12:02 AM, sfeam wrote:
> On Sunday, 19 April 2015 11:51:22 PM Daniel J Sebald wrote:
>> Forgot one:
>>
>> imageNaN.dem
>>     Treatment of missing/undefined/NaN/Inf data: Qt and x11 plots look
>> similar except for first column.
>>                Qt: (top to bottom) black, yellow, white, blue, white, blue
>>                x11: (top to bottom) black, yellow, black, blue, black, blue
>>     image from non-matrix data: The x11 plot has a black pixel left,
>> second from top so the text "NaN should appear as background" is not
>> visible.
>>     negative values mapped to log-scale colorbar: Same sort of thing for
>> x11, the "Negative values become NaN..." is not visible.
>
> Right. That's the point of having the demos - they serve as unit tests
> for the various code features.  In this case it shows that the x11 terminal
> does not handle NaN in image data optimally.  That's at least partly because
> the x11 terminal doesn't handle transparency, so there is not the option
> of mapping NaN to "all-transparent".
>
> The PostScript terminal exhibits the same deficiency.
> In both cases the terminal is just showing it's age.
> The newer options (qt/cairo) are more capable.
>
> 	Ethan

Are we talking 100% transparent "pixel"?  Or partially transparent?

I've not worked with any of the Qt QGraphicsItem classes, but I'm 
wondering if this QGraphicsPixmapItem class is handling images as a 
collective of pixels, as opposed to an image of data that is sent to a 
driver.  That might explain the slowness of the Qt terminal.  Qt is much 
slower than x11 when working with the image data--a factor of five or more.

In other words, the QGraphicsItem class might be similar to the failsafe 
mode of x11, as far as its operation is concerned--I'm assuming failsafe 
is where an image is created by drawing squares on the canvas.

For that example, if I turn on failsafe mode, i.e.,

plot $DATA with image failsafe

that example with "NaN should appear as background" and "Negative values 
become NaN with a log-scale color mapping" looks similar in x11 and Qt 
terminals.  In fact, shrinking down the image I can see in both cases 
that "NaN should appear as background" is actually in front of the 
pixmap while "Negative values become NaN with a log-scale color mapping".

I'm fine with the demo, but now that I understand it I don't see the 
terminal type as being highly responsible for the feature.  (Partial 
transparency is a different issue.  That's something more significant. 
Could probably do alpha-blending in X11, but I don't think anyone wants 
to tackle that.)  The "failsafe" option is somewhat vague.  Given what I 
suspect about the image being actually drawn with individual rectangles 
(something that "image" defaults to when cast into a 3D 
non-perpendicular view), it might have been nicer to force this mode 
with a different type, say "pixmap" as opposed to "image".

I'm not too quick to dismiss x11 terminal.  Yes, I know maintenance is 
an issue, and alpha blending is missing, antialiasing for nice lines is 
missing, etc.  But it wouldn't surprise me if ultimately Qt terminal 
(i.e., QGraphicsItem) is using X11 in some form.

Dan

Re: Peculiarities in demo plots

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

On 04/20/2015 02:00 AM, Daniel J Sebald wrote:

> In other words, the QGraphicsItem class might be similar to the failsafe
> mode of x11, as far as its operation is concerned--I'm assuming failsafe
> is where an image is created by drawing squares on the canvas.
>
> For that example, if I turn on failsafe mode, i.e.,
>
> plot $DATA with image failsafe
>
> that example with "NaN should appear as background" and "Negative values
> become NaN with a log-scale color mapping" looks similar in x11 and Qt
> terminals. In fact, shrinking down the image I can see in both cases
> that "NaN should appear as background" is actually in front of the
> pixmap while "Negative values become NaN with a log-scale color mapping".
>
> I'm fine with the demo, but now that I understand it I don't see the
> terminal type as being highly responsible for the feature. (Partial
> transparency is a different issue. That's something more significant.
> Could probably do alpha-blending in X11, but I don't think anyone wants
> to tackle that.) The "failsafe" option is somewhat vague. Given what I
> suspect about the image being actually drawn with individual rectangles
> (something that "image" defaults to when cast into a 3D
> non-perpendicular view), it might have been nicer to force this mode
> with a different type, say "pixmap" as opposed to "image".

Has anyone put more thought into this failsafe option?  I don't think it 
is urgent to change, but I do think in the long run the failsafe option 
would be better as its own plot type, e.g., pixmap.  It's more 
distinctive that way.  In other words, pixmap and image would have the 
same underlying construction but the difference would be that "pixmap" 
is assured to be pixel-based in the sense that NAN can remove the 
pixels.  "image" would only be pixel based in the case there is no 
support for images (2D/3D) in the terminal.  The point is to attempt to 
use more efficient image capabilities when possible with "image".

Making failsafe (i.e., pixmap) a type would also mean an additional 
option variable isn't needed.  Also, more significantly, if hidden 
surfaces ever arise there is a big distinction between treating an image 
as pixels and as a whole image.  Individual pixels treated as simple 
polygons falls naturally into the hidden surface routine, whereas a 
whole image doesn't.  Depth order would be the only thing for obscuring 
the hidden portion of a whole image.

Dan

Re: Peculiarities in demo plots

[sfeam <sf...@us...>]

On Saturday, 16 May 2015 11:43:48 PM Daniel J Sebald wrote:
> On 04/20/2015 02:00 AM, Daniel J Sebald wrote:
> 
> > In other words, the QGraphicsItem class might be similar to the failsafe
> > mode of x11, as far as its operation is concerned--I'm assuming failsafe
> > is where an image is created by drawing squares on the canvas.
> >
> > For that example, if I turn on failsafe mode, i.e.,
> >
> > plot $DATA with image failsafe
> >
> > that example with "NaN should appear as background" and "Negative values
> > become NaN with a log-scale color mapping" looks similar in x11 and Qt
> > terminals. In fact, shrinking down the image I can see in both cases
> > that "NaN should appear as background" is actually in front of the
> > pixmap while "Negative values become NaN with a log-scale color mapping".
> >
> > I'm fine with the demo, but now that I understand it I don't see the
> > terminal type as being highly responsible for the feature. (Partial
> > transparency is a different issue. That's something more significant.
> > Could probably do alpha-blending in X11, but I don't think anyone wants
> > to tackle that.) The "failsafe" option is somewhat vague. Given what I
> > suspect about the image being actually drawn with individual rectangles
> > (something that "image" defaults to when cast into a 3D
> > non-perpendicular view), it might have been nicer to force this mode
> > with a different type, say "pixmap" as opposed to "image".
> 
> Has anyone put more thought into this failsafe option?  I don't think it 
> is urgent to change, but I do think in the long run the failsafe option 
> would be better as its own plot type, e.g., pixmap.  It's more 
> distinctive that way. 

I may be overly influenced by knowing what's underneath the hood,
but I don't see it that way.  The original failsafe option was purely
an internal accommodation for terminals that didn't support 
term->image().  The core code for drawing images could test for whether
the terminal had dedicated support, and if not it could fall back to 
the failsafe mode.   It turned out that for certain purposes it
was useful to force that same pixel-by-pixel mode on demand even for
terminals that do support term->image().  For instance svg applies
color-smoothing to images, so if you want a clean heatmap it is better
to use "with image pixels".

   http://gnuplot.sourceforge.net/demo_svg_5.0/heatmaps.html

The NaN business is just a distraction.  It is nice to have some
well-defined behaviour in the presence of NaN, but that depends
on what is possible to support in each terminal's term->image() 
code.  The failsafe code is terminal-independent, so it is easier
to be consistent.   But this is was never driving creation of
the failsafe/fallback/pixels mode, and indeed was only added
later.

	Ethan

> In other words, pixmap and image would have the 
> same underlying construction but the difference would be that "pixmap" 
> is assured to be pixel-based in the sense that NAN can remove the 
> pixels.  "image" would only be pixel based in the case there is no 
> support for images (2D/3D) in the terminal.  The point is to attempt to 
> use more efficient image capabilities when possible with "image".
> 
> Making failsafe (i.e., pixmap) a type would also mean an additional 
> option variable isn't needed.  Also, more significantly, if hidden 
> surfaces ever arise there is a big distinction between treating an image 
> as pixels and as a whole image.  Individual pixels treated as simple 
> polygons falls naturally into the hidden surface routine, whereas a 
> whole image doesn't.  Depth order would be the only thing for obscuring 
> the hidden portion of a whole image.
> 
> Dan

Re: Peculiarities in demo plots

[Ethan A M. <sf...@us...>]

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.