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

Re: towards 4.4

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

Hello

I have confirmed that your patch works for 3d plots.

I have upload binaries with the patch on the web.
http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/ 

Regards

Tatsuro

--- Benjamin Lindner  wrote:

> Tatsuro MATSUOKA wrote:
> > Hello
> > 
> > I have tried the patch.
> > 
> > set term windows enhanced font ",14"
> > set label 1 "e^{i{/symbol p}} = -1" at graph 0.1,0.5
> > plot sin(x) with linespoints, cos(x) with linespoints
> > 
> > worked fine!!!!!!!.
> > 
> > 
> > However,  I have tried
> > set xrange [-pi:pi]
> > set yrange [-pi:pi]
> > splot sin(x*x+y*y)/(x*x+y*y)
> > 
> > was broken as a attachment file.
> 
> Thanks for the report.
> 
> I modified my patch and now I see the expected behaviour
> with plot (lines + image), splot (surface+pm3d).
> 
> I also added the keyboard shortcut Ctrl+C for copying to clipboard.
> 
> benjamin
> 
> 
> > testing EMF clipboard copying
> 
> diff --git a/src/win/wgraph.c b/src/win/wgraph.c
> --- a/src/win/wgraph.c
> +++ b/src/win/wgraph.c
> @@ -389,7 +389,7 @@
>  		M_GRAPH_TO_TOP, "Bring to &Top");
>  	AppendMenu(lpgw->hPopMenu, MF_STRING | (lpgw->color ? MF_CHECKED : MF_UNCHECKED),
>  		M_COLOR, "C&olor");
> -	AppendMenu(lpgw->hPopMenu, MF_STRING, M_COPY_CLIP, "&Copy to Clipboard");
> +	AppendMenu(lpgw->hPopMenu, MF_STRING, M_COPY_CLIP, "&Copy to Clipboard (Ctrl+C)");
>  #if WINVER >= 0x030a
>  	AppendMenu(lpgw->hPopMenu, MF_STRING, M_BACKGROUND, "&Background...");
>  	AppendMenu(lpgw->hPopMenu, MF_STRING, M_CHOOSE_FONT, "Choose &Font...");
> @@ -646,6 +646,38 @@
>  	if (rect->bottom < rect->top) rect->bottom = rect->top;
>  }
>  
> +static void 
> +GetPlotRectInMM(LPGW lpgw, LPRECT rect, HDC hdc)
> +{
> +	GetPlotRect (lpgw, rect);
> +	
> +	/* Taken from 
> +	http://msdn.microsoft.com/en-us/library/dd183519(VS.85).aspx
> +	 */
> +	
> +	// Determine the picture frame dimensions.  
> +	// iWidthMM is the display width in millimeters.  
> +	// iHeightMM is the display height in millimeters.  
> +	// iWidthPels is the display width in pixels.  
> +	// iHeightPels is the display height in pixels  
> +	
> +	int iWidthMM = GetDeviceCaps(hdc, HORZSIZE); 
> +	int iHeightMM = GetDeviceCaps(hdc, VERTSIZE); 
> +	int iWidthPels = GetDeviceCaps(hdc, HORZRES); 
> +	int iHeightPels = GetDeviceCaps(hdc, VERTRES); 
> +	
> +	// Convert client coordinates to .01-mm units.  
> +	// Use iWidthMM, iWidthPels, iHeightMM, and  
> +	// iHeightPels to determine the number of  
> +	// .01-millimeter units per pixel in the x-  
> +	//  and y-directions.  
> +	
> +	rect->left = (rect->left * iWidthMM * 100)/iWidthPels; 
> +	rect->top = (rect->top * iHeightMM * 100)/iHeightPels; 
> +	rect->right = (rect->right * iWidthMM * 100)/iWidthPels; 
> +	rect->bottom = (rect->bottom * iHeightMM * 100)/iHeightPels; 
> +}
> +
>  
>  static void
>  MakeFonts(LPGW lpgw, LPRECT lprect, HDC hdc)
> @@ -1362,12 +1394,10 @@
>  static void
>  CopyClip(LPGW lpgw)
>  {
> -	RECT rect;
> -	HDC mem;
> +	RECT rect, mfrect;
> +	HDC mem, hmf;
>  	HBITMAP bitmap;
> -	HANDLE hmf;
> -	GLOBALHANDLE hGMem;
> -	LPMETAFILEPICT lpMFP;
> +	HENHMETAFILE hemf;
>  	HWND hwnd;
>  	HDC hdc;
>  
> @@ -1400,49 +1430,23 @@
>  	}
>  	DeleteDC(mem);
>  
> -	/* OK, bitmap done, now create a Metafile context at full theoretical resolution
> -	 * of the Windows terminal (24000 x 18000 pixels), and redraw the whole
> -	 * plot into that. */
> +	/* OK, bitmap done, now create an enhanced Metafile context 
> +	 * and redraw the whole plot into that. 
> +	 */
>  	{
>  		/* make copy of window's main status struct for modification */
>  		GW gwclip = *lpgw;
> -		int windowfontsize = MulDiv(lpgw->fontsize, GetDeviceCaps(hdc, LOGPIXELSY), 72);
> -		int i;
>  
> -		gwclip.fontsize = MulDiv(windowfontsize, lpgw->ymax, rect.bottom);
>  		gwclip.hfonth = gwclip.hfontv = 0;
> -
> -		/* HBB 981203: scale up pens as well... */
> -		for (i = 0; i < WGNUMPENS + 2; i++) {
> -			if(gwclip.monopen[i].lopnWidth.x > 1)
> -				gwclip.monopen[i].lopnWidth.x =
> -					MulDiv(gwclip.monopen[i].lopnWidth.x,
> -					       gwclip.xmax, rect.right-rect.left);
> -			if(gwclip.colorpen[i].lopnWidth.x > 1)
> -				gwclip.colorpen[i].lopnWidth.x =
> -					MulDiv(gwclip.colorpen[i].lopnWidth.x,
> -					       gwclip.xmax, rect.right-rect.left);
> -		}
> -
> -		rect.right = lpgw->xmax;
> -		rect.bottom = lpgw->ymax;
> -
>  		MakePens(&gwclip, hdc);
>  		MakeFonts(&gwclip, &rect, hdc);
>  
> -		ReleaseDC(hwnd, hdc);
> +		GetPlotRectInMM(lpgw, &mfrect, hdc);
>  
> -		hdc = CreateMetaFile((LPSTR)NULL);
> +		hmf = CreateEnhMetaFile(hdc, (LPCTSTR)NULL, &mfrect, (LPCTSTR)NULL);
> +		drawgraph(&gwclip, hmf, (LPRECT) &rect);
> +		hemf = CloseEnhMetaFile(hmf);
>  
> -/* HBB 981203: According to Petzold, Metafiles shouldn't contain SetMapMode() calls: */
> -	/*SetMapMode(hdc, MM_ANISOTROPIC);*/
> -#ifdef WIN32
> -		SetWindowExtEx(hdc, rect.right, rect.bottom, (LPSIZE)NULL);
> -#else
> -		SetWindowExt(hdc, rect.right, rect.bottom);
> -#endif
> -		drawgraph(&gwclip, hdc, (LPRECT) &rect);
> -		hmf = CloseMetaFile(hdc);
>  		DestroyFonts(&gwclip);
>  		DestroyPens(&gwclip);
>  	}
> @@ -1450,23 +1454,13 @@
>  	/* Now we have the Metafile and Bitmap prepared, post their contents to
>  	 * the Clipboard */
>  
> -	hGMem = GlobalAlloc(GMEM_MOVEABLE, (DWORD)sizeof(METAFILEPICT));
> -	lpMFP = (LPMETAFILEPICT) GlobalLock(hGMem);
> -	hdc = GetDC(hwnd);	/* get window size */
> -	GetPlotRect(lpgw, &rect);
> -	/* in MM_ANISOTROPIC, xExt & yExt give suggested size in 0.01mm units */
> -	lpMFP->mm = MM_ANISOTROPIC;
> -	lpMFP->xExt = MulDiv(rect.right-rect.left, 2540, GetDeviceCaps(hdc, LOGPIXELSX));
> -	lpMFP->yExt = MulDiv(rect.bottom-rect.top, 2540, GetDeviceCaps(hdc, LOGPIXELSY));
> -	lpMFP->hMF = hmf;
> -	ReleaseDC(hwnd, hdc);
> -	GlobalUnlock(hGMem);
> -
>  	OpenClipboard(hwnd);
>  	EmptyClipboard();
> -	SetClipboardData(CF_METAFILEPICT,hGMem);
> +	SetClipboardData(CF_ENHMETAFILE,hemf);
>  	SetClipboardData(CF_BITMAP, bitmap);
>  	CloseClipboard();
> +	ReleaseDC(hwnd, hdc);
> +	DeleteEnhMetaFile(hemf);
>  	return;
>  }
>  
> @@ -2244,6 +2238,15 @@
>  			break;
>  		case WM_KEYDOWN:
>  			{
> +			if (GetKeyState(VK_CONTROL) < 0) {
> +				switch(wParam) {
> +				case 'C':
> +					/* Ctrl-C: Copy to Clipboard */
> +					SendMessage(hwnd,WM_COMMAND,M_COPY_CLIP,0L);
> +					break;
> +				} /* switch(wparam) */
> +			} /* if(Ctrl) */
> +			else {
>  				/* First, look for a change in modifier status */
>  				unsigned int modifier_mask = 0;
>  				modifier_mask = ((GetKeyState(VK_SHIFT) < 0) ? Mod_Shift : 0 )
> @@ -2254,6 +2257,7 @@
>  					last_modifier_mask = modifier_mask;
>  				}
>  			}
> +			}
>  			switch (wParam) {
>  			case VK_BACK:
>  				Wnd_exec_event(lpgw, lParam, GE_keypress, GP_BackSpace);
> diff --git a/term/win.trm b/term/win.trm
> --- a/term/win.trm
> +++ b/term/win.trm
> @@ -982,7 +982,7 @@
>  " `Color` when checked enables color linestyles.  When unchecked it forces",
>  " monochrome linestyles.",
>  "",
> -" `Copy to Clipboard` copies a bitmap and a Metafile picture.",
> +" `Copy to Clipboard` copies a bitmap and an enhanced Metafile picture.",
>  "",
>  " `Background...` sets the window background color.",
>  "",
> 


--------------------------------------
VANCOUVER 2010 Olympic News [Yahoo! Sports/sportsnavi]
http://pr.mail.yahoo.co.jp/olympic/

Re: Add 'size' and 'position' to windows terminal options

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

Hello

Thank you for your efforts.

It will be quite nice!! the windows terminal has the options of size and position.

I have applied your patch and upload binary on the web.
http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/


sizedefines the width and height of the window in pixel and positionthe origin of the window i.e.the
position of the top left corner on the screen (again in pixel).Both these options override the default
settings from the WGNUPLOT.INI file (see below).


gnuplot> set term win size 1024, 768 position 200, 200
Terminal type set to 'windows'
Options are 'color noenhanced font "Arial, 10"'
gnuplot> plot sin(x)

However size are small compared to that expected (t) and position option was not changed.

Regards

Tatsuro

--- Benjamin Lindner  wrote:

> Hello,
> 
> I'd like to propose the addition of a 'size' and 'position' option
> to the windows terminal.
> This would fit very nicely in the possibility to position the
> plotting figure from octave on screen when using the gnuplot plotting 
> backend.
> 
> I attached a patch which accomplishes it.
> Comments?
> 
> benjamin
> > add size option to windows terminal
> 
> diff --git a/term/win.trm b/term/win.trm
> --- a/term/win.trm
> +++ b/term/win.trm
> @@ -125,7 +125,8 @@
>  /* Interface routines - create list of actions for Windows */
>  
>  enum WIN_id { WIN_DEFAULT, WIN_MONOCHROME, WIN_COLOR, WIN_GTITLE,
> -	      WIN_ENHANCED, WIN_NOENHANCED, WIN_FONT, WIN_OTHER };
> +	      WIN_ENHANCED, WIN_NOENHANCED, WIN_FONT, WIN_SIZE, 
> +	      WIN_POSITION, WIN_OTHER };
>  
>  static struct gen_table WIN_opts[] =
>  {
> @@ -137,6 +138,8 @@
>      { "enh$anced", WIN_ENHANCED },
>      { "font", WIN_FONT },
>      { "ti$tle", WIN_GTITLE },
> +    { "siz$e", WIN_SIZE },
> +    { "pos$ition", WIN_SIZE },
>      { NULL, WIN_OTHER }
>  };
>  
> @@ -196,6 +199,42 @@
>  	    term->flags |= TERM_MONOCHROME;
>  	    c_token++;
>  	    break;
> +	case WIN_SIZE:
> +	{
> +	    c_token++;
> +	    int win_width = 0;
> +	    int win_height = 0;
> +	    if (END_OF_COMMAND)
> +		int_error(c_token,"size requires 'width,heigth'");
> +	    win_width = real_expression();
> +	    if (!equals(c_token++,","))
> +		int_error(c_token,"size requires 'width,heigth'");
> +	    win_height = real_expression();
> +	    if (win_width < 1 || win_height < 1)
> +		int_error(c_token, "size is out of range");
> +	    
> +	    graphwin.Size.x = win_width;
> +	    graphwin.Size.y = win_height + graphwin.statuslineheight;
> +	    break;
> +	}
> +	case WIN_POSITION:
> +	{
> +	    c_token++;
> +	    int win_x = 0;
> +	    int win_y = 0;
> +	    if (END_OF_COMMAND)
> +		int_error(c_token,"position requires 'x,y'");
> +	    win_x = real_expression();
> +	    if (!equals(c_token++,","))
> +		int_error(c_token,"position requires 'x,y'");
> +	    win_y = real_expression();
> +	    if (win_x < 1 || win_y < 1)
> +		int_error(c_token, "position is out of range");
> +	    
> +	    graphwin.Origin.x = win_x;
> +	    graphwin.Origin.y = win_y;
> +	    break;
> +	}
>  	case WIN_COLOR:
>  	    graphwin.color = TRUE;
>  	    term->flags &= ~TERM_MONOCHROME;
> @@ -949,12 +988,18 @@
>  "                            {enhanced | noenhanced}",
>  "                            {{font} \"fontname{,fontsize}\" {<fontsize>}}",
>  "                            {title \"Plot Window Title\"}",
> +"                            {size <width>,<height>}",
> +"                            {position <x>,<y>}",
>  "",
>  " where `color` and `monochrome` select colored or mono output,", 
>  " `enhanced` enables enhanced text mode features (subscripts,",
>  " superscripts and mixed fonts). See `enhanced` for more information.",
>  " `\"<fontname>\"` is the name of a valid Windows font, and `<fontsize>`",
>  " is the size of the font in points.",
> +" `size` defines the width and height of the window in pixel and `position`",
> +" the origin of the window i.e. the position of the top left corner on the",
> +" screen (again in pixel). Both these options override the default settings",
> +" from the WGNUPLOT.INI file (see below).",
>  "",
>  " Other options may be set with the graph-menu or the initialization file.",
>  "",
> > ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 


--------------------------------------
VANCOUVER 2010 Olympic News [Yahoo! Sports/sportsnavi]
http://pr.mail.yahoo.co.jp/olympic/

Re: towards 4.4

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

> Well, actually, for a windows GUI application Ctrl+C means "copy to 
> clipboard" That has been so since I don't know when, and I believe that a 
> decent GUI application should follow the commonly used basic shortcuts. 
> Coming from the windows world I find it more confusing if an application 
> does not follow these "standards". It's like Ctrl+O meaning "Open", Ctrl+S 
> "save", Ctrl+C copy-to-clipboard, Ctrl+V paste-from-clipboard, F1 meaning 
> "help" etc

Well, there is possibly a funny story about copy and paste? It is 
Ctrl-Insert and Shift-Insert for ages. On Mac it is Apple-C and Apple-V. 
When has M$ got an idea it's too difficult for people to press the Insert 
key ... and Win key was on available on old keyboards? The -Insert shortcuts 
are still working even they seem not to be documented!

> > Should we give up on trying to make Ctrl-C == "break to command line"
> > work under Windows?
> 
> One has to distinguish *which* application window we are
> talking about.
> The shortcut I implemented in the patch concerns the graph window only.
> The text window (showing the prompt and doing the user-input) has a 
> separate keyboard-shortcut handling queue. And Pressing Ctrl+C within
> the text window can have a completely different meaning than in the
> graph window. And the text window then can be either the console OR 
> again a graphical window (for the GUI application).
> 
> Pressing Ctrl+C in the GUI-text window currently has no effect, but
> pressing ESC bails to the "command line" (as it is a gui application 
> there's no real command line in a console sense)
> - again like I'd expect from a windows application (yes, talking about 
> "standards" again...)

Ctrl-C in graph window should copy graph to clipboard (win, wxt, ...).

In command window, it has to break the command.

---
PM

Re: Windows terminal ignores fontname+size of labels

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

On Sunday 07 February 2010, Benjamin Lindner wrote:
> Ethan Merritt wrote:
> > On Sunday 07 February 2010, Benjamin Lindner wrote:
> >> Hello,
> >>
> >> Working on the copy-to-clipboard-as-emf issue I stumbled over the
> >> bug that the windows terminal obviously ignores the font name and size
> >> specified for labels and instead uses the default terminal's font
> >> and size.
> > 
> > Huh.  Does the "enhancedtext.dem" demo not work under [real] Windows?
> > It works from the Windows terminal when run under linux+wine.
> 
> Yes it works, but none of the demos contain a "set label" with explicit 
> fontname/size. *this* does not work.

Ah. I misunderstood.
  
I thought you were talking about the  enhanced text constructs, as in 
  set label 11 "{/Symbol=18 \362@_{/=9.6 0}^{/=12 ^\245}} {e^{-{/Symbol m}^2/2} d}"
where both the font and the size are correctly selected.
 
> >> To reproduce:
> >>
> >> set term windows enhanced font "arial,9"
> >> set label 1 "e^{i{/symbol p}}=-1" at graph 0.5,0.5 font "courier,15"
> >> plot sin(x) with linespoints
> > 
> > Works properly under linux+wine using wgnuplot from Oct 2009.
> > Could it be a font path problem?
> 
> Ah, there is one catch: it should read "courier new,15".
> But then it still only works with the patch applied,
> with the 4.4.0-rc1 binaries, it does neither change the font name nor 
> the font size.

OK.

Petr:  
  Are you collecting the patches from Benjamin Lindner and
Tatsuro Matsuoka for application to 4.4?

	Ethan

Re: Windows terminal ignores fontname+size of labels

[Benjamin L. <lin...@gm...>]

Ethan Merritt wrote:
> On Sunday 07 February 2010, Benjamin Lindner wrote:
>> Hello,
>>
>> Working on the copy-to-clipboard-as-emf issue I stumbled over the
>> bug that the windows terminal obviously ignores the font name and size
>> specified for labels and instead uses the default terminal's font
>> and size.
> 
> Huh.  Does the "enhancedtext.dem" demo not work under [real] Windows?
> It works from the Windows terminal when run under linux+wine.

Yes it works, but none of the demos contain a "set label" with explicit 
fontname/size. *this* does not work.

>> To reproduce:
>>
>> set term windows enhanced font "arial,9"
>> set label 1 "e^{i{/symbol p}}=-1" at graph 0.5,0.5 font "courier,15"
>> plot sin(x) with linespoints
> 
> Works properly under linux+wine using wgnuplot from Oct 2009.
> Could it be a font path problem?

Ah, there is one catch: it should read "courier new,15".
But then it still only works with the patch applied,
with the 4.4.0-rc1 binaries, it does neither change the font name nor 
the font size.

So no, I don't think it's a font path issue.
It works fine if the label is set to "noenhanced".
But with enhanced text it ignores the explicit specifications.

benjamin

Re: towards 4.4

[Benjamin L. <lin...@gm...>]

Ethan Merritt wrote:
> On Sunday 07 February 2010, Benjamin Lindner wrote:
>> Tatsuro MATSUOKA wrote:
>>> Hello
>>>
>>> I have tried the patch.
>>>
>>> set term windows enhanced font ",14"
>>> set label 1 "e^{i{/symbol p}} = -1" at graph 0.1,0.5
>>> plot sin(x) with linespoints, cos(x) with linespoints
>>>
>>> worked fine!!!!!!!.
>>>
>>>
>>> However,  I have tried
>>> set xrange [-pi:pi]
>>> set yrange [-pi:pi]
>>> splot sin(x*x+y*y)/(x*x+y*y)
>>>
>>> was broken as a attachment file.
>> Thanks for the report.
>>
>> I modified my patch and now I see the expected behaviour
>> with plot (lines + image), splot (surface+pm3d).
> 
> Very good. 
> 
>> I also added the keyboard shortcut Ctrl+C for copying to clipboard.
> 
> Er...
> Ctrl+C is currently documented as having another, quite different meaning.
> True, it apparently isn't working properly under Windows,
> but re-assigning it to "copy to clipboard" further confuses the issue.

Well, actually, for a windows GUI application Ctrl+C means "copy to 
clipboard"
That has been so since I don't know when, and I believe that a decent
GUI application should follow the commonly used basic shortcuts.
Coming from the windows world I find it more confusing if an application
does not follow these "standards".
It's like Ctrl+O meaning "Open", Ctrl+S "save", Ctrl+C 
copy-to-clipboard, Ctrl+V paste-from-clipboard, F1 meaning "help" etc

So having the feature that copies something to clipboard I think it
should have the shortcut Ctrl+C.

I know that in the non-windows world it has a completely different
interpretation, but it's a windows GUI application here, and I think
it should follow windows' behaviour.

> Actually, now that I think about it...
> Is it possible that the reason Ctrl+C is having problems is that
> some layer is trying to interpret it as "copy" at the same time
> another layer is trying to interpret it as "break to command line"?

I can't really tell...

> Should we give up on trying to make Ctrl-C == "break to command line"
> work under Windows?

One has to distinguish *which* application window we are
talking about.
The shortcut I implemented in the patch concerns the graph window only.
The text window (showing the prompt and doing the user-input) has a 
separate keyboard-shortcut handling queue. And Pressing Ctrl+C within
the text window can have a completely different meaning than in the
graph window. And the text window then can be either the console OR 
again a graphical window (for the GUI application).

Pressing Ctrl+C in the GUI-text window currently has no effect, but
pressing ESC bails to the "command line" (as it is a gui application 
there's no real command line in a console sense)
- again like I'd expect from a windows application (yes, talking about 
"standards" again...)

benjamin

Re: Windows terminal ignores fontname+size of labels

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

On Sunday 07 February 2010, Benjamin Lindner wrote:
> Hello,
> 
> Working on the copy-to-clipboard-as-emf issue I stumbled over the
> bug that the windows terminal obviously ignores the font name and size
> specified for labels and instead uses the default terminal's font
> and size.

Huh.  Does the "enhancedtext.dem" demo not work under [real] Windows?
It works from the Windows terminal when run under linux+wine.

> To reproduce:
> 
> set term windows enhanced font "arial,9"
> set label 1 "e^{i{/symbol p}}=-1" at graph 0.5,0.5 font "courier,15"
> plot sin(x) with linespoints

Works properly under linux+wine using wgnuplot from Oct 2009.
Could it be a font path problem?

	Ethan

> Searching the code I found that in win.trm indeed the font is explicitly
> reverted to the terminal's default before processing the text output ?
> 
> If I remove this statement, at least the size is working as expected, 
> but the font name still is ignored?
> 
> benjamin
> 
> diff --git a/term/win.trm b/term/win.trm
> --- a/term/win.trm
> +++ b/term/win.trm
> @@ -894,7 +894,7 @@
> 
>   	/* This will restore the default font
>   	   and update WIN_font and WIN_fontsize */
> -	WIN_set_font(NULL);
> +	/*WIN_set_font(NULL); */
> 
>   	/* Set the recursion going. We say to keep going until a
>   	* closing brace, but we don't really expect to find one.

Re: towards 4.4

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

On Sunday 07 February 2010, Benjamin Lindner wrote:
> Tatsuro MATSUOKA wrote:
> > Hello
> > 
> > I have tried the patch.
> > 
> > set term windows enhanced font ",14"
> > set label 1 "e^{i{/symbol p}} = -1" at graph 0.1,0.5
> > plot sin(x) with linespoints, cos(x) with linespoints
> > 
> > worked fine!!!!!!!.
> > 
> > 
> > However,  I have tried
> > set xrange [-pi:pi]
> > set yrange [-pi:pi]
> > splot sin(x*x+y*y)/(x*x+y*y)
> > 
> > was broken as a attachment file.
> 
> Thanks for the report.
> 
> I modified my patch and now I see the expected behaviour
> with plot (lines + image), splot (surface+pm3d).

Very good. 

> I also added the keyboard shortcut Ctrl+C for copying to clipboard.

Er...
Ctrl+C is currently documented as having another, quite different meaning.
True, it apparently isn't working properly under Windows,
but re-assigning it to "copy to clipboard" further confuses the issue.

Actually, now that I think about it...
Is it possible that the reason Ctrl+C is having problems is that
some layer is trying to interpret it as "copy" at the same time
another layer is trying to interpret it as "break to command line"?

Should we give up on trying to make Ctrl-C == "break to command line"
work under Windows?


	Ethan

> 
> benjamin
> 
> 
> 

Add 'size' and 'position' to windows terminal options

[Benjamin L. <lin...@gm...>]

Hello,

I'd like to propose the addition of a 'size' and 'position' option
to the windows terminal.
This would fit very nicely in the possibility to position the
plotting figure from octave on screen when using the gnuplot plotting 
backend.

I attached a patch which accomplishes it.
Comments?

benjamin

Windows terminal ignores fontname+size of labels

[Benjamin L. <lin...@gm...>]

Hello,

Working on the copy-to-clipboard-as-emf issue I stumbled over the
bug that the windows terminal obviously ignores the font name and size
specified for labels and instead uses the default terminal's font
and size.

To reproduce:

set term windows enhanced font "arial,9"
set label 1 "e^{i{/symbol p}}=-1" at graph 0.5,0.5 font "courier,15"
plot sin(x) with linespoints

Searching the code I found that in win.trm indeed the font is explicitly
reverted to the terminal's default before processing the text output ?

If I remove this statement, at least the size is working as expected, 
but the font name still is ignored?

benjamin

diff --git a/term/win.trm b/term/win.trm
--- a/term/win.trm
+++ b/term/win.trm
@@ -894,7 +894,7 @@

  	/* This will restore the default font
  	   and update WIN_font and WIN_fontsize */
-	WIN_set_font(NULL);
+	/*WIN_set_font(NULL); */

  	/* Set the recursion going. We say to keep going until a
  	* closing brace, but we don't really expect to find one.

Re: towards 4.4

[Benjamin L. <lin...@gm...>]

Tatsuro MATSUOKA wrote:
> Hello
> 
> I have tried the patch.
> 
> set term windows enhanced font ",14"
> set label 1 "e^{i{/symbol p}} = -1" at graph 0.1,0.5
> plot sin(x) with linespoints, cos(x) with linespoints
> 
> worked fine!!!!!!!.
> 
> 
> However,  I have tried
> set xrange [-pi:pi]
> set yrange [-pi:pi]
> splot sin(x*x+y*y)/(x*x+y*y)
> 
> was broken as a attachment file.

Thanks for the report.

I modified my patch and now I see the expected behaviour
with plot (lines + image), splot (surface+pm3d).

I also added the keyboard shortcut Ctrl+C for copying to clipboard.

benjamin

Re: Old bug, new problem

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

> It seems that the code implementing "index" has been broken since
  at least version 3.7.   It always loads one too many data points.
  This is most easily seen by selecting table output.

  Here is output from gnuplot v3.7, but it is the same in current CVS.
  ==========
  gnuplot> set term table
  gnuplot> plot '-' index 0 using 1:2

  0 0 u


It seems that the added artificial point
  0 0 u
is always the same whichever data come afterwards.

---
PM

Old bug, new problem

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

It seems that the code implementing "index" has been broken since
at least version 3.7.   It always loads one too many data points.
This is most easily seen by selecting table output.

Here is output from gnuplot v3.7, but it is the same in current CVS.
==========
gnuplot> set term table
gnuplot> plot '-' index 0 using 1:2
1 1.
2 2.
3 3.


4 4.
e
#Curve 0, 4 points
#x y type
1 1 i
2 2 i
3 3 i
0 0 u

===========

If you are simply plotting the points, this error is usually hidden
because the extra point is marked UNDEFINED and doesn't appear in the graph.
But if you actually care about the exact number of points in the data set,
it is a problem.

The new (CVS only) plot style "with boxplot" does care about the number of
points, and this bug triggered a report from Péter Juhász about boxplot
errors.  But the underlying bug is not specific to the plot style,
and the fix must surely belong in the "index" handling code.

Now I am on shaky ground.
Where does the fix go, exactly?

Maybe df_readascii() in datafile.c needs to explicitly return
DF_SECOND_BLANK rather than DF_EOF in places 
like this:
               /* Found two blank lines after a block of data with a named index */
                if (indexname && index_found) {
                    df_eof = 1;
                    return DF_EOF;
                }
and this:
                /* df_upper_index is MAXINT-1 if we are not doing index */
                if (df_current_index > df_upper_index) {
                    /* oops - need to gobble rest of input if mixed */
                    if (mixed_data_fp)
                        continue;
                    else {
                        df_eof = 1;
                        return DF_EOF;  /* no point continuing */
                    }
                }

Or maybe it is OK to simply strip undefined points from the end of
all data sets?

--- cvs/gnuplot/src/plot2d.c      2010-01-12 19:04:51.000000000 -0800
+++ test/gnuplot/src/plot2d.c  2010-02-05 15:18:34.000000000 -0800
@@ -926,6 +926,9 @@ images:

     }                           /*while */

+    /* Trim off extra point at end of indexed data */
+    if (current_plot->points[i-1].type == UNDEFINED)
+       i--;
     current_plot->p_count = i;
     cp_extend(current_plot, i); /* shrink to fit */

That simple patch does seem to solve the boxplot problem.

Maybe both of these changes, along with a new point type that is
set when the second blank line is encountered?
	INRANGE/OUTRANGE/UNDEFINED/DATASET_SEPARATOR

	Ethan

-- 
Ethan A Merritt

OSS Usability

[Arif R. <ar...@uw...>]

Hi there

Please find below a link to a survey related to my PhD research work to evaluate OSS usability improvement from Industry Perspective.
It shall not not take more than 5 minutes of your precious time. 
Your identity is neither required nor recorded. The participation is highly valued and appreciated.
 
http://www.kwiksurveys.com/online-survey.php?surveyID=BOHMN_8d5c35f8

Thank you and Best Regards

Arif Raza

Re: towards 4.4

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

Hello

I have tried the patch.

set term windows enhanced font ",14"
set label 1 "e^{i{/symbol p}} = -1" at graph 0.1,0.5
plot sin(x) with linespoints, cos(x) with linespoints

worked fine!!!!!!!.


However,  I have tried
set xrange [-pi:pi]
set yrange [-pi:pi]
splot sin(x*x+y*y)/(x*x+y*y)

was broken as a attachment file.

Perhaps the patch seems not to work correct for splot.

Regards

Tatsuro
Tatsuro
--- Benjamin Lindner <lin...@gm...> wrote:

> > > 
> > > One observation on gnuplot 4.4: this list has been much taken up
> > > with somewhat arcane problems on Windows. 
> > 
> > That's 'cos Windows is in the worst shape.
> 
> nevertheless gnuplot works very nicely, and it's good to have it
> avilable, so bear with us windows users ...
> 
> Back to the copy-to-clipboard-as-emf issue.
> 
> I have attached a patch, which (for the current 4.5.0 CVS sources)
> creates an enhanced metafile instead of a metafile and stores
> this in the clipboard. It still has some debugging statements 
> included, so it's a testing version of a patch.
> 
> set term windows enhanced font ",14"
> set label 1 "e^{i{/symbol p}} = -1" at graph 0.1,0.5
> plot sin(x) with linespoints, cos(x) with linespoints
> 
> This works for me using wxp and microsoft word (see png) even with 
> enhanced text.
> 
> (BTW you can still paste as simple metafile if you like, since
> windows can obviously convert on-the-fly between the two)
> 
> It would be interesting to see if this also works on other systems.
> 
> benjamin
> -- 
> Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
> sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser
> > ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 


--------------------------------------
VANCOUVER 2010 Olympic News [Yahoo! Sports/sportsnavi]
http://pr.mail.yahoo.co.jp/olympic/

Re: towards 4.4

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

Hello

--- Ethan Merritt wrote:

> On Wednesday 03 February 2010, Benjamin Lindner wrote:
> > > > 
> > > > One observation on gnuplot 4.4: this list has been much taken up
> > > > with somewhat arcane problems on Windows. 
> > > 
> > > That's 'cos Windows is in the worst shape.
> > 
> > nevertheless gnuplot works very nicely, and it's good to have it
> > avilable, so bear with us windows users ...
> 
> I think you may have misunderstood me.
> The point is that fewer people are working on the Windows-specific
> parts of gnuplot, so the code is in worse shape than the more
> general routines.  I consider it a good thing that the list has
> recently attracted more discussion of Windows problems, because
> that's where the attention is most needed.


As for the pause mouse routine for 'pause mouse' that I have worked on it with Petr, the code for
windows seems to be not smart.  In my idea, it is better described it in win.trm and wxt.trm (or
wxt_gui.cpp) and the part of platform dependent code is better to be small as possible.

If people agree it, I'll try the change.

Regards

Tatsuro

--------------------------------------
VANCOUVER 2010 Olympic News [Yahoo! Sports/sportsnavi]
http://pr.mail.yahoo.co.jp/olympic/

Re: towards 4.4

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

On Wednesday 03 February 2010, Benjamin Lindner wrote:
> > > 
> > > One observation on gnuplot 4.4: this list has been much taken up
> > > with somewhat arcane problems on Windows. 
> > 
> > That's 'cos Windows is in the worst shape.
> 
> nevertheless gnuplot works very nicely, and it's good to have it
> avilable, so bear with us windows users ...

I think you may have misunderstood me.
The point is that fewer people are working on the Windows-specific
parts of gnuplot, so the code is in worse shape than the more
general routines.  I consider it a good thing that the list has
recently attracted more discussion of Windows problems, because
that's where the attention is most needed.

> I have attached a patch, which (for the current 4.5.0 CVS sources)
> creates an enhanced metafile instead of a metafile and stores
> this in the clipboard. It still has some debugging statements 
> included, so it's a testing version of a patch.
> 
> set term windows enhanced font ",14"
> set label 1 "e^{i{/symbol p}} = -1" at graph 0.1,0.5
> plot sin(x) with linespoints, cos(x) with linespoints
> 
> This works for me using wxp and microsoft word (see png) even with 
> enhanced text.

Sounds good!

	Ethan

Re: towards 4.4

[Benjamin L. <lin...@gm...>]

> > 
> > One observation on gnuplot 4.4: this list has been much taken up
> > with somewhat arcane problems on Windows. 
> 
> That's 'cos Windows is in the worst shape.

nevertheless gnuplot works very nicely, and it's good to have it
avilable, so bear with us windows users ...

Back to the copy-to-clipboard-as-emf issue.

I have attached a patch, which (for the current 4.5.0 CVS sources)
creates an enhanced metafile instead of a metafile and stores
this in the clipboard. It still has some debugging statements 
included, so it's a testing version of a patch.

set term windows enhanced font ",14"
set label 1 "e^{i{/symbol p}} = -1" at graph 0.1,0.5
plot sin(x) with linespoints, cos(x) with linespoints

This works for me using wxp and microsoft word (see png) even with 
enhanced text.

(BTW you can still paste as simple metafile if you like, since
windows can obviously convert on-the-fly between the two)

It would be interesting to see if this also works on other systems.

benjamin
-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser

Re: towards 4.4 (pause for keyboard for gnuplot.exe on windows)

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

Hello

I have applied the patch for 'pause -1' to the current cvs source (Latest ChangeLog Date 2010-02-02)
and uploaded on the web.

http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/

Regards

Tatsuro


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

> Hello
> 
> --- Tatsuro MATSUOKA  wrote:
>  
> > I am now quite occupied due to the end of winter term of the university.
> > I will post the patch in the weekend.
> 
> Although I stated as the above, I have done it.
> 
> Only enter key breaks 'pause -1'. 
> 
> Regards
> 
> Tatsuro
> 
> 
> --------------------------------------
> VANCOUVER 2010 Olympic News [Yahoo! Sports/sportsnavi]
> http://pr.mail.yahoo.co.jp/olympic/


--------------------------------------
VANCOUVER 2010 Olympic News [Yahoo! Sports/sportsnavi]
http://pr.mail.yahoo.co.jp/olympic/

Re: towards 4.4

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

Hello

--- Allin Cottrell  wrote:

> One observation on gnuplot 4.4: this list has been much taken up
> with somewhat arcane problems on Windows.  My 2 cents is that it
> would be good to have 4.4 out as soon as possible just so long as
> there are no substantial regressions relative to 4.2 (given how
> much good stuff 4.4 contains).  I fear that waiting for perfection
> on "pause mouse" and company could be a recipe for indefinite
> postponement.

For 'pause mouse' problem for without the graph window is not serious for the windows terminal.
One can breaks 'pause mouse' without the graph window by pressing enter for windows terminal.
For wxt terminal, one cannot break it by the Enter key.

The problem is related to the CTRL+C problem for windows. If it will be fixed, the wxt terminal
problem will not be serious. 

However, if it cannot be fixed, it is better to go forward noting that 'pause mouse' problem for
without the graph window on wxt terminal for windows is known problem.

In practical sense, the situation of the graph window is disappeared is not caused in the ordinary
use, I think.

Regards

Tatsuro
Regards

Tatsuro

--------------------------------------
VANCOUVER 2010 Olympic News [Yahoo! Sports/sportsnavi]
http://pr.mail.yahoo.co.jp/olympic/

Re: towards 4.4

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

On Tuesday 02 February 2010, Allin Cottrell wrote:

> 
> One observation on gnuplot 4.4: this list has been much taken up
> with somewhat arcane problems on Windows. 

That's 'cos Windows is in the worst shape.

> My 2 cents is that it
> would be good to have 4.4 out as soon as possible just so long as
> there are no substantial regressions relative to 4.2 (given how
> much good stuff 4.4 contains).  I fear that waiting for perfection
> on "pause mouse" and company could be a recipe for indefinite
> postponement.

To be fair, people have been sending reports and patches to fix
build problems on other platforms as well.  But I've been kind of
busy, and haven't yet caught up with all of them.   

The target release date all along has been March (6 months after
4.2.6).  I think we can hit that target, though I am not sure
we will have a fully automated recipe for building from source
under OSX.

	Ethan

Re: towards 4.4

[Allin C. <cot...@wf...>]

On Tue, 2 Feb 2010, Ethan Merritt wrote:

> I am totally unfamiliar with the mechanisms for loading or dumping the
> MSWin clipboard. But that doesn't stop me from looking at the code :-)
>
> Two thoughts:
>
> In wgraph.c (CopyClip) line 1434:
> 	 hdc = CreateMetaFile((LPSTR)NULL);
>
> According to the on-line docs at msdn.microsoft.com, since 2000
> it is better to use CreateEnhMetaFile(), and if necessary
> convert this afterwards to a backwards compatible [unenhanced]
> metafile.  Can the clipboard not handle an enhanced metafile?

Yes, the Windows clipboard can handle enhanced metafiles, and
since we have a good driver for that format in emf.trm it would be
a good idea to make use of it. (I suspect -- though I admit I'm
winging it here -- that Windows could downgrade it to WMF if
needed for an archaic paste target that can't handle EMF.)

One observation on gnuplot 4.4: this list has been much taken up
with somewhat arcane problems on Windows.  My 2 cents is that it
would be good to have 4.4 out as soon as possible just so long as
there are no substantial regressions relative to 4.2 (given how
much good stuff 4.4 contains).  I fear that waiting for perfection
on "pause mouse" and company could be a recipe for indefinite
postponement.

Allin Cottrell

Re: towards 4.4 (pause for keyboard for gnuplot.exe on windows)

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

Hello

--- Tatsuro MATSUOKA  wrote:
 
> I am now quite occupied due to the end of winter term of the university.
> I will post the patch in the weekend.

Although I stated as the above, I have done it.

Only enter key breaks 'pause -1'. 

Regards

Tatsuro


--------------------------------------
VANCOUVER 2010 Olympic News [Yahoo! Sports/sportsnavi]
http://pr.mail.yahoo.co.jp/olympic/

Re: towards 4.4

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

On Monday 01 February 2010 13:37:04 Benjamin Lindner wrote:
> Hans-Bernhard Bröker wrote:
> > Benjamin Lindner wrote:
> > 
> > [about wgnuplot 4.4 candidate:]
> >> There is still one issue open I believe:
> >> - Copying to clipboard as metafile is broken.
> > 
> > Broken how, exactly?
> > 
> 
> in the way that the command
> 
>   plot sin(x) with linespoints, cos(x) with linespoints
> 
> produces the attached term window, but when doing Options->Copy to Clipboard
> and then pasting as Metafile in openoffice the result looks like the 
> second attachment.
> 
> benjamin

I am totally unfamiliar with the mechanisms for loading or dumping the
MSWin clipboard. But that doesn't stop me from looking at the code :-)

Two thoughts:

In wgraph.c (CopyClip) line 1434:
	 hdc = CreateMetaFile((LPSTR)NULL);

According to the on-line docs at msdn.microsoft.com, since 2000 it is better
to use CreateEnhMetaFile(), and if necessary convert this afterwards to a
backwards compatible [unenhanced] metafile.  Can the clipboard not handle 
an enhanced metafile?


I also notice the following in the current code, and I wonder if it explains
the lack of text output in your clipboard screenshots:

wgraph.c line 849:
    /* HBB 20010218: the GDI status query functions don't work on Metafile
     * handles, so can't know whether the screen is actually showing
     * color or not, if drawgraph() is being called from CopyClip().
     * Solve by defaulting isColor to 1 if hdc is a metafile. */
    isColor = (((GetDeviceCaps(hdc, PLANES) * GetDeviceCaps(hdc,BITSPIXEL))>2)
               || (GetDeviceCaps(hdc, TECHNOLOGY) == DT_METAFILE));


The comment indicates that GetDeviceCaps() can fail if the context is creation
of a metafile, as it is when loading the clipboard.  But then elsewhere in the
code....


wgraph.c (MakeFonts) 
line 661:
	lpgw->lf.lfHeight = -MulDiv(lpgw->fontsize, GetDeviceCaps(hdc, LOGPIXELSY), 72);
line 689:
       /* CMW: Base tick size on character size */
        lpgw->htic = lpgw->hchar / 2;
        cy = MulDiv(cx/20, GetDeviceCaps(hdc, LOGPIXELSY), GetDeviceCaps(hdc, LOGPIXELSX));
        lpgw->vtic = MulDiv(cy,lpgw->ymax,lprect->bottom - lprect->top);
        /* find out if we can rotate text 90deg */
        SelectObject(hdc, lpgw->hfontv);
        result = GetDeviceCaps(hdc, TEXTCAPS);

If the comment is correct, then maybe other places where there is a call to
GetDeviceCaps() must be modified to do something else during metafile creation. 
I.e., maybe the font size is being set to 0 because GetDeviceCaps() returns
something other than a useful screen resolution.


Finally, if the clipboard wants an enhanced metafile, is it possible that an
alternative approach is to replace CopyClip() with an equivalent to
      tmpgc = CreateEnhMetaFile(...)
      set term push
      set term emf [some new option to attach the output to tmpgc]
      replot
      set term pop


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

Re: save and multiplot

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

'save' is working as intended, it writes the last plot command to file:
http://www.gnuplot.info/docs/node153.html

in multiplot mode all plots are still individual plots which - in contrast
to normal plotting mode where each plot gets a fresh canvas - are
plotted to the same canvas.

to save all plot commands to file you may
- 'save' after each 'plot'
- 'print GPVAL_LAST_PLOT' after each 'plot'
the latter you may do using a small script which is 'call'ed instead
of the 'plot' command.


adhemar wrote:
> 
> Hello everybody,
> 
> I am unable to save all the "plot" commands that I've given inside the
> multiplot mode, but it appears to only save the last plot command that
> I've issued.
> 
> For example:
> 
> set multiplot layout 2,2
> plot x
> plot x**2
> plot x**3
> plot x**4
> save "example.gp"
> unset multiplot
> 
> produces a file containing a lot of settings and then only the last
> command, i.e. plot x**4.
> Is this working as intended? Is there a way to save all the plot commands
> I have given in multiplot mode?
> 
> Thank you.
> 
> 

-- 
View this message in context: http://old.nabble.com/save-and-multiplot-tp27413719p27417547.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.