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

Re: irreversibly reversing range

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

On Tue, Jul 21, 2009 at 14:39, Thomas Sefzick wrote:
>
> set xrange [] noreverse

Thanks. But shouldn't it change back automatically?

It automatically changes to "reverse" as soon as one uses [more:less],
but doesn't automatically change back.

I mean ...

> show xrange
	set xrange [ * : * ] noreverse nowriteback  # (currently [-10.0000:10.0000] )
> plot [0:10] sin(x)
> show xrange
	set xrange [ * : * ] noreverse nowriteback  # (currently [0.00000:10.0000] )
> plot  sin(x)
# only "currently" changes, but gets restored as soon as one drops
using explicit [:]
> show xrange
	set xrange [ * : * ] noreverse nowriteback  # (currently [-10.0000:10.0000] )
> plot [10:0] sin(x)
> show xrange
	set xrange [ * : * ] reverse nowriteback  # (currently [10.0000:0.00000] )
> plot sin(x)
# in my opinion this should become "noreverse" automatically
# unless someone uses "set xrange [] reverse" by explicitely calling it
> show xrange
	set xrange [ * : * ] reverse nowriteback  # (currently [10.0000:-10.0000] )

I didn't check internals, but maybe a separate variable is needed to
track "current reverse" just as there is "current range" after #.

Mojca

> Mojca Miklavec wrote:
>>
>> Hello,
>>
>> I accidentally used "plot [bigger:smaller]", but when I corrected the
>> mistake, the plotting range didn't restore to the appropriate value.
>> Would it make sense to fix that behaviour?
>>
>> Example:
>>
>> # ok
>> plot [0:10] sin(x)
>> # ok
>> plot [10:0] sin(x)
>> # wrong; plots as [10:0]; "set xrange restore" doesn't help; only "reset"
>> does
>> plot [0:10] sin(x)
>>
>> Thanks,
>>     Mojca

Re: irreversibly reversing range

[Thomas S. <t.s...@fz...>]

set xrange [] noreverse


Mojca Miklavec wrote:
> 
> Hello,
> 
> I accidentally used "plot [bigger:smaller]", but when I corrected the
> mistake, the plotting range didn't restore to the appropriate value.
> Would it make sense to fix that behaviour?
> 
> Example:
> 
> # ok
> plot [0:10] sin(x)
> # ok
> plot [10:0] sin(x)
> # wrong; plots as [10:0]; "set xrange restore" doesn't help; only "reset"
> does
> plot [0:10] sin(x)
> 
> Thanks,
>     Mojca
> 
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge  
> This is your chance to win up to $100,000 in prizes! For a limited time, 
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full
> prize  
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 
> 

-- 
View this message in context: http://www.nabble.com/irreversibly-reversing-range-tp24585446p24586919.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

irreversibly reversing range

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

Hello,

I accidentally used "plot [bigger:smaller]", but when I corrected the
mistake, the plotting range didn't restore to the appropriate value.
Would it make sense to fix that behaviour?

Example:

# ok
plot [0:10] sin(x)
# ok
plot [10:0] sin(x)
# wrong; plots as [10:0]; "set xrange restore" doesn't help; only "reset" does
plot [0:10] sin(x)

Thanks,
    Mojca

Re: mouse pan and zoom

[James R. V. Z. <jr...@co...>]

> Tatsuro MATSUOKA <tma...@ya...> writes:
>
>> I have built wgnuplot with wxt on the cvs trees
>> 2009-07-18  Ethan A Merritt  <merritt@u.washington.edu>
>>
>>	   * src/wxterminal/wxt_gui.cpp src/wxterminal/wxt_gui.h:
>>	   Pass through mouse wheel events from the wxt terminal, so that the new
>>	   pan and zoom works for wxt as well as x11.
>
>   I have confirmed that  pan and zoom using work on wxt but does not work on windows terminal.

Thanks for checking this out.  

In the mean time I've found a simpler approach:

 if (modifier_mask & Mod_Shift) {
    /* scroll left */
    xmin = AXIS_DE_LOG_VALUE(FIRST_X_AXIS,1.1*axis_array[FIRST_X_AXIS].min 
                                          -.1*axis_array[FIRST_X_AXIS].max);
    ymin = AXIS_DE_LOG_VALUE(FIRST_Y_AXIS,axis_array[FIRST_Y_AXIS].min);
    x2min = AXIS_DE_LOG_VALUE(SECOND_X_AXIS,1.1*axis_array[SECOND_X_AXIS].min 
                                            -.1*axis_array[SECOND_X_AXIS].max);
    y2min = AXIS_DE_LOG_VALUE(SECOND_Y_AXIS,axis_array[SECOND_Y_AXIS].min);
    
    xmax = AXIS_DE_LOG_VALUE(FIRST_X_AXIS,.1*axis_array[FIRST_X_AXIS].min 
                                         +.9*axis_array[FIRST_X_AXIS].max);
    ymax = AXIS_DE_LOG_VALUE(FIRST_Y_AXIS,axis_array[FIRST_Y_AXIS].max);
    x2max = AXIS_DE_LOG_VALUE(SECOND_X_AXIS,.1*axis_array[SECOND_X_AXIS].min 
                                           +.9*axis_array[SECOND_X_AXIS].max);
    y2max = AXIS_DE_LOG_VALUE(SECOND_Y_AXIS,axis_array[SECOND_Y_AXIS].max);
    do_zoom(xmin, ymin, x2min, y2min, xmax, ymax, x2max, y2max);
    if (display_ipc_commands()) {
      fprintf(stderr, "scroll left.\n");
    }
 } 

Since this doesn't involve MousePosToGraphPosReal(), it works even for
splot.  I don't know whether this change would affect the other terminals.

I haven't checked in this change because I found a bug: If I plot a
function defined only for certain values of Y, and set logscale Y, and
scroll past the defined region, then it breaks.  E.g.

  set logscale y;set xrange [0:5];set yrange [.01:10];
  splot sqrt(1.02-(1- x)**2 - (1-y)**2)

I haven't diagnosed that problem yet.

        - Jim Van Zandt

Re: [Gnuplot-developers] [ gnuplot-Patches-2558043 ] Qt terminal

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

> >Comment By: Petr Mikulik (mikulik)
> Date: 2009-07-21 02:28
> 
> Message:
> ./configure says:
> 
> Requested 'QtCore >= 4.5' but version of Qtcore is 4.4.3
> Requested 'QtGui >= 4.5' but version of Qtgui is 4.4.3
> Requested 'QtNetwork >= 4.5' but version of Qtnetwork is 4.4.3
> Requested 'QtSvg >= 4.5' but version of Qtsvg is 4.4.3
> 
> Does it really need version 4.5? On my latest OpenSUSE 11.1 the latest is
> libqt4-devel-4.4.3-4.8.2.

Not sure.

> If 4.5 is required, it will take ages before the terminal can be used.
> Could you support other 4.x?

I think 4.5 will be adopted very quickly, at least on the linux side,
if only because of the LGPL licensing.
I have it already on current Mandriva, and it looks like there is support in
Suse 11.1 also:
  http://download.opensuse.org/repositories/KDE:/Qt/openSUSE_11.1/i586/
      libqt4-4.5.2-53.2.i586.rpm 
      libqt4-devel-4.5.2-53.2.i586.rpm 
	etc

 
		Ethan

> ----------------------------------------------------------------------
> 
> Comment By: Jérôme Lodewyck (lodewyck)
> Date: 2009-07-19 08:56
> 
> Message:
> New patch
> 
> - fixes various font problems
> - select background color UI
> - mouse wheel scroll and zoom
> 
> ----------------------------------------------------------------------
> 
> Comment By: Jérôme Lodewyck (lodewyck)
> Date: 2009-07-06 21:42
> 
> Message:
> Here it is.
> 
> ----------------------------------------------------------------------
> 
> Comment By: Ethan Merritt (sfeam)
> Date: 2009-07-06 17:21
> 
> Message:
> Build fails with the new patch, because it does not contain the file
> term/qt.trm
> Oversight when the patch file was created?
> 
> 
> ----------------------------------------------------------------------
> 
> Comment By: Jérôme Lodewyck (lodewyck)
> Date: 2009-07-04 19:21
> 
> Message:
> Here is a new patch. It includes the locale patch, and fixes the dist
> building error. It still needs the separate image tarball.
> About the font problem, I can set the terminal font with 
> set term qt font "times,20"
> Is this not working for you ?
> 
> I would be delighted to have this patch included in CVS. There are a few
> things to settle:
> - The images are taken from the KDE project, and are under the Creative
> Commons Attribution-NonCommercial-NoDerivs 2.5 License. Is it possible to
> include them as such in the gnuplot CVS ?
> - How to submit further development of the terminal ? With new patches, or
>  by continuing on this one ?
> 
> ----------------------------------------------------------------------
> 
> Comment By: Ethan Merritt (sfeam)
> Date: 2009-06-17 05:06
> 
> Message:
> I am inclined to move this patch implementing a Qt terminal  into CVS so
> that it gets wider testing.  Also because I like the terminal :-)
> 
> Is that OK, or did you have more you wanted to work on while it was still
> a separate patchset?
> 
> I have found two things that need attention, but neither would prevent
> testing and initial use:
> 
> 1) I cannot figure out how to select a font.  I can see in the code that
> there is a call to QFont(), but it does not see to do anything.  If I
> replace "Sans" in the source code with a hard-coded alternative, then it
> works.  But passing a font in through the user interface does not work.
> 
> 2) The build targets "make check"  "make distcheck"  and "make dist", 
> used for packaging the source tree for distribution, fail due to some
> problem with the qt targets.  I don't understand what is going on here, but
> I am no expert at all when it comes to the autoconf tools.  
> 
> 
> 
> ----------------------------------------------------------------------
> 
> Comment By: Ethan Merritt (sfeam)
> Date: 2009-06-08 06:25
> 
> Message:
> Here is a patch to fix the encoding problem.
> 
> ----------------------------------------------------------------------
> 
> Comment By: Ethan Merritt (sfeam)
> Date: 2009-06-02 22:59
> 
> Message:
> Locale handling changed between version 4.2 and the CVS version (which will
> become 4.4). What I say now applies to the CVS version.
> 
> For the intended behaviour, see "help set decimal".  If you find that
> something else is happening in practice - that is a bug.
> 
> Here is an outline of how it is supposedly working. Please report any
> observed deviation.
> 
> 1)  The program sets the numeric locale to "C" on entry.  You can confirm
> this by typing "show decimal".  It should report that the decimal separator
> is a period, even if your global locale is such that it would be a comma. 
> 
> 2) You can change the treatment of decimals on input  and output using
> "set decimal locale". Again see "help set decimal" for more information. 
> However, the program  _does not change_ the internal locale setting at this
> point.  It simply remembers your preference.
> 
> 3) When data is read from a file, or formatted for printing on the plot,
> the program temporarily sets the numeric locale to whatever you stored as a
> preference.  When it is done reading or formatting, it sets the locale back
> to "C".  
> 
> 4) As a consequence of (3), the numeric locale should never be anything
> except "C" inside terminal driver code.  Reading data from a file does not
> involve calling a terminal driver at all, and when strings are printed they
> are formatted first and then sent to the terminal driver afterward.
> 
> 
> 
> However, it is believable that some call to a Qt library changes the
> locale setting.  Or the locale setting may not be preserved across the
> fork/exec to start a separate Qt process. I  remember that we had a similar
> problem with the wxt terminal. Here is the ChangeLog entry:
> 
> 2008-03-17  Ethan A Merritt  <merritt@u.washington.edu>
>         * src/wxterminal/wxt_gui.cpp (wxt_init): Restore the locale
> settings
>         for both LC_TIME and LC_NUMERIC, but only after the GTK+ thread
> has
>         finished mangling them.
>         Bug #1916190
> 
> And here is the patch:
> http://gnuplot.cvs.sourceforge.net/viewvc/gnuplot/gnuplot/src/wxterminal/wxt_gui.cpp?r1=1.62&r2=1.63
> 
> The initialization code for the Qt driver may need a similar patch.  
> 
> Or, of course, there may be a bug somewhere else :-)
> 
> 
> ----------------------------------------------------------------------
> 
> Comment By: Jérôme Lodewyck (lodewyck)
> Date: 2009-06-02 21:43
> 
> Message:
> Here is a new patch.
> 
> A new strange bug has appeared. When running gnuplot with the Qt terminal
> in a french local environment, some bugs pop up here and there, such as 
> 
> ******************** file electron.dem ********************
> 
> gnuplot> plot Ic(Vbe)
>                      ^
>          "electron.dem", line 27: Can't plot with an empty x range!
> 
> 
> All these bugs disappear if I set the environment variable
> export LC_NUMERIC=.
> 
> So apparently Qt is changing the decimal separator. What is the gnuplot
> policy about locale settings ? If I find a way to tell Qt to use the "."
> decimal separator in any locale, would that be OK ?
> 
> 
> 
> ----------------------------------------------------------------------
> 
> Comment By: Ethan Merritt (sfeam)
> Date: 2009-06-02 14:22
> 
> Message:
> Oops. I don't know why the file didn't show up.  I'm not used to this new
> SourceForge interface yet.
> 
> ----------------------------------------------------------------------
> 
> Comment By: Jérôme Lodewyck (lodewyck)
> Date: 2009-06-02 07:48
> 
> Message:
> I cannot find your updated patch in the file list. Is it somewhere else ?
> 
> I have been away from hacking lately, but I have a pending update for the
> patch on my hard drive. I will try to merge it with your patch and submit
> it shortly.
> 
> There is no such Qt5. I just mentionned that Qt 4.5 is the first LGPL
> version of Qt, thus it should be required to distribute the Qt terminal
> along with gnuplot. But from a technical point of view, Qt 4.5 is just a
> minor update that do not require a rewrite at all.
> 
> ----------------------------------------------------------------------
> 
> Comment By: Ethan Merritt (sfeam)
> Date: 2009-06-02 06:37
> 
> Message:
> I've attached an updated patch file that compiles with current CVS.   All
> changes are trivial except for a fix for extra lines in polygons.
> 
> Do you want to do any more work on this driver before it goes into CVS?  
> 
> At one point I think you mentioned that Qt5 would require a re-write.  Is
> it worth waiting till then?
> It would be nice to have more complete documentation, if nothing else.
> 
> By the way, my earlier problem with no mouse response in the embed demo
> program seems to have gone away with a slightly newer libqt.
> 
> ----------------------------------------------------------------------
> 
> Comment By: Ethan Merritt (sfeam)
> Date: 2009-06-01 05:00
> 
> Message:
> In preparation for eventual release of gnuplot version 4.4, existing bugs
> and patchsets are being re-prioritized. 
> 
> I have chosen to use the following categories
> 
>  9 - should be included in 4.4.rc1 if possible
>  7 - looks reasonable to me, but not high priority for 4.4.rc1
>  5 - default priority for newly submitted patches
>  2 - not under active consideration
> 
> 
> These are my personal ratings.  If you want to argue for a different
> priority on one or more patches - go right ahead. 
> 
>      Ethan Merritt  (sfeam)
> 
> 
> ----------------------------------------------------------------------
> 
> Comment By: Ethan Merritt (sfeam)
> Date: 2009-02-17 06:39
> 
> Message:
> > What is the gnuplot policy for background painting ?
> 
> I don't think there is one. Most terminals do not have such an option. 
> x11 uses the XResource gnuplot*background or the command line option -bg. 
> The libgd terminals (png, jpeg, gif) allow a list of colors at the end of
> "set term command". The windows terminal pops up a color selection widget
> if you select "Background" from a pull-down menu.
> A qt color-selection widget would be neat, but I'd be happy with an option
> "set term qt background <colorspec>" if that's the easiest. The routine
> parse_colorspec() can be used to read it.
> 
> > Your issue with multiplot seems strange
> I can't explain multiplot slowness either. I'm just reporting what I see. 
> It seems to be worse when the system is loaded, which again may be a hint.
> 
> > The purpose of the embed example is to show how to use the terminal
> > to embed plots in Qt applications. Mousing is working, but only on
> > the last plot displayed
> 
> The embed example does not display mouse coordinates when I run it here. 
> I'd be happy to provide more information if this is a bug and you tell me
> what I should look for or try. 
> 
> 
> The TERM_HELP entry needs to be filled in more completely at some point.
> What does the "widget" option do?  Is that for embedding the plot?
>   
> 
> 
> ----------------------------------------------------------------------
> 
> Comment By: Jérôme Lodewyck (lodewyck)
> Date: 2009-02-16 22:23
> 
> Message:
> Thank you for your in-depth testing.
> 
> - "running_avg.dem" is indeed working fine with your patch
> 
> - splot mousing works after sending GE_plotdone
> 
> - The driver control flow is the following : when initialized, the process
> forks. The parents returns to the gnuplot core, while the child starts the
> GUI. Events are sent between processes using a crossplatform IPC exposed by
> the Qt API.
> 
> - Your issue with multiplot seems strange to me. Here, it is working fine,
> and all plots are displayed almost instantaneously. The very first version
> of the terminal was much slower and multiplot were indeed amongst the
> slowest to be drawn. Is there some special procedure triggered by gnuplot
> between each plot drawing ?
> 
> - When using the wxt terminal with the Qt theme for GTK widgets, Qt
> libraries version 3 are loaded and conflict with QT 4 libraries, hence the
> crash. In this configuration, compiling with Qt enabled forbids ever using
> the wxt terminal with the generated binary. With another theme, is is
> possible to select the wxt terminal or the qt terminal at runtime. However,
> successively plotting with both terminal in the same gnuplot session
> crashes because Qt internally uses the glib event loop. This issue should
> be resolved with the patch proposed by Timothée to run the wx terminal as
> an independant process.
> 
> - The Control-C issue is probably a problem with both core and GUI process
> catching the signal. I wil have a closer look at it.
> 
> - I don't think it is possible to specify the default background color
> independently from other default color settings. However, it is possible to
> programmatically have the background painted in white. What is the gnuplot
> policy for background painting ? Most terminal seem to choose white, but I
> tihink the X11 terminal background is rather grey-ish. Using the system
> color setting seems pretty sensible to me.
> 
> - The purpose of the embed example is to show how to use the terminal to
> embed plots in Qt applications. Mousing is working, but only on the last
> plot displayed, as in standard gnuplot with multiple windows open.
> 
> 
> ----------------------------------------------------------------------
> 
> Comment By: Ethan Merritt (sfeam)
> Date: 2009-02-16 05:54
> 
> Message:
> > except 3D mousing for which I really don't know what I am doing wrong...
> >
> 
> What's going wrong here is that the core code will not redraw the plot
> until it is notified that the previous draw event has finished.  But this
> signal is never being sent. The qt driver needs to respond to term->text()
> by sending back an event GE_plotdone.  I'm pretty sure that would fix the
> 3D mouse rotation.
> 
> I think there is one more bit of cleverness that should be added to
> prevent hysteresis. Whenever a mouse motion event is received by the event
> loop, all other pending mouse motion events should be purged from the event
> queue.  This makes a huge difference to the performance of the x11 driver,
> and I imagine it is similarly needed for qt.
> 
> ----------------------------------------------------------------------
> 
> Comment By: Ethan Merritt (sfeam)
> Date: 2009-02-16 04:10
> 
> Message:
> > There is a curious error that causes the top border of the plot to be
> > drawn, even if it is disabled.  See, for example, running_avg.dem.  
> There
> > should be no right- or top- border on the plot. This plots also
> triggers
> > that "wrong polygon size" warning, so maybe it is a clue.
> 
> I found some more cases of extra lines, and I think the fix is something
> like the following. It does fix the cases I found, but I'm working purely
> off intuition, so please sanity check the call:
> 
> diff -urp QtGnuplotScene.cpp QtGnuplotScene.cpp.save
> --- QtGnuplotScene.cpp.save  2009-02-15 20:09:06.000000000 -0800
> +++ QtGnuplotScene.cpp       2009-02-15 20:09:02.000000000 -0800
> @@ -100,7 +100,6 @@ void QtGnuplotScene::flushCurrentPolygon
>         if (m_currentPolygon.size() < 2)
>         {
>                 fprintf(stderr, "Wrong polygon size %i\n",
> m_currentPolygon.size());
> +               m_currentPolygon.clear();
>                 return;
>         }
> 
> 
> ----------------------------------------------------------------------
> 
> Comment By: Ethan Merritt (sfeam)
> Date: 2009-02-15 20:50
> 
> Message:
> Nice!
> 
> Could you please give a brief explanation of the control flow through this
> version of the driver?  I see that it spawns off a second copy of gnuplot,
> and I am suspicious that some of the problems I will describe below are due
> to glitches in the inter-process communication.
> 
> Comments from testing patch version of 15-Feb-2009:
> Built against libqt4-devel-4.4.3-1mdv2009.0
> 
> - There is a curious error that causes the top border of the plot to be
> drawn, even if it is disabled.  See, for example, running_avg.dem.   There
> should be no right- or top- border on the plot. This plots also triggers
> that "wrong polygon size" warning, so maybe it is a clue.
> 
> - Multiplots are ridiculously slow.  Try for example "key.dem". Each
> sample in the demo takes 5-10 seconds to draw.  In some multiplot demos the
> first plot in the figure comes up reasonably quickly, but then there is a
> very long delay before the rest of the plots appear.
> 
> - The edges of the individual parallelograms that represent the pixels in
> "image" plots do not meet up perfectly, leading to a visible grid on the
> plot.  We've seen this before in other terminal types, and had to work
> around quirks in the corresponding support libraries.  The effect is
> particularly visible in pm3d.dem. Is this what you meant by saying that
> "polygon clipping is wrong"?  The last time I fought with this, it turned
> out that in order for the graphics library to not leave a blank line of
> pixels along the boundary, it was necessary to both stroke and fill the
> same polygon.  I have no idea if that analysis is relevant to the Qt
> drawing primitives.
> 
> - In image2.dem, the plot showing decimation of binary data produces a
> garbled image. The plot command in question is 
>    plot 'blutux.rgb' binary array=(128,128) flipy format='%uchar' \
>                      every 1:1:43:15:83:65 with rgbimage 
> 
> - What I am now seeing if I attempt 3D mousing is that the first 1 or 2
> incremental moves are shown, but then the plot freezes. I.e. the view
> settings are updated internally but the plot is not redrawn. Manual replot
> does update to the current view setting.
> 
> - If I try to switch between the wxt and qt terminals in the same gnuplot
> session, it either segfaults or locks up hard and has to be killed
> externally from the command line.  Is this a known limitation, that the
> terminals are mutually exclusive?  That's probably OK, since I would think
> users would choose only one of the two, but it means we need to forcibly
> exclude selecton of the combination. [at build time? at run time?]
> 
> - Hitting control-C sometimes leaves the program in a peculiar state. 
> Characters may or may not be echoed as you type them, and subsequent plot
> commands generate the error:
>     QCoreApplication::exec: The event loop is already running
> After this the dead qt plot window consumes 100% of the CPU and must be
> killed externally.
> 
> 
> - The embedding example is neat, but I don't understand exactly how it
> should behave so I can't comment on whether it is living up to
> expectations.  It doesn't seem to be mouseable;  is this a bug?
> 
> - Because I have KDE set so that applications inherit the desktop color
> scheme, the background of the gnuplot window is not white.  What is the
> recommended way to force a background color for a specific Qt app?  If
> there is not a standard way, then I think the gnuplot terminal itself needs
> a way to specify the background color.
> 
> - Not sure what you mean by problems with Symbol->UTF8 conversion. Do you
> mean that iconv doesn't handle the Adobe-specific encoding used by the
> Adobe Symbol font?  I wouldn't consider that a bug. Using UTF8 for symbols
> is working fine.
> 
> 
> ----------------------------------------------------------------------
> 
> Comment By: Jérôme Lodewyck (lodewyck)
> Date: 2009-02-15 14:35
> 
> Message:
> Here is a new patch. It fixed all reported bugs, except 3D mousing for
> which I really don't know what I am doing wrong...
> 
> New:
> - Much faster
> - Antialiasing / Oversampling / Hinting
> - No more thread => should work with OS X
> - Persist behavior
> - Export to various formats (clipboard, printer, PDF, bitmaps)
> - Support for embedding plots in Qt applications. See embed_example.
> 
> Known issues:
> - the size term option not working
> - polygon clipping is wrong (edges are positioned at +/- 1 pixel)
> - problems with Symbol -> utf8 conversion
> - some demo give a "Wrong polygon size" error, which should not happen
> - mousing in 3D does not work
> - export to EPS not working
> - image clipping not implemented
> - implement mousing for non active plots
> 
> 
> ----------------------------------------------------------------------
> 
> Comment By: Ethan Merritt (sfeam)
> Date: 2009-02-15 05:01
> 
> Message:
> Found a bug.  If the program exits immediately after drawing a plot, then
> the process segfaults from somewhere in the Qt libraries:
> 
> qt.bug:
>     N = 0
>     plot sin(x)
>     pause N
>     exit
> 
> ./gnuplot qt.bug
> 
>    segfaults for N=0,  exits cleanly for N > 0.
> 
> ----------------------------------------------------------------------
> 
> Comment By: Ethan Merritt (sfeam)
> Date: 2009-02-09 06:50
> 
> Message:
> On, and one more minor observation.  The vertical alignment in enhanced
> text mode seems set to the top of the character cell rather than the
> baseline.  Have a look at "enhanced_utf8.dem" and note how the large B and
> the large integral sign extend down rather than up. 
> 
> ----------------------------------------------------------------------
> 
> Comment By: Ethan Merritt (sfeam)
> Date: 2009-02-09 06:40
> 
> Message:
> OK. It builds fine after an upgrade to Qt4.4.3
> 
> Some comments:
> 
> As Petr noted, mousing is broken in 3D.  It appears to be tracking the
> mouse properly, and updating the view matrix, but it doesn't issue a
> replot/refresh command as it goes so you don't see anything unless/until
> you hit the refresh manually.  Could this be a one-line fix somewhere?
> 
> Mousing is only partially working in 2D.  The tracking and zoom/unzoom is
> OK, but it doesn't seem to return mouse events on request.  E.g. the
> "mousevariables.dem" demo fails, and neither "pause mouse" nor "pause mouse
> key" ever returns.
> 
> One very noticeable thing that is that it doesn't offer the
> anti-aliasing/oversampling of the wxt terminal, so the lines and edges are
> not nearly as smooth. Is this something that could be added? 
> 
> But yes, it seems very promising. 
> 
> ----------------------------------------------------------------------
> 
> Comment By: Nobody/Anonymous (nobody)
> Date: 2009-02-07 09:47
> 
> Message:
> These are indeed Qt 4.4 functions.
> 
> clear() should be replaced by 
>   foreach (QGraphicsItem* item, items())
>     removeItem(item);
> 
> and 
>   line.setP1(##) by line.setPoints(##, line.p2())
>   line.setP2(##) by line.setPoints(line.p1(), ##)
> 
> Anyway, the target Qt version will most likely be 4.5 since it will be the
> first LGPL version of Qt.
> 
> 
> ----------------------------------------------------------------------
> 
> Comment By: Ethan Merritt (sfeam)
> Date: 2009-02-07 04:45
> 
> Message:
> I'm having trouble getting this to build properly.
> I get several errors from undefined symbols:
>     setP1
>     setP2
> which I can get past by commenting out the corresponding source lines.
> But this error is a problem:
> 
> qtterminal/QtGnuplotScene.cpp: In member function ‘void
> QtGnuplotScene::resetItems()’:
> qtterminal/QtGnuplotScene.cpp:196: error: ‘clear’ was not declared in
> this scope
> 
> If I comment out that one, or cast it to void, then the terminal builds
> but indeed it never clears the canvas.  So everything you try to plot
> writes on top of the existing contents.   There are about a gazillion
> instances of 'clear' in the qt4 headers, so I have no idea which scope to
> force.   Any suggestions?
> 
> For what it's worth, I am trying to build against
> libqt4-devel-4.3.4-6mdv2008.1
> 
> 
> 
> ----------------------------------------------------------------------
> 
> Comment By: Petr Mikulik (mikulik)
> Date: 2009-02-02 23:46
> 
> Message:
> Cool! It seems only mousing in "splot" does not work.
> 
> 
> ----------------------------------------------------------------------
> 
> You can respond by visiting: 
> https://sourceforge.net/tracker/?func=detail&atid=302055&aid=2558043&group_id=2055
> 
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge  
> This is your chance to win up to $100,000 in prizes! For a limited time, 
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize  
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> Gnuplot-developers mailing list
> Gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-developers
> 

Re: mouse pan and zoom

[Tatsuro M. <tma...@ya...>]

Hello

I have built wgnuplot with wxt on the cvs trees
2009-07-18  Ethan A Merritt  <merritt@u.washington.edu>

	* src/wxterminal/wxt_gui.cpp src/wxterminal/wxt_gui.h:
	Pass through mouse wheel events from the wxt terminal, so that the new
	pan and zoom works for wxt as well as x11.

I have confirmed that  pan and zoom using work on wxt but does not work on windows terminal.

Regards

Tatsuro

--- Ethan Merritt  wrote:

> On Friday 17 July 2009, Ethan Merritt wrote:
> > On Friday 17 July 2009, James R. Van Zandt wrote:
> > > 
> > > I've just checked in code to do "pan and zoom" with the mouse wheel.
> > 
> > First thoughts:
> > 
> > It works nicely here in x11, but doesn't do anything at all in wxt or
> > in the new canvas or qt terminals.  I understand that extra javascript
> > would be needed for the canvas,  but what is needed in order to support
> > this for other interactive terminal types?
> 
>   OK. I figured out how to add a wxt handler for mouse wheel events.
> 
>   I'll punt on qt and hope that J将アr将ヤme Lodewyck will take care of it.
> 
>   What about the windows terminal - can someone confirm whether that
>   is recognizing pan and zoom using the same conventions as x11?
> 
> 	Ethan 
> 
> 
> 
> > 
> > Wouldn't it be logical to apply this in 3D also?
> > 
> > It does not immediately strike me as useful to save the settings on the
> > zoom stack.  Unlike a click-and-drag zoom operation, the inverse is easy
> > to achieve by reversing the direction of the mouse wheel.
> > 
> > 
> > > These commands work like Acroread or Gimp:
> > > 
> > >  - control-wheel-up zooms in toward the center of the plot
> > >  - control-wheel-down  reverses the above
> > > 
> > >  - wheel-up move the viewpoint up (increases both ymin and ymax by ten
> > >    percent of the plot range)
> > > 
> > >  - wheel-down moves the viewpoint down
> > > 
> > >  - shift-wheel-up moves the viewpoint left (decreases both xmin and xmax
> > >    by ten percent of the plot range)
> > > 
> > >  - shift-wheel-down moves the viewpoint right
> > > 
> > > 
> > > I implemented these just for completeness:
> > > 
> > >  - shift-control-wheel-up zooms in only the X axis
> > >  - shift-control-wheel-down zooms out only the X axis
> > > 
> > > 
> > > These work for linear or log axes.
> > > 
> > > A simple plot for testing, with or without log axes:
> > > 
> > > set parametric; plot sin(t)+1.02,cos(t)+1.02
> > > 
> > > (If zero is not currently on an axis, you can use "L" to toggle
> > > logscale along that axis.)
> > > 
> > > 
> > > I'll be glad to add documentation, but first I'll see what changes
> > > people want.  E.g.:
> > > 
> > >  - Are the pan and zoom steps reasonable?  Should they be user-tunable?
> > >  - Do you have a better idea for shift-control-wheel?
> > >  - Each of these commands is added to the zoom stack, so they can be
> > > undone individually.  That was easy to implement, but do we want that?
> > > Does "u" recover all that memory?  Should we suggest that the user
> > > type "u" occasionally?
> > > 
> > >         - Jim Van Zandt
> > > 
> > > ------------------------------------------------------------------------------
> > > Enter the BlackBerry Developer Challenge  
> > > This is your chance to win up to $100,000 in prizes! For a limited time, 
> > > vendors submitting new applications to BlackBerry App World(TM) will have
> > > the opportunity to enter the BlackBerry Developer Challenge. See full prize  
> > > details at: http://p.sf.net/sfu/Challenge
> > > _______________________________________________
> > > gnuplot-beta mailing list
> > > gnu...@li...
> > > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> > > 
> > 
> > 
> 
> 
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge  
> This is your chance to win up to $100,000 in prizes! For a limited time, 
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize  
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 


--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

Re: mouse pan and zoom

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

On Saturday 18 July 2009, James R. Van Zandt wrote:
> Ethan Merritt <merritt@u.washington.edu> writes:

> >It works nicely here in x11, but doesn't do anything at all in wxt or
> >in the new canvas or qt terminals.  I understand that extra javascript
> >would be needed for the canvas,  but what is needed in order to support
> >this for other interactive terminal types?
> 
> I only tested the x11 terminal, but I'm actually disappointed that
> changes to the core code don't affect all the mouse-capable terminals.

The core code works fine, but it is only called if there is an event
handler registered for the mouse wheel events inside the plot window
used by the current terminal.  X11 has one. I can see in the code
that there is one also for windows, though I can't confirm that it works.
I have just added one for wxt.  

Re: mouse pan and zoom

[James R. V. Z. <jr...@co...>]

Ethan Merritt <merritt@u.washington.edu> writes:
>On Friday 17 July 2009, James R. Van Zandt wrote:
>> 
>> I've just checked in code to do "pan and zoom" with the mouse wheel.
>
>It works nicely here in x11, but doesn't do anything at all in wxt or
>in the new canvas or qt terminals.  I understand that extra javascript
>would be needed for the canvas,  but what is needed in order to support
>this for other interactive terminal types?

I only tested the x11 terminal, but I'm actually disappointed that
changes to the core code don't affect all the mouse-capable terminals.
It suggests there's something wrong with the way the code is factored.
However, I have no idea how the other terminals handle the mouse.
Does it work with the Windows terminal?

>Wouldn't it be logical to apply this in 3D also?

Good idea.

>It does not immediately strike me as useful to save the settings on the
>zoom stack.  Unlike a click-and-drag zoom operation, the inverse is easy
>to achieve by reversing the direction of the mouse wheel.

True.  As I wrote, it was easiest to implement it that way.
Separating the zooming and stacking functions looked messy (I wasn't
sure I followed all the logic) and I didn't convince myself that it
was worth the trouble.

      - Jim

Re: mouse pan and zoom

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

On Friday 17 July 2009, Ethan Merritt wrote:
> On Friday 17 July 2009, James R. Van Zandt wrote:
> > 
> > I've just checked in code to do "pan and zoom" with the mouse wheel.
> 
> First thoughts:
> 
> It works nicely here in x11, but doesn't do anything at all in wxt or
> in the new canvas or qt terminals.  I understand that extra javascript
> would be needed for the canvas,  but what is needed in order to support
> this for other interactive terminal types?

  OK. I figured out how to add a wxt handler for mouse wheel events.

  I'll punt on qt and hope that Jérôme Lodewyck will take care of it.

  What about the windows terminal - can someone confirm whether that
  is recognizing pan and zoom using the same conventions as x11?

	Ethan 



> 
> Wouldn't it be logical to apply this in 3D also?
> 
> It does not immediately strike me as useful to save the settings on the
> zoom stack.  Unlike a click-and-drag zoom operation, the inverse is easy
> to achieve by reversing the direction of the mouse wheel.
> 
> 
> > These commands work like Acroread or Gimp:
> > 
> >  - control-wheel-up zooms in toward the center of the plot
> >  - control-wheel-down  reverses the above
> > 
> >  - wheel-up move the viewpoint up (increases both ymin and ymax by ten
> >    percent of the plot range)
> > 
> >  - wheel-down moves the viewpoint down
> > 
> >  - shift-wheel-up moves the viewpoint left (decreases both xmin and xmax
> >    by ten percent of the plot range)
> > 
> >  - shift-wheel-down moves the viewpoint right
> > 
> > 
> > I implemented these just for completeness:
> > 
> >  - shift-control-wheel-up zooms in only the X axis
> >  - shift-control-wheel-down zooms out only the X axis
> > 
> > 
> > These work for linear or log axes.
> > 
> > A simple plot for testing, with or without log axes:
> > 
> > set parametric; plot sin(t)+1.02,cos(t)+1.02
> > 
> > (If zero is not currently on an axis, you can use "L" to toggle
> > logscale along that axis.)
> > 
> > 
> > I'll be glad to add documentation, but first I'll see what changes
> > people want.  E.g.:
> > 
> >  - Are the pan and zoom steps reasonable?  Should they be user-tunable?
> >  - Do you have a better idea for shift-control-wheel?
> >  - Each of these commands is added to the zoom stack, so they can be
> > undone individually.  That was easy to implement, but do we want that?
> > Does "u" recover all that memory?  Should we suggest that the user
> > type "u" occasionally?
> > 
> >         - Jim Van Zandt
> > 
> > ------------------------------------------------------------------------------
> > Enter the BlackBerry Developer Challenge  
> > This is your chance to win up to $100,000 in prizes! For a limited time, 
> > vendors submitting new applications to BlackBerry App World(TM) will have
> > the opportunity to enter the BlackBerry Developer Challenge. See full prize  
> > details at: http://p.sf.net/sfu/Challenge
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> > 
> 
> 

Re: mouse pan and zoom

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

On Friday 17 July 2009, James R. Van Zandt wrote:
> 
> I've just checked in code to do "pan and zoom" with the mouse wheel.

First thoughts:

It works nicely here in x11, but doesn't do anything at all in wxt or
in the new canvas or qt terminals.  I understand that extra javascript
would be needed for the canvas,  but what is needed in order to support
this for other interactive terminal types?

Wouldn't it be logical to apply this in 3D also?

It does not immediately strike me as useful to save the settings on the
zoom stack.  Unlike a click-and-drag zoom operation, the inverse is easy
to achieve by reversing the direction of the mouse wheel.


> These commands work like Acroread or Gimp:
> 
>  - control-wheel-up zooms in toward the center of the plot
>  - control-wheel-down  reverses the above
> 
>  - wheel-up move the viewpoint up (increases both ymin and ymax by ten
>    percent of the plot range)
> 
>  - wheel-down moves the viewpoint down
> 
>  - shift-wheel-up moves the viewpoint left (decreases both xmin and xmax
>    by ten percent of the plot range)
> 
>  - shift-wheel-down moves the viewpoint right
> 
> 
> I implemented these just for completeness:
> 
>  - shift-control-wheel-up zooms in only the X axis
>  - shift-control-wheel-down zooms out only the X axis
> 
> 
> These work for linear or log axes.
> 
> A simple plot for testing, with or without log axes:
> 
> set parametric; plot sin(t)+1.02,cos(t)+1.02
> 
> (If zero is not currently on an axis, you can use "L" to toggle
> logscale along that axis.)
> 
> 
> I'll be glad to add documentation, but first I'll see what changes
> people want.  E.g.:
> 
>  - Are the pan and zoom steps reasonable?  Should they be user-tunable?
>  - Do you have a better idea for shift-control-wheel?
>  - Each of these commands is added to the zoom stack, so they can be
> undone individually.  That was easy to implement, but do we want that?
> Does "u" recover all that memory?  Should we suggest that the user
> type "u" occasionally?
> 
>         - Jim Van Zandt
> 
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge  
> This is your chance to win up to $100,000 in prizes! For a limited time, 
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize  
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

mouse pan and zoom

[James R. V. Z. <jr...@co...>]

I've just checked in code to do "pan and zoom" with the mouse wheel.

These commands work like Acroread or Gimp:

 - control-wheel-up zooms in toward the center of the plot
 - control-wheel-down  reverses the above

 - wheel-up move the viewpoint up (increases both ymin and ymax by ten
   percent of the plot range)

 - wheel-down moves the viewpoint down

 - shift-wheel-up moves the viewpoint left (decreases both xmin and xmax
   by ten percent of the plot range)

 - shift-wheel-down moves the viewpoint right


I implemented these just for completeness:

 - shift-control-wheel-up zooms in only the X axis
 - shift-control-wheel-down zooms out only the X axis


These work for linear or log axes.

A simple plot for testing, with or without log axes:

set parametric; plot sin(t)+1.02,cos(t)+1.02

(If zero is not currently on an axis, you can use "L" to toggle
logscale along that axis.)


I'll be glad to add documentation, but first I'll see what changes
people want.  E.g.:

 - Are the pan and zoom steps reasonable?  Should they be user-tunable?
 - Do you have a better idea for shift-control-wheel?
 - Each of these commands is added to the zoom stack, so they can be
undone individually.  That was easy to implement, but do we want that?
Does "u" recover all that memory?  Should we suggest that the user
type "u" occasionally?

        - Jim Van Zandt

Re: set x/yrange for the fit command

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

On Friday 17 July 2009 06:56:39 Petr Mikulik wrote:
> A colleague reported me that limitations due to "set yrange" are in charge 
> also for the "fit" command despite that this is not documented. He thought 
> that "set yrange" applies for plots only and was surprised by wrong fits.
> 
> Indeed, documentation for "fit" says that x and y range limitations for the 
> "fit" command must be given as "fit [xrange] [yrange]".

No, it does not say "must".   It says:
    Ranges may be specified to temporarily limit 
    the data which is to be fitted

This is exactly the same as with a "plot" command.  You can specify the
x and y ranges in the plot command itself if you prefer, but otherwise
it looks in the current settings of xrange and yrange.

> And "help xrange" speak about plotting only:
>   The `set xrange` command sets the horizontal range that will be displayed.
> 
> Is this bug or undocumented feature? 
> Should gnuplot or its documentation be fixed?

I think it is already documented.  The text in "help fit" says is behaves
analogously to "plot", and explicitly refers you to "help plot ranges".
Then again, if one person is confused by it, other people may also be
confused. 

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

set x/yrange for the fit command

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

A colleague reported me that limitations due to "set yrange" are in charge 
also for the "fit" command despite that this is not documented. He thought 
that "set yrange" applies for plots only and was surprised by wrong fits.

Indeed, documentation for "fit" says that x and y range limitations for the 
"fit" command must be given as "fit [xrange] [yrange]".

And "help xrange" speak about plotting only:
  The `set xrange` command sets the horizontal range that will be displayed.

Is this bug or undocumented feature? Should gnuplot or its documentation be 
fixed?

---
PM

Re: eaten character in X11 - Re: et origin

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

Here is yet another observations: the bug

multiplot> et origin 0, 0
           ^
           line 0: invalid command

appears also
- I copy by mouse to Octave's command line commands
	plot(1:10);
	plot(1:10);
- I copy these lines by mouse or they can be in a script file
  blabla.m:
	plot(1:10);
	print -deps bla.ps

but it is OK with a delay:
	plot(1:10);
	pause(1);
	print -deps bla.ps

It appears to me that the gnuplot's plot is not yet finished and it wants to 
read a char from keyboard but it eats it from the stream of commands 
instead.


I've tried to reproduce the bug by means of reading file with gnuplot 
commands
	f=popen('gnuplot', 'w');
	g=fopen('xx.gp', 'r');
	while (~feof(g))
	    s = fgets(g); fputs(f, s);
	end
	fclose(g);
	fflush(f);

but the problem was not reproduced.

I don't know whether this problem can be avoided -- well, the simplest 
solution for Octave is to add "\n" into the __go_draw_figure__.m as I've 
mentioned earlier. Ben, can you please update the file?


> Here is a more improved bug report compared to that I've sent to Ben and 
> bu...@oc...:
> 
> 
> In Octave 3.2.0, I've noticed a missing ("eaten") character when pasting 
> several commands by mouse into Octave or when plotting many plots from a 
> script file (under Linux and X11 gnuplot terminal). For example, the 
> following is reproducible on my computer -- paste the following by middle 
> mouse button:
> 
> clf
> subplot(1,2,1); title("fig 1")
> subplot(2,2,2); title("fig 2")
> subplot(2,2,4); title("fig 3")
> 
> which leads to:
> 
> tmp|16:57:30|11> clf
> tmp|16:57:30|12> subplot(1,2,1); title("fig 1")
> tmp|16:57:31|13> subplot(2,2,2); title("fig 2")
> tmp|16:57:31|14> subplot(2,2,4); title("fig 3")
> 
> multiplot> et origin 0, 0
>            ^
>            line 30: invalid command
> 
> 
> It happens in this sequence of commands sent to gnuplot:
> 
> 	fputs (plot_stream, "set multiplot;\n");
> 	fputs (plot_stream, "set origin 0, 0\n");
> 
> in octave/3.2.0/m/plot/__go_draw_figure__.m
> 
> The problem vanishes if I add \n into the first command, e.g.
>         fputs (plot_stream, "set multiplot;\n\n");
> Note that adding ";" or fflush() does not help.
> 
> I have tested older gnuplot releases, and it seems that gnuplot earlier than 
> the patch below works correctly:
> 
> 2008-11-06  Ethan Merritt  <merritt@u.washington.edu>
> * term/x11.trm (X11_set_font ENHX11_put_text): Initialize enhanced text 
>   processing to use most recently requested font rather than the default 
>   font.

transparent.dem in x11

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

I've just compared "transparent.dem" under x11, wxt and win. It seems the 
first figure has different colours on x11: blue, red, green instead of red, 
green, yellow as seen on other terminals.

Moreover, colours of the solid filled curves do not correspond to colours in 
the key (legend).

Note that the file says "forest-green", "gold" and "red". However, these 
problems happen also if these are changed to another colour names.

---
PM

Re: initailization issue? transparent_solids.dem on gnuplot 4.3

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

> > The other problem ("lc lt N" not working) is less easy to understand.
> > Perhaps I have made a stupid typo somewhere.
> 
> I think I have found the error.
> Here is try #4.  I hope that "lc lt N" will now work.
>
> One thing I am not sure about, however, is the effect of linewidth.

I confirm all works OK! Wonderful!

Petr

Re: initailization issue? transparent_solids.dem on gnuplot 4.3

[Tatsuro M. <tma...@ya...>]

Hello 


--- Ethan Merritt  wrote:

> On Monday 13 July 2009 08:48:34 Ethan Merritt wrote:
> > 
> > The other problem ("lc lt N" not working) is less easy to understand.
> > Perhaps I have made a stupid typo somewhere.
> 
> I think I have found the error.
> Here is try #4.  I hope that "lc lt N" will now work.
> 
> One thing I am not sure about, however, is the effect of linewidth.
> I copied a block of code from the W_line_type case that is marked
> "work-around for Windows clipboard bug" and treats (line_width == 1)
> as a special case.  It is possible that the color setting will work
> only if the line_width is, or is not, equal to 1.  Please check both.

I have applied your new patch and tested.

set title "HELLO" tc rgb "blue"
set xlabel "xxxxx"
set ylabel "yyyyy"
set style rectangle fs solid 1.0 noborder
set object 1 rect from 0,0 to 7,7 fc rgb "blue"
set object 2 rect from -6,-6 to -2,-2 fc rgb "magenta"
set object 3 rect from -9,-9 to -4,+2 fc rgb "yellow"
plot x lw 1

set title "HELLO" tc rgb "blue"
set xlabel "xxxxx"
set ylabel "yyyyy"
set style rectangle fs solid 1.0 noborder
set object 1 rect from 0,0 to 7,7 fc rgb "blue"
set object 2 rect from -6,-6 to -2,-2 fc rgb "magenta"
set object 3 rect from -9,-9 to -4,+2 fc rgb "yellow"
plot x lw 2

Both worked correctly!!!.

The second point by Petr
	set title "HELLO"Further,
	set title "HELLO" tc lt 3
also worked fine!!!.

Of cource,  'transparent_solids.dem' worked correctly!!!

I strongly appreciated for your all efforts about this matter.

Regards

Tatsuro

--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

Re: initailization issue? transparent_solids.dem on gnuplot 4.3

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

On Monday 13 July 2009 08:48:34 Ethan Merritt wrote:
> 
> The other problem ("lc lt N" not working) is less easy to understand.
> Perhaps I have made a stupid typo somewhere.

I think I have found the error.
Here is try #4.  I hope that "lc lt N" will now work.

One thing I am not sure about, however, is the effect of linewidth.
I copied a block of code from the W_line_type case that is marked
"work-around for Windows clipboard bug" and treats (line_width == 1)
as a special case.  It is possible that the color setting will work
only if the line_width is, or is not, equal to 1.  Please check both.


-- 
Ethan A Merritt

Re: initailization issue? transparent_solids.dem on gnuplot 4.3

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

On Monday 13 July 2009, Petr Mikulik wrote:
>
> => all rectangles have correct colour.

Aha. Progress!
 
> On the other hand, there is a bug in Windows terminal that color selection 
> with "lt <n>" does not work -- it produces either black or red colours.

I get brown here, rather than black or red,
using Matsuoka-san's executable.

> 
> I think this bug is associated:
> 	plot x, -x, sin(x), cos(x)
> => and now resize the window by mouse => the colour of legend (key) labels 
> "x", "-x", "sin(x)", "cos(x)" changes after each mouse movement during 
> window resizing.

> Ethan, can you deduce something from these cases?

Yes, but it make be a couple of days before I have time to work on it.

It turns out that the fill color is in some circumstances taken from the
text color rather than the line color (strange, but that's what the Windows
documentation says).  The -try3 patch forces the text color to the same
as the line color during a fill.  That made the RGB color fill start working,
but it must be that the text color needs to be reset somewhere else before
the next text operation. 

The other problem ("lc lt N" not working) is less easy to understand.
Perhaps I have made a stupid typo somewhere.

[Sun, X. <xiu...@ci...>]

Re: initailization issue? transparent_solids.dem on gnuplot 4.3

[Tatsuro M. <tma...@ya...>]

Hello

--- Petr Mikulik <mi...@ph...> wrote:

> I've missed  Ethan's patch  win_fillbox_try3.patch ... I've tried it now, 
> and it works!
> 
> I.e., this is correct:
> 
> set title "HELLO" tc rgb "blue"
> set xlabel "xxxxx"
> set ylabel "yyyyy"
> set style rectangle fs solid 1.0 noborder
> set object 1 rect from 0,0 to 7,7 fc rgb "blue"
> set object 2 rect from -6,-6 to -2,-2 fc rgb "magenta"
> set object 3 rect from -9,-9 to -4,+2 fc rgb "yellow"
> 
> => all rectangles have correct colour.

The above works well for my build with 'win_fillbox_try3.patch'

> ***
> 
> On the other hand, there is a bug in Windows terminal that color selection 
> with "lt <n>" does not work -- it produces either black or red colours.
> 
> I think this bug is associated:
> 	plot x, -x, sin(x), cos(x)
> => and now resize the window by mouse => the colour of legend (key) labels 
> "x", "-x", "sin(x)", "cos(x)" changes after each mouse movement during 
> window resizing.

Hmmm! I got the same results

> The same happens for the colour of title
> 	set title "HELLO"
> Further,
> 	set title "HELLO" tc lt 3
> is red (for whichever number of lt).
> 
After plot x, -x, sin(x), cos(x) test,
 	set title "HELLO"
 	set title "HELLO" tc lt 3
 is red (for whichever number of lt).

However, I exit gnuplot and reexecute gnuplot.
 	set title "HELLO"
 	set title "HELLO" tc lt 3
 is black (for whichever number of lt).

Regards

Tatsuro

--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

Re: initailization issue? transparent_solids.dem on gnuplot 4.3

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

I've missed  Ethan's patch  win_fillbox_try3.patch ... I've tried it now, 
and it works!

I.e., this is correct:

set title "HELLO" tc rgb "blue"
set xlabel "xxxxx"
set ylabel "yyyyy"
set style rectangle fs solid 1.0 noborder
set object 1 rect from 0,0 to 7,7 fc rgb "blue"
set object 2 rect from -6,-6 to -2,-2 fc rgb "magenta"
set object 3 rect from -9,-9 to -4,+2 fc rgb "yellow"

=> all rectangles have correct colour.

***

On the other hand, there is a bug in Windows terminal that color selection 
with "lt <n>" does not work -- it produces either black or red colours.

I think this bug is associated:
	plot x, -x, sin(x), cos(x)
=> and now resize the window by mouse => the colour of legend (key) labels 
"x", "-x", "sin(x)", "cos(x)" changes after each mouse movement during 
window resizing.

The same happens for the colour of title
	set title "HELLO"
Further,
	set title "HELLO" tc lt 3
is red (for whichever number of lt).

Ethan, can you deduce something from these cases?

---
PM

Re: initailization issue? transparent_solids.dem on gnuplot 4.3

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

I have also tested Ethan's patch  win_fillbox_try2.patch
with

set title 'HELLO' tc rgb "blue"
set style rectangle fs solid 1.0 noborder
set object 1 rect from 0,0 to 5,5 fc rgb "blue"
set object 2 rect from -6,-6 to -1,-1 fc lt 3
plot x

and there are still two black boxes instead of blue boxes.

I think we should make a Bug report on SF site for a future windows 
developer.

---
PM

Fwd: Re: initailization issue? transparent_solids.dem on gnuplot 4.3 ChangeLog 2009-07-04 on win term

[Tatsuro M. <tma...@ya...>]

I have fortten sent the below to gnu...@li...

--- Tatsuro MATSUOKA <tma...@ya...> wrote:

> Date:Mon, 13 Jul 2009 10:16:30 +0900 (JST)
> From:Tatsuro MATSUOKA <tma...@ya...>
> Subject:Re: initailization issue? transparent_solids.dem on gnuplot 4.3 ChangeLog 2009-07-04 on
> win term
> To:Ethan Merritt <merritt@u.washington.edu>
> CC:Petr Mikulik <mi...@ph...>
> 
> Hello
> 
> --- Ethan Merritt wrote:
> 
> > Another try.  This one touches a different part of the code,
> > and contains some debugging statements.
> > 
> > Could you send me a copy of the windows executable containing the patch?
> > Or put it on a web site for download?
> > I'd like to do further debugging by experimenting with different settings,
> > fill styles, and color assignments.
> > 
> > 	thanks,
> > 
> > 		Ethan
> > 
> 
> Thank you very much for your  mail
> 
> I have built with your patch and tested
> 
> set title 'HELLO' tc rgb "blue"
> set object 1 rect from 0,0 to 5,5 fc rgb "blue"
> set object 2 rect from -6,-6 to -1,-1 fc lt 3
> plot x
> 
> => title is blue, but rectangle 1 is blue with blue boader  and rectangle 2 is blue with black
> boader 
> (red is color of the line of plot x)
> 
> I have also the executables on
> http://www.geocities.jp/tmgpltwin/Files/Files.html
> 
> 0020 Gnuplot4.3.zip, 3,946,720 bytes, 2009-07-17
> 
> I have built binaries with DEBUG is true (complied with -g).
> 
> Regards
> 
> Tatsuro
> 
> 
> --------------------------------------
> Power up the Internet with Yahoo! Toolbar.
> http://pr.mail.yahoo.co.jp/toolbar/
> 


--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

Fwd: Re: initailization issue? transparent_solids.dem on gnuplot 4.3 ChangeLog 2009-07-04 on win term

[Tatsuro M. <tma...@ya...>]

I have fortten sent the below to gnu...@li...

--- Tatsuro MATSUOKA <tma...@ya...> wrote:

> Date:Mon, 13 Jul 2009 10:16:30 +0900 (JST)
> From:Tatsuro MATSUOKA <tma...@ya...>
> Subject:Re: initailization issue? transparent_solids.dem on gnuplot 4.3 ChangeLog 2009-07-04 on
> win term
> To:Ethan Merritt <merritt@u.washington.edu>
> CC:Petr Mikulik <mi...@ph...>
> 
> Hello
> 
> --- Ethan Merritt wrote:
> 
> > Another try.  This one touches a different part of the code,
> > and contains some debugging statements.
> > 
> > Could you send me a copy of the windows executable containing the patch?
> > Or put it on a web site for download?
> > I'd like to do further debugging by experimenting with different settings,
> > fill styles, and color assignments.
> > 
> > 	thanks,
> > 
> > 		Ethan
> > 
> 
> Thank you very much for your  mail
> 
> I have built with your patch and tested
> 
> set title 'HELLO' tc rgb "blue"
> set object 1 rect from 0,0 to 5,5 fc rgb "blue"
> set object 2 rect from -6,-6 to -1,-1 fc lt 3
> plot x
> 
> => title is blue, but rectangle 1 is blue with blue boader  and rectangle 2 is blue with black
> boader 
> (red is color of the line of plot x)
> 
> I have also the executables on
> http://www.geocities.jp/tmgpltwin/Files/Files.html
> 
> 0020 Gnuplot4.3.zip, 3,946,720 bytes, 2009-07-17
> 
> I have built binaries with DEBUG is true (complied with -g).
> 
> Regards
> 
> Tatsuro
> 
> 
> --------------------------------------
> Power up the Internet with Yahoo! Toolbar.
> http://pr.mail.yahoo.co.jp/toolbar/
> 


--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/