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

lua/tikz terminal is implemented to cvs binary of DJGPP

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

Hello

As was seen in
http://sourceforge.net/tracker/?func=detail&aid=3440066&group_id=2055&atid=102055

snprintf issue was solved in DJGPP for context terminal.
Thus now we can support lua/tikz terminal on DJGPP.

I have updated cvs binary with lua/tikz terminal.

Regards

Tatsuro

getting svg js included

[<pl...@pi...>]

Hi,

I would like to have the possibility to make the active mouse features 
be included in svg file rather than as an external reference.

This is not always desirable but has significant advantages when sending 
svg output to collaborators where it adds a whole load of complex 
explanations if I have two separate files.

AFAIR this was the format when I originally submitted a patch with this 
kind of interactive behaviour for svg.

It would seem the best way to hook this into the existing structure 
would be a special value of the jsdir dir option to svg terminal.

eg.
set term svg jsdir="internal"

Before I dive in and start coding I would like to do something that fits 
in with current philosophy and that could be submitted as a patch for 
consideration.

Any comments or suggestions on how to go about this?

TIA, Peter.

auto scale not getting into scaling history.

[<pl...@pi...>]

Hi,

this is not a major issue but it's a bit annoying and seems illogical to 
the user (that is to say, me in this case ;) ).

If I zoom a plot , then autoscale then do a different zoom , the 
autoscale viewing is not getting into the view history.

if I now do P (or the equivalent button on wxt ) it jumps me from zoom 2 
back to zoom 1. I was expecting the autoscaled zoom level. It's a bit 
derouting and inconvienient since I normally find I do want to go back 
to the previous zoom level with P, not the one before.

Is there a special reason why the result of the autozoom cannot be 
inserted into the zoom history or is this an oversight?

best regards, Peter.

zoom selection not being full respected in ensuing zoom

[<pl...@pi...>]

Hi,

this is something I notices about 6 months ago. Don't know if it was a 
regression or I had never noticed it before.

If I select a zoom area with the mouse, the top , bottom and right hand 
coords are used but it does not always seem to catch the left hand one.

I think this is happening if there are several plot lines.

I have a plot with six lines showing this oddity but one with four that 
does not.

I have had a college report the same thing on windoze builds.

If that does not make sense I'll try to narrow it down a bit more.

regards, Peter.

Re: Suggestion: array should be supported

[gbliu <goo...@gm...>]

Thank you for your tips. But the using of word()  function is limitted 
to "words".
If a key title is a string with spaces, then the word() function can not 
be used.
Only array function can solve the problem perfectly.

In version 4.5, the loop and block are supported as new features:

7 	* NEW syntax supporting multi-line blocks of code delimited by curly 
braces
8 	if (<cond>) { ... } else { ... }
9 	do for [...] { ... }
10 	while (<cond>) { ... }


Now that loop is supportted, the absence of array will  limit the 
application of loop in significant measure.

So, I still highly suggest developers to add array support in the future.

gbliu


? 2011/11/19 4:30, Ethan A Merritt ??:
> On Friday, November 18, 2011 01:43:29 am gbliu wrote:
>> Dear all:
>>
>> These years gnuplot becomes more and more powerful. In sense, it's a
>> quasi-programming-language. String variable is supported since ver4.0, and {}
>> blocks and loops are supported in ver4.5. But a basic function, array, is still
>> not supported now. I think this is highly needed, especially when loops are
>> supported.
>>
>> ------------------------
>> e.g.
>>
>> I have a data file with many columns, but want to plot only some columns, say,
>> column 2, 3,6,7,9,15,24. And the lengeds for each column differ. Now, I can only
>> use the command as follow:
>>
>>
>> plot 'data' u 1:2 title '...', '' u 1:3 title '...', '' u 1:6 title '...',\
>>       ''     u 1:7 title '...', '' u 1:9 title '...', '' u 1:15 title '...',\
>>       ''     u 1:24 title '...'
>>
>> Although gnuplot support "plot for [i=...]" now, but it cannot be used here,
>> because the column numbers is not regular. In this case, array is needed to
>> simplify the plot command.
> Array support has been suggested before, but no one has stepped up to
> do the work :-)
>
> In your particular case it is possible to use the existing syntax
>
>   plot for [COL in "2 3 6 7 9 15 24"] 'data' using 1:(column(int(COL))
>
> Generalizing this a little bit, you could even do
>
>   COL = "2 3 6 7 9 15 24"
>   TITLE = "title2 title3 title6 title7 title9 title15 title24"
>
>   plot for [i=1:7] 'data' using 1:(column(int(word(COL,i)))) title word(TITLE,i)
>
>
> 	Ethan
>
>
>> Suppose there are two arrays, col and str:
>> col[1]=2;  str[1]='...'
>> col[2]=3;  str[2]='...'
>> col[3]=6;  str[3]='...'
>> col[4]=7;  str[4]='...'
>> col[5]=9;  str[5]='...'
>> col[6]=15; str[6]='...'
>> col[7]=24; str[7]='...'
>>
>> now, I can use the following more concise command:
>>
>> plot for [i=1:7] 'data' u 1:(column(col[i])) title str[i]
>>
>> ------------------------
>>
>> Therefore, array is highly suggested to be supportted by gnuplot!
>>
>> Yours, faithfully
>>
>> gbliu
>>
>

Re: Suggestion: array should be supported

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

On Friday, November 18, 2011 01:43:29 am gbliu wrote:
> Dear all:
> 
> These years gnuplot becomes more and more powerful. In sense, it's a
> quasi-programming-language. String variable is supported since ver4.0, and {}
> blocks and loops are supported in ver4.5. But a basic function, array, is still
> not supported now. I think this is highly needed, especially when loops are
> supported.
> 
> ------------------------
> e.g.
> 
> I have a data file with many columns, but want to plot only some columns, say,
> column 2, 3,6,7,9,15,24. And the lengeds for each column differ. Now, I can only
> use the command as follow:
> 
> 
> plot 'data' u 1:2 title '...', '' u 1:3 title '...', '' u 1:6 title '...',\
>      ''     u 1:7 title '...', '' u 1:9 title '...', '' u 1:15 title '...',\
>      ''     u 1:24 title '...'
> 
> Although gnuplot support "plot for [i=...]" now, but it cannot be used here,
> because the column numbers is not regular. In this case, array is needed to
> simplify the plot command.

Array support has been suggested before, but no one has stepped up to
do the work :-)

In your particular case it is possible to use the existing syntax

 plot for [COL in "2 3 6 7 9 15 24"] 'data' using 1:(column(int(COL))

Generalizing this a little bit, you could even do

 COL = "2 3 6 7 9 15 24"
 TITLE = "title2 title3 title6 title7 title9 title15 title24"

 plot for [i=1:7] 'data' using 1:(column(int(word(COL,i)))) title word(TITLE,i)


	Ethan


> 
> Suppose there are two arrays, col and str:
> col[1]=2;  str[1]='...'
> col[2]=3;  str[2]='...'
> col[3]=6;  str[3]='...'
> col[4]=7;  str[4]='...'
> col[5]=9;  str[5]='...'
> col[6]=15; str[6]='...'
> col[7]=24; str[7]='...'
> 
> now, I can use the following more concise command:
> 
> plot for [i=1:7] 'data' u 1:(column(col[i])) title str[i]
> 
> ------------------------
> 
> Therefore, array is highly suggested to be supportted by gnuplot!
> 
> Yours, faithfully
> 
> gbliu
> 

Suggestion: array should be supported

[gbliu <goo...@gm...>]

Dear all:

These years gnuplot becomes more and more powerful. In sense, it's a
quasi-programming-language. String variable is supported since ver4.0, and {}
blocks and loops are supported in ver4.5. But a basic function, array, is still
not supported now. I think this is highly needed, especially when loops are
supported.

------------------------
e.g.

I have a data file with many columns, but want to plot only some columns, say,
column 2, 3,6,7,9,15,24. And the lengeds for each column differ. Now, I can only
use the command as follow:


plot 'data' u 1:2 title '...', '' u 1:3 title '...', '' u 1:6 title '...',\
     ''     u 1:7 title '...', '' u 1:9 title '...', '' u 1:15 title '...',\
     ''     u 1:24 title '...'

Although gnuplot support "plot for [i=...]" now, but it cannot be used here,
because the column numbers is not regular. In this case, array is needed to
simplify the plot command.

Suppose there are two arrays, col and str:
col[1]=2;  str[1]='...'
col[2]=3;  str[2]='...'
col[3]=6;  str[3]='...'
col[4]=7;  str[4]='...'
col[5]=9;  str[5]='...'
col[6]=15; str[6]='...'
col[7]=24; str[7]='...'

now, I can use the following more concise command:

plot for [i=1:7] 'data' u 1:(column(col[i])) title str[i]

------------------------

Therefore, array is highly suggested to be supportted by gnuplot!

Yours, faithfully

gbliu

Re: Missing zlib1.dll

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

Hello

Thank you for your pointing out the packaging error.
I have add  zlib1.dll when I have updated binaries.

Regards

Tatsuro
--- On Tue, 2011/11/15, Kirill Kryukov  wrote:

> Dear Dr. Matsuoka,
> 
> "zlib1.dll" is missing in your latest gnuplot 4.5 binaries.
> 
> (From http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/ :
> 0001 gp45-winbin.zip, 10,499,767 bytes, 2011-11-15, md5sum
> 2fef6cba990c65ca0a7ca6dfd4a286e7,
> 0002 gp45-winbin-small.zip, 6,512,202 bytes, 2011-11-15, md5sum
> 981ec780b4620dae2fa41e3195f5739f)
> 
> Thanks a lot for preparing a Windows binary.
> 
> Best,
> Kirill
> 

Re: Your gnuplot source to compile under cygwin

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

Hello

I am using the source code downloaded from the cvs repository and no changes are applied to it.  

Perhaps you know the below
http://gnuplot.sourceforge.net/development/index.html

I have just carried out the described above.
One of the possibilities is the dependency libraries is not enough.
Error message is not shown so that I cannot tell you further.

Regards

Tatsuro

--- On Tue, 2011/11/15, Suchaneck, Andre  wrote:

> 
> 
> 
> Dear Mr. Matsuoka,
> 
> I tried to make some small changes in the gnuplot source to test a few things, but failed to compile the source code under Windows->cygwin.
> 
> In Linux everything works fine, but I need the changes in windows, so it is not caused by my changes – I also tried the original source code.
> 
> All errors I get are the same you already discussed in forums with the gnuplot developers (matherr, …) and all solutions yield to further errors.
> 
> Because of that I would like you to ask to send me your source code with all changes you used to compile your latest binaries, if possible.
> 
> Also the right command lines you used to compile would be very helpful in case I made a mistake there.
> 
> I would be very thankful!
> 
> Thanks in advance!
> 
>   
> 
> Regards,
> 
> Andre Suchaneck
> 
>   
> 
> =====================================================
> 
> Karlsruher Institut für Technologie (KIT) 
> 
> Institut für Industrielle Informationstechnik - IIIT
> 
>   
> 
> Dipl.-Ing. Andre Suchaneck
> 
> Wissenschaftlicher Mitarbeiter
> 
> Hertzstr. 16 - Geb. 06.35
> 
> 76187 Karlsruhe
> 
>   
> 
> Tel. +49 721 608-44515
> 
> Fax +49 721 608-44500
> 
> www.iiit.kit.edu
> 
>  
> 
> email: and...@ki...
> 
>   
> 
> KIT - Universität des Landes Baden-Württemberg und nationales Forschungszentrum in der Helmholtz-Gemeinschaft
> 
>   

Re: Version 4.4.4 released

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

Hello

I have built windows, cygwin and djgpp binaries ans made zip packages.

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

Please check the contents and Readme files.

Regards

Tatsuro


--- On Sun, 2011/11/13, sfeam wrote:

> The source tarball, release notes, and user manual for 
> gnuplot version 4.4.4 are now available on SourceForge.
> 
> Binary installation packages for Windows will follow later
> as usual. Please be patient, as these are prepared from the
> releases source by a separate set of volunteers.
> 
> This release was delayed somewhat by an unexpected flurry
> of bug reports + fixes against the development version that
> turned out to affect 4.4 as well.
> 
> The plan is that this will be the last incremental release
> in the 4.4 series.  Whether the next release gets labeled
> 4.6 or 5.0 is still under discussion.
> 
>     Ethan Merritt (sfeam) 
>     on behlf of the gnuplot development team
> 
> 
>                   GNUPLOT VERSION 4.4.4
>         ===================================
> 
> Version 4.4.4 is an incremental update to the current official release.
> 
> A synopsis of changes since the previous patchlevel (version 4.4.3)
> is given below and in the NEWS file.  Detailed information is in ChangeLog.
> 
> New features, changes and fixes in gnuplot version 4.4.4
> ========================================================
> 
> * NEW boxxyerrors plot style now allows variable color
> * NEW splot with pm3d now allows variable rgb color
> * NEW "nonuniform matrix" indicates ascii data with explicit x, y
> * CHANGE columnhead(N) is a string-valued function, not a keyword
> * CHANGE Demarcate plots in svg output using <g id="Plot_#"><title>...
> * CHANGE xticlabels() works for binary data files as well as ascii
> * CHANGE "set key maxrows" now applies to 3D plots as well as 2D
> * CHANGE rewrite installation path rules for TeX files
> * FIX wxt terminal should now work on at least some flavors of OSX
> * FIX incorrect space allowed for outside left key box
> * FIX buffer overflow from enhanced text timefmt tic labels
> * FIX correction for offset in epochs when reading in time format "%s"
> * FIX discontinuity in defined palette limited by maxcolors
> * FIX initialization of svg pattern-fill definitions
> * FIX positioning of histogram bars when some data entries are missing
> * FIX emf terminal can handle UTF-8 encoding
> * FIX User-specified axis tick labels override auto labels in 3D as in 2D
> * FIX `plot with labels` failed to skip labels with UNDEFINED coords
> * FIX NaN (not a number) implementation for Windows build
> * FIX work-around for poor scaling in pdfcairo pattern fill
> * FIX segfault if mismatch between palette sizes of successive terminals
> 
> 
>          NOTE TO PACKAGERS AND TESTERS 
>         ===============================
> 
> We strongly encourage you to build, test, and package the new cairo-based
> terminals. These are pngcairo and pdfcairo for output to file, and wxt as
> the default interactive terminal.  wxt should (at last!) work on OSX also.
> 
> This introduces dependencies on
>     libwxgtk2
>     libpangocairo
>     libpango
>     libcairo
> 
> Of course the terminals (output modes) used by previous gnuplot versions
> are also still available, including png output based on libgd and
> interactive output using X11.
> 
> Demo plots illustrating these and other features are online at
> 
>     http://gnuplot.sourceforge.net/demo/
> 
> You can download a source tarball for gnuplot version 4.4.3 from the 
> gnuplot development site on SourceForge.
> 
>     http://sourceforge.net/project/showfiles.php?group_id=2055
> 
> 
>                   OTHER NOTES
>         ===============================
> 
> Installation
> ------------
> Installation instructions are available in the source itself; the short
> version for linux/unix-like systems is to unpack the tarball and then
> build it:
>         cd gnuplot-4.4.4 ; ./configure ; make
> test it:
>         make check
> install it:
>         make install
> 
> Pay careful attention to the output of the ./configure script.
> It may indicate that some output drivers have been omitted because the
> necessary support libraries were not found.  In general you need to have
> previously installed the "*-devel-*" versions of these libraries. 
> 
> 
> Known issues
> ------------
> 
> - OSX:  Alpha-channel support in aquaterm requires aquaterm version 1.0.1,
> available from http://aquaterm.sourceforge.net
> Aquaterm itself may not work on 64-bit systems.
> 
> - External support library libgd version 2.0.36 introduces a new method
> of font selection using the fontconfig utitily.  However, it does not work
> properly without a patch to the upstream libgd source that has not yet made
> it into all packaged versions.   Here it is:
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> --- gd-2.0.36/gdft.c    2008-03-09 16:05:52.000000000 -0700
> +++ gd-2.0.36-mod/gdft.c        2009-05-20 20:22:13.000000000 -0700
> @@ -1661,7 +1661,7 @@ static char * font_path(char **fontpath,
>  BGD_DECLARE(int) gdFTUseFontConfig(int flag)
>  {
>  #ifdef HAVE_LIBFONTCONFIG
> -       fontConfigFlag = 1;
> +       fontConfigFlag = flag;
>         return 1;
>  #else
>         return 0;
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> 
> - The MS Windows terminal device sometimes draws with a dashed line
> when it should draw with a solid line. (Tracker item 1952364).
> Also it doesn't yet fully support alpha-channel output.
> 
> 
> Support
> -------
> Please report all bugs and installation problems to the bug tracker
> on SourceForge:
> 
>     http://sourceforge.net/tracker/?group_id=2055&atid=102055
> 
> There is also an active gnuplot discussion forum on usenet group
> 
>     comp.graphics.apps.gnuplot
> 
> Development
> -----------
> Gnuplot development is quite active. The development branch on SourceForge
> contains preliminary implementations of many new features.  The development
> branch is currently identified as version 4.5.
> Feedback and contributions of code are very welcome.
>    
> 
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Version 4.4.4 released

[sfeam (E. Merritt) <eam...@gm...>]

The source tarball, release notes, and user manual for 
gnuplot version 4.4.4 are now available on SourceForge.

Binary installation packages for Windows will follow later
as usual. Please be patient, as these are prepared from the
releases source by a separate set of volunteers.

This release was delayed somewhat by an unexpected flurry
of bug reports + fixes against the development version that
turned out to affect 4.4 as well.

The plan is that this will be the last incremental release
in the 4.4 series.  Whether the next release gets labeled
4.6 or 5.0 is still under discussion.

	Ethan Merritt (sfeam) 
	on behlf of the gnuplot development team


   	           GNUPLOT VERSION 4.4.4
	    ===================================

Version 4.4.4 is an incremental update to the current official release.

A synopsis of changes since the previous patchlevel (version 4.4.3)
is given below and in the NEWS file.  Detailed information is in ChangeLog.

New features, changes and fixes in gnuplot version 4.4.4
========================================================

* NEW boxxyerrors plot style now allows variable color
* NEW splot with pm3d now allows variable rgb color
* NEW "nonuniform matrix" indicates ascii data with explicit x, y
* CHANGE columnhead(N) is a string-valued function, not a keyword
* CHANGE Demarcate plots in svg output using <g id="Plot_#"><title>...
* CHANGE xticlabels() works for binary data files as well as ascii
* CHANGE "set key maxrows" now applies to 3D plots as well as 2D
* CHANGE rewrite installation path rules for TeX files
* FIX wxt terminal should now work on at least some flavors of OSX
* FIX incorrect space allowed for outside left key box
* FIX buffer overflow from enhanced text timefmt tic labels
* FIX correction for offset in epochs when reading in time format "%s"
* FIX discontinuity in defined palette limited by maxcolors
* FIX initialization of svg pattern-fill definitions
* FIX positioning of histogram bars when some data entries are missing
* FIX emf terminal can handle UTF-8 encoding
* FIX User-specified axis tick labels override auto labels in 3D as in 2D
* FIX `plot with labels` failed to skip labels with UNDEFINED coords
* FIX NaN (not a number) implementation for Windows build
* FIX work-around for poor scaling in pdfcairo pattern fill
* FIX segfault if mismatch between palette sizes of successive terminals


		 NOTE TO PACKAGERS AND TESTERS 
		===============================

We strongly encourage you to build, test, and package the new cairo-based
terminals. These are pngcairo and pdfcairo for output to file, and wxt as
the default interactive terminal.  wxt should (at last!) work on OSX also.

This introduces dependencies on
	libwxgtk2
	libpangocairo
	libpango
	libcairo

Of course the terminals (output modes) used by previous gnuplot versions
are also still available, including png output based on libgd and
interactive output using X11.

Demo plots illustrating these and other features are online at

	http://gnuplot.sourceforge.net/demo/

You can download a source tarball for gnuplot version 4.4.3 from the 
gnuplot development site on SourceForge.

	http://sourceforge.net/project/showfiles.php?group_id=2055


		          OTHER NOTES
		===============================

Installation
------------
Installation instructions are available in the source itself; the short
version for linux/unix-like systems is to unpack the tarball and then
build it:
		cd gnuplot-4.4.4 ; ./configure ; make
test it:
		make check
install it:
		make install

Pay careful attention to the output of the ./configure script.
It may indicate that some output drivers have been omitted because the
necessary support libraries were not found.  In general you need to have
previously installed the "*-devel-*" versions of these libraries. 


Known issues
------------

- OSX:  Alpha-channel support in aquaterm requires aquaterm version 1.0.1,
available from http://aquaterm.sourceforge.net
Aquaterm itself may not work on 64-bit systems.

- External support library libgd version 2.0.36 introduces a new method
of font selection using the fontconfig utitily.  However, it does not work
properly without a patch to the upstream libgd source that has not yet made
it into all packaged versions.   Here it is:
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
--- gd-2.0.36/gdft.c    2008-03-09 16:05:52.000000000 -0700
+++ gd-2.0.36-mod/gdft.c        2009-05-20 20:22:13.000000000 -0700
@@ -1661,7 +1661,7 @@ static char * font_path(char **fontpath,
 BGD_DECLARE(int) gdFTUseFontConfig(int flag)
 {
 #ifdef HAVE_LIBFONTCONFIG
-       fontConfigFlag = 1;
+       fontConfigFlag = flag;
        return 1;
 #else
        return 0;
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

- The MS Windows terminal device sometimes draws with a dashed line
when it should draw with a solid line. (Tracker item 1952364).
Also it doesn't yet fully support alpha-channel output.


Support
-------
Please report all bugs and installation problems to the bug tracker
on SourceForge:

	http://sourceforge.net/tracker/?group_id=2055&atid=102055

There is also an active gnuplot discussion forum on usenet group

	comp.graphics.apps.gnuplot

Development
-----------
Gnuplot development is quite active. The development branch on SourceForge
contains preliminary implementations of many new features.  The development
branch is currently identified as version 4.5.
Feedback and contributions of code are very welcome.
   

gnuplot manual misprint (no.36)

[Shigeharu T. <sh...@ie...>]

shige 11/10 2011
----------------

In docs/gnuplot.doc of current CVS version

 C RCS $Id: gnuplot.doc,v 1.699 2011/11/09 19:01:19 markisch Exp $

and in some terminal helps I found the following points which may
be typo: 

----- From here -----
diff -u docs/gnuplot.doc.ORG docs/gnuplot.doc
--- docs/gnuplot.doc.ORG	2011-11-10 08:33:17.000000000 +0900
+++ docs/gnuplot.doc	2011-11-10 14:52:28.000000000 +0900
@@ -284,7 +284,7 @@
 
  The `cairolatex` terminal uses the cairo backend of the `pdfcairo` or 
  `epscairo` terminal to produce graphs for inclusion in LaTeX documents. It
- creates png or eps graphics but transfers texts to LaTeX in the same way as
+ creates pdf or eps graphics but transfers texts to LaTeX in the same way as
  the `epslatex` terminal.
  
  The `windows` terminal driver has been largely revised. It now suports
@@ -10219,7 +10219,7 @@
 
  Automatic gamma correction via `set palette gamma <gamma>` can be done for
  gray maps (`set palette gray`) and for the `cubehelix` color palette schemes.
- Gamma = 1 produces a linear ramp of intensity. See `test palette`.
+ Gamma = 1 produces a linear map of intensity. See `test palette`.
 
  Many terminals support only discrete number of colors (e.g. 256 colors in gif).
  After the default gnuplot linetype colors are allocated, the rest of the
diff -u term/be.trm.ORG term/be.trm
--- term/be.trm.ORG	2011-08-03 09:41:54.000000000 +0900
+++ term/be.trm	2011-11-10 14:55:29.000000000 +0900
@@ -399,7 +399,7 @@
 "?be",
 "?BE",
 " The `be` terminal type is present if gnuplot is built for the `beos`",
-" operating system. for use with X servers.  It is selected at program",
+" operating system and for use with X servers.  It is selected at program",
 " startup if the `DISPLAY` environment variable is set, if the `TERM`",
 " environment variable is set to `xterm`, or if the `-display` command",
 " line option is used.",
diff -u term/cairo.trm.ORG term/cairo.trm
--- term/cairo.trm.ORG	2011-11-08 08:25:31.000000000 +0900
+++ term/cairo.trm	2011-11-10 15:04:45.000000000 +0900
@@ -1401,22 +1401,22 @@
 " LaTeX can typeset as an LR-box. \\rule{}{}'s may help for best positioning.",
 " See also the documentation for the `pslatex` terminal driver.",
 " To create multiline labels, use \\shortstack, for example",
-"    set ylabel '[r]{\\shortstack{first line \\\\ second line}}' ",
+"    set ylabel '[r]{\\shortstack{first line \\\\ second line}}'",
 "",
 " The `back` option of `set label` commands is handled slightly different",
 " than in other terminals. Labels using 'back' are printed behind all other",
-" elements of the plot while labels using 'front' are printed above ",
+" elements of the plot while labels using 'front' are printed above",
 " everything else.",
 "",
 " The driver produces two different files, one for the eps or pdf part of the",
 " figure and one for the LaTeX part. The name of the LaTeX file is taken from",
 " the `set output` command. The name of the eps/pdf file is derived by",
-" replacing the file extension (normally `.tex`) with `.eps` or `.pdf` instead.",
+" replacing the file extension (normally '.tex') with '.eps' or '.pdf' instead.",
 " There is no LaTeX output if no output file is given!  Remember to close the",
 " `output file` before next plot unless in `multiplot` mode.",
 "",
 " In your LaTeX documents use '\\input{filename}' to include the figure.",
-" The `.eps` or `.pdf` file is included by the command \\includegraphics{...},",
+" The '.eps' or '.pdf' file is included by the command \\includegraphics{...},",
 " so you must also include \\usepackage{graphicx} in the LaTeX preamble.  If",
 " you want to use coloured text (option `colourtext`) you also have to include",
 " \\usepackage{color} in the LaTeX preamble.",
@@ -1455,7 +1455,7 @@
 " LaTeX font name.  It contains up to three parts, separated by a comma:",
 " 'fontname,fontseries,fontshape'.  If the default fontshape or fontseries",
 " are requested, they can be omitted.  Thus, the real syntax for the fontname",
-" is '[fontname][,fontseries][,fontshape]'.  The naming convention for all",
+" is '{<fontname>}{,{<fontseries>}{,<fontshape>}}'. The naming convention for all",
 " parts is given by the LaTeX font scheme.  The fontname is 3 to 4 characters",
 " long and is built as follows: One character for the font vendor, two",
 " characters for the name of the font, and optionally one additional",
@@ -1486,14 +1486,14 @@
 " the math fonts you have to use the \"gnuplot.cfg\" file or the `header`",
 " option, described below.",
 "",
-" In standalone mode, the font size is taken from the given font size in the",
+" In `standalone` mode, the font size is taken from the given font size in the",
 " `set terminal` command. To be able to use a specified font size, a file",
 " \"size<size>.clo\" has to reside in the LaTeX search path.  By default,",
 " 10pt, 11pt, and 12pt are supported.  If the package \"extsizes\" is",
 " installed, 8pt, 9pt, 14pt, 17pt, and 20pt are added.",
 "",
 " The `header` option takes a string as argument.  This string is written",
-" into the generated LaTeX file.  If using the `standalone` mode, it is ",
+" into the generated LaTeX file.  If using the `standalone` mode, it is",
 " written into the preamble, directly before the \\begin{document} command.",
 " In the `input` mode, it is placed directly after the \\begingroup command",
 " to ensure that all settings are local to the plot.",
diff -u term/context.trm.ORG term/context.trm
--- term/context.trm.ORG	2011-11-08 08:25:31.000000000 +0900
+++ term/context.trm	2011-11-10 15:08:41.000000000 +0900
@@ -1980,7 +1980,7 @@
 " or to read the manual of the gnuplot module for ConTeXt.",
 "",
 " The `context` terminal supports the following options:",
-" ",
+"",
 " Syntax:",
 "      set term context {default}",
 "                       {defaultsize | size <scale> |",
@@ -2002,13 +2002,13 @@
 " In non-standalone (`input`) graphic only parameters `size` to select graphic",
 " size, `fontscale` to scale all the labels for a factor <fontscale>",
 " and font size, make sense, the rest is silently",
-" ignored and should be configured in the .tex file which inputs the graphic."
+" ignored and should be configured in the .tex file which inputs the graphic.",
 " It's highly recommended to set the proper fontsize if document font differs from",
 " 12pt, so that gnuplot will know how much space to reserve for labels.",
 "",
 " `default` resets all the options to their default values.",
 "",
-" `defaultsize` sets the plot size to 5in,3in.\n",
+" `defaultsize` sets the plot size to 5in,3in.",
 " `size` <scale> sets the plot size to <scale> times <default value>.",
 " If two arguments are given (separated with ','), the first one sets",
 " the horizontal size and the second one the vertical size.",
@@ -2016,7 +2016,7 @@
 " value), with inches ('in') or centimeters ('cm').",
 "",
 " `input` (default) creates a graphic that can be included into another ConTeXt",
-" document.\n",
+" document.",
 " `standalone` adds some lines, so that the document might be compiled as-is.",
 " You might also want to add `header` in that case.",
 "",
@@ -2038,11 +2038,11 @@
 " (Some general support for this should be added to Gnuplot, so that the same options",
 " could be set for each line (style) separately).",
 "",
-" `dashed` (default) uses different dash patterns for different line types,"
+" `dashed` (default) uses different dash patterns for different line types,",
 " `solid` draws all plots with solid lines.",
 "",
 " `dashlength` or `dl` scales the length of the dashed-line segments by <dl>.",
-" `linewidth` or `lw` scales all linewidths by <lw>."
+" `linewidth` or `lw` scales all linewidths by <lw>.",
 " (lw 1 stands for 0.5bp, which is the default line width when drawing with Metapost.)",
 " `fontscale` scales text labels for factor <fontscale> relative to default document font.",
 "",
@@ -2054,26 +2054,26 @@
 "",
 " `inlineimages` writes binary images to a string and only works in ConTeXt MKIV.",
 " `externalimages` writes PNG files to disk and also works with ConTeXt MKII.",
-" Gnuplot needs to have support for PNG images built in for this to work."
+" Gnuplot needs to have support for PNG images built in for this to work.",
 "",
 " With `font` you can set font name and size in standalone graphics.",
 " In non-standalone (`input`) mode only the font size is important",
 " to reserve enough space for text labels.",
-" The command"
+" The command",
 "      set term context font \"myfont,ss,10\"",
 " will result in",
 "      \\setupbodyfont[myfont,ss,10pt]",
 " If you additionaly set `fontscale` to 0.8 for example,",
 " then the resulting font will be 8pt big and",
 "      set label ... font \"myfont,12\"",
-" will come out as 9.6pt.\n",
+" will come out as 9.6pt.",
 " It is your own responsibility to provide proper typescripts (and header),",
-" otherwise switching the font will have no effect.\n",
+" otherwise switching the font will have no effect.",
 " For a standard font in ConTeXt MKII (pdfTeX) you could use:",
 "      set terminal context standalone header '\\usetypescript[iwona][ec]' \\",
 "          font \"iwona,ss,11\"",
 " Please take a look into ConTeXt documentation, wiki or mailing list (archives)",
-" for any up-to-date information about font usage."
+" for any up-to-date information about font usage.",
 "",
 " Examples:",
 "      set terminal context size 10cm, 5cm     # 10cm, 5cm",
diff -u term/win.trm.ORG term/win.trm
--- term/win.trm.ORG	2011-10-06 09:37:14.000000000 +0900
+++ term/win.trm	2011-11-10 15:10:59.000000000 +0900
@@ -921,7 +921,7 @@
 " gnuplot's interactive command line is accessible after the -persist option.",
 "",
 " The plot window remains open when the gnuplot terminal is changed with a",
-" `set term` command. The plot window can be closed with `set term windows close`",
+" `set term` command. The plot window can be closed with `set term windows close`.",
 "",
 " `gnuplot` supports different methods to create printed output on Windows,",
 " see `windows printing`. The windows terminal supports data exchange with ",
----- To here -----

+========================================================+
 Shigeharu TAKENO     NIigata Institute of Technology
                       kashiwazaki,Niigata 945-1195 JAPAN
 sh...@ie...   TEL(&FAX): +81-257-22-8161
+========================================================+

licence of new files in gnuplot repository

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

Hello,

Bastian asked me to change the licence of code before including it into gnuplot.

Are there any guidelines/long-term plans for switching to some
particular licence for the gnuplot project as a whole? What exactly
should I put on top of a new file?

Mojca

Re: default value of degree_sign on Japanese env.

[Shigeharu T. <sh...@ie...>]

shige 11/05 2011
----------------

Ethan A Merritt <sf...@us...> wrote:
| On Solaris 9 does iconv_open() accept "PCK" as an encoding name?
| We don't care what the name is, we only care that iconv() can use it.

Though Solaris's iconv accepts "PCK", it does not seem to admit
the translation from "ISO-8859-1" to "PCK" unfortunately. 
iconv_open() fails the translation.

GNU iconv may accept "PCK" if it is compiled with "-DUSE_SOLARIS_ALIAS".
It translates 0xb0 to 0x818b correctly.

+========================================================+
 Shigeharu TAKENO     NIigata Institute of Technology
                       kashiwazaki,Niigata 945-1195 JAPAN
 sh...@ie...   TEL(&FAX): +81-257-22-8161
+========================================================+

Re: default value of degree_sign on Japanese env.

[Ethan M. <eam...@gm...>]

2011/11/4 Bastian Märkisch <bma...@we...>:
> For the currently active locale you could also simply use wcrtomb() to
> convert.

If Solaris is reporting "PCK" instead of "Shift-JIS" in LC_CTYPE then
I would guess that wcrtomb and iconv either both fail or both work..
One would hope it would accept its own name convention!

I will try Shige's suggestion to use nl_langinfo().

         Ethan


>
>  Bastian
>
> Am 04.11.2011 08:54, schrieb Shigeharu TAKENO:
>>
>> shige 11/04 2011
>> ----------------
>>
>> Ethan A Merritt<sf...@us...>  wrote:
>> | I have revised the new code to use iconv() if it is available.
>> | I tested under linux by setting the locale to ja_JP.EUC-JP,
>> | which causes it to emit the character sequence \241 \353 (octal)
>> | which is 0xA1EB (hexidecimal).  But I don't have any EUC-JP fonts
>> | installed, so I cannot confirm if this is correct.
>>
>> The code 0xA1EB is correct for EUC-JP.
>>
>> Well, I think the idea
>>
>> +    if (locale) {
>> +       /* This should work even if gnuplot doesn't understand the
>> encoding */
>> +       char *encoding = strchr(locale, '.');
>> +       if (encoding) {
>> +           encoding++; /* Step past the dot in, e.g., ja_JP.EUC-JP */
>>
>> of src/set.c is not so good, since substrings of locale name
>> after '.' may not proper name of the character encoding. For
>> example, in Solaris 9,
>>
>>   EUC-JP enconding locale name = "ja", "ja_JP.EUC", "ja_JP.eucJP"
>>   Shift_JIS encoding locale name = "ja_JP.PCK"
>>   UTF-8 encoding locale name = "ja_JP.UTF-8"
>>
>> To obtain encoding codeset name of current locale, there seems to
>> be two methods:
>>
>> 1) Use nl_langinfo(CODESET) (#include<langinfo.h>)
>> 2) Use locale_charset() (#include<localcharset.h>) in libcharset,
>>   which is included in GNU libiconv.
>>
>> cf. http://www.haible.de/bruno/packages-libcharset.html
>>
>> On Solaris 9, nl_langinfo(CODESET) of system library returns:
>>
>>   locale = ja, ja_JP.eucJP =>  "eucJP"
>>   locale = ja_JP.PCK =>  "PCK"
>>
>> and locale_charset() of GNU libcharset returns:
>>
>>   locale = ja, ja_JP.eucJP =>  "EUC-JP"
>>   locale = ja_JP.PCK =>  "SHIFT_JIS"
>>
>> I think that names returned by locale_charset() may be better,
>> but libcharset may not be installed in default.
>>
>>
>> | If you build the new code, you can test it by saying
>> |    set encoding locale
>> |    show decimal
>>
>> Though it puts a incorrect string on "ja" locale, it works fine
>> on "ja_JP.eucJP" locale since iconv library admits "eucJP".
>>
>> +========================================================+
>>  Shigeharu TAKENO     NIigata Institute of Technology
>>                        kashiwazaki,Niigata 945-1195 JAPAN
>>  sh...@ie...   TEL(&FAX): +81-257-22-8161
>> +========================================================+
>
>

Re: default value of degree_sign on Japanese env.

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

 Shigeharu TAKENO <sh...@ie...> wrote

> On Solaris 9, nl_langinfo(CODESET) of system library returns:
>   locale = ja, ja_JP.eucJP => "eucJP"
>   locale = ja_JP.PCK => "PCK"

Thank you for mentioning nl_langinfo().  I did not know about that routine.

On Solaris 9 does iconv_open() accept "PCK" as an encoding name?
We don't care what the name is, we only care that iconv() can use it.

So if nl_langinfo(CODESET) returns "PCK"
and iconv_open( "PCK", "ISO-8859-1" ) works correctly
then this method seems OK.

We will have to check for nl_lanfinfo() in the configure script,
but that's not a problem.

	Ethan



> Ethan A Merritt <sf...@us...> wrote:
> | I have revised the new code to use iconv() if it is available.
> | I tested under linux by setting the locale to ja_JP.EUC-JP,
> | which causes it to emit the character sequence \241 \353 (octal)
> | which is 0xA1EB (hexidecimal).  But I don't have any EUC-JP fonts
> | installed, so I cannot confirm if this is correct.
> 
> The code 0xA1EB is correct for EUC-JP.
> 
> Well, I think the idea
> 
> +    if (locale) { 
> +       /* This should work even if gnuplot doesn't understand the encoding */
> +       char *encoding = strchr(locale, '.');
> +       if (encoding) {
> +           encoding++; /* Step past the dot in, e.g., ja_JP.EUC-JP */
> 
> of src/set.c is not so good, since substrings of locale name 
> after '.' may not proper name of the character encoding. For 
> example, in Solaris 9,
> 
>   EUC-JP enconding locale name = "ja", "ja_JP.EUC", "ja_JP.eucJP"
>   Shift_JIS encoding locale name = "ja_JP.PCK"
>   UTF-8 encoding locale name = "ja_JP.UTF-8"
> 
> To obtain encoding codeset name of current locale, there seems to
> be two methods:
> 
> 1) Use nl_langinfo(CODESET) (#include <langinfo.h>)
> 2) Use locale_charset() (#include <localcharset.h>) in libcharset,
>   which is included in GNU libiconv.
> 
> cf. http://www.haible.de/bruno/packages-libcharset.html
> 
> On Solaris 9, nl_langinfo(CODESET) of system library returns:
> 
>   locale = ja, ja_JP.eucJP => "eucJP"
>   locale = ja_JP.PCK => "PCK"
> 
> and locale_charset() of GNU libcharset returns:
> 
>   locale = ja, ja_JP.eucJP => "EUC-JP"
>   locale = ja_JP.PCK => "SHIFT_JIS"
> 
> I think that names returned by locale_charset() may be better,
> but libcharset may not be installed in default. 
> 
> 
> | If you build the new code, you can test it by saying
> |    set encoding locale
> |    show decimal
> 
> Though it puts a incorrect string on "ja" locale, it works fine
> on "ja_JP.eucJP" locale since iconv library admits "eucJP".
> 
> +========================================================+
>  Shigeharu TAKENO     NIigata Institute of Technology
>                        kashiwazaki,Niigata 945-1195 JAPAN
>  sh...@ie...   TEL(&FAX): +81-257-22-8161
> +========================================================+
> 

Re: default value of degree_sign on Japanese env.

[Bastian M. <bma...@we...>]

For the currently active locale you could also simply use wcrtomb() to 
convert.

   Bastian

Am 04.11.2011 08:54, schrieb Shigeharu TAKENO:
> shige 11/04 2011
> ----------------
>
> Ethan A Merritt<sf...@us...>  wrote:
> | I have revised the new code to use iconv() if it is available.
> | I tested under linux by setting the locale to ja_JP.EUC-JP,
> | which causes it to emit the character sequence \241 \353 (octal)
> | which is 0xA1EB (hexidecimal).  But I don't have any EUC-JP fonts
> | installed, so I cannot confirm if this is correct.
>
> The code 0xA1EB is correct for EUC-JP.
>
> Well, I think the idea
>
> +    if (locale) {
> +       /* This should work even if gnuplot doesn't understand the encoding */
> +       char *encoding = strchr(locale, '.');
> +       if (encoding) {
> +           encoding++; /* Step past the dot in, e.g., ja_JP.EUC-JP */
>
> of src/set.c is not so good, since substrings of locale name
> after '.' may not proper name of the character encoding. For
> example, in Solaris 9,
>
>    EUC-JP enconding locale name = "ja", "ja_JP.EUC", "ja_JP.eucJP"
>    Shift_JIS encoding locale name = "ja_JP.PCK"
>    UTF-8 encoding locale name = "ja_JP.UTF-8"
>
> To obtain encoding codeset name of current locale, there seems to
> be two methods:
>
> 1) Use nl_langinfo(CODESET) (#include<langinfo.h>)
> 2) Use locale_charset() (#include<localcharset.h>) in libcharset,
>    which is included in GNU libiconv.
>
> cf. http://www.haible.de/bruno/packages-libcharset.html
>
> On Solaris 9, nl_langinfo(CODESET) of system library returns:
>
>    locale = ja, ja_JP.eucJP =>  "eucJP"
>    locale = ja_JP.PCK =>  "PCK"
>
> and locale_charset() of GNU libcharset returns:
>
>    locale = ja, ja_JP.eucJP =>  "EUC-JP"
>    locale = ja_JP.PCK =>  "SHIFT_JIS"
>
> I think that names returned by locale_charset() may be better,
> but libcharset may not be installed in default.
>
>
> | If you build the new code, you can test it by saying
> |    set encoding locale
> |    show decimal
>
> Though it puts a incorrect string on "ja" locale, it works fine
> on "ja_JP.eucJP" locale since iconv library admits "eucJP".
>
> +========================================================+
>   Shigeharu TAKENO     NIigata Institute of Technology
>                         kashiwazaki,Niigata 945-1195 JAPAN
>   sh...@ie...   TEL(&FAX): +81-257-22-8161
> +========================================================+

Re: default value of degree_sign on Japanese env.

[Shigeharu T. <sh...@ie...>]

shige 11/04 2011
----------------

Ethan A Merritt <sf...@us...> wrote:
| I have revised the new code to use iconv() if it is available.
| I tested under linux by setting the locale to ja_JP.EUC-JP,
| which causes it to emit the character sequence \241 \353 (octal)
| which is 0xA1EB (hexidecimal).  But I don't have any EUC-JP fonts
| installed, so I cannot confirm if this is correct.

The code 0xA1EB is correct for EUC-JP.

Well, I think the idea

+    if (locale) { 
+       /* This should work even if gnuplot doesn't understand the encoding */
+       char *encoding = strchr(locale, '.');
+       if (encoding) {
+           encoding++; /* Step past the dot in, e.g., ja_JP.EUC-JP */

of src/set.c is not so good, since substrings of locale name 
after '.' may not proper name of the character encoding. For 
example, in Solaris 9,

  EUC-JP enconding locale name = "ja", "ja_JP.EUC", "ja_JP.eucJP"
  Shift_JIS encoding locale name = "ja_JP.PCK"
  UTF-8 encoding locale name = "ja_JP.UTF-8"

To obtain encoding codeset name of current locale, there seems to
be two methods:

1) Use nl_langinfo(CODESET) (#include <langinfo.h>)
2) Use locale_charset() (#include <localcharset.h>) in libcharset,
  which is included in GNU libiconv.

cf. http://www.haible.de/bruno/packages-libcharset.html

On Solaris 9, nl_langinfo(CODESET) of system library returns:

  locale = ja, ja_JP.eucJP => "eucJP"
  locale = ja_JP.PCK => "PCK"

and locale_charset() of GNU libcharset returns:

  locale = ja, ja_JP.eucJP => "EUC-JP"
  locale = ja_JP.PCK => "SHIFT_JIS"

I think that names returned by locale_charset() may be better,
but libcharset may not be installed in default. 


| If you build the new code, you can test it by saying
|    set encoding locale
|    show decimal

Though it puts a incorrect string on "ja" locale, it works fine
on "ja_JP.eucJP" locale since iconv library admits "eucJP".

+========================================================+
 Shigeharu TAKENO     NIigata Institute of Technology
                       kashiwazaki,Niigata 945-1195 JAPAN
 sh...@ie...   TEL(&FAX): +81-257-22-8161
+========================================================+

Re: default value of degree_sign on Japanese env.

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

On Wednesday, November 02, 2011 02:40:47 am Shigeharu TAKENO wrote:
> | 
> | Or the program could use iconv() to convert the symbol into the 
> | locale setting of the program environment.  
> 
> I think both are not need now. I will consider them when the 
> degree_sign is used at somewhere in fact.

I have revised the new code to use iconv() if it is available.
I tested under linux by setting the locale to ja_JP.EUC-JP,
which causes it to emit the character sequence \241 \353 (octal)
which is 0xA1EB (hexidecimal).  But I don't have any EUC-JP fonts
installed, so I cannot confirm if this is correct.

If you build the new code, you can test it by saying
   set encoding locale
   show decimal

If your locale is EUC-JP and you see a degree sign, then it is working.
If you get an error message then there is a problem with recognizing the
locale.

	Ethan

Re: default value of degree_sign on Japanese env.

[Shigeharu T. <sh...@ie...>]

shige 11/02 2011
----------------

Thank you for your reply.

Ethan Merritt <merritt@u.washington.edu> wrote:
| Right now the degree sign is not being used anywhere, so it
| cannot be a problem yet.  The intention is to use the degree
| sign to create a default format for writing geographic coordinates
| (patch #3428074 on SourceForge). Even so, this would only be a
| default format.  You could still specify a different format if
| it is needed.

I see.

| If you tell me the correct character sequence for EUC-JP I
| can at least put it in a comment, as it is now for SJIS and
| CP950.
| 
| Or the program could use iconv() to convert the symbol into the 
| locale setting of the program environment.  

I think both are not need now. I will consider them when the 
degree_sign is used at somewhere in fact.

+========================================================+
 Shigeharu TAKENO     NIigata Institute of Technology
                       kashiwazaki,Niigata 945-1195 JAPAN
 sh...@ie...   TEL(&FAX): +81-257-22-8161
+========================================================+

Re: default value of degree_sign on Japanese env.

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

On Tuesday, November 01, 2011 05:25:41 pm Shigeharu TAKENO wrote:
> shige 11/02 2011
> ----------------
> 
> Recently, variable degree_sign with encoding is introduced. But, 
> I think it has a problem for Japanese environment.
> 
> There are 3 encoding systems we use normaly in Japan, Shift_JIS
> for most of MS-Win user, EUC-JP for many unix user, and UTF-8.
> 
> Current version of gnuplot has support for Shift_JIS encoding 
> because the Shift_JIS Japanese characters have a singular 
> feature that the 2nd byte of them may be 7bit code (0x40-0x7E).

According to the code table on Wikipedia, the SJIS code for 
degree sign is not the same as any of the other encodings.
There is a comment in the new code that gives the SJIS code,
but right now it returns an empty string.  However, for SJIS
it works anyway in the gd and cairo terminals because iconv()
is used on output.

> We have not need care of EUC encoding in gnuplot because all 
> bytes of EUC-JP Japanese characters are 8bit code (0x8E,0x8F,
> and 0xA1-0xFE).
> 
> However, newly introduced degree_sign has a default value of 
> 8bit code 0260 (0xB0), which is a proper code of iso-8859-1 
> encoding, but is not recognized in EUC-JP encoding.

Right now the degree sign is not being used anywhere, so it
cannot be a problem yet.  The intention is to use the degree
sign to create a default format for writing geographic coordinates
(patch #3428074 on SourceForge). Even so, this would only be a
default format.  You could still specify a different format if
it is needed.

> To solve the problem, make the new encoding support for 
> EUC-JP, or to set the default value of degree_sign to 7bit
> character strings, I think.

If you tell me the correct character sequence for EUC-JP I
can at least put it in a comment, as it is now for SJIS and
CP950.

Or the program could use iconv() to convert the symbol into the 
locale setting of the program environment.  

	Ethan


-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
University of Washington, Seattle 98195-7742

default value of degree_sign on Japanese env.

[Shigeharu T. <sh...@ie...>]

shige 11/02 2011
----------------

Recently, variable degree_sign with encoding is introduced. But, 
I think it has a problem for Japanese environment.

There are 3 encoding systems we use normaly in Japan, Shift_JIS
for most of MS-Win user, EUC-JP for many unix user, and UTF-8.

Current version of gnuplot has support for Shift_JIS encoding 
because the Shift_JIS Japanese characters have a singular 
feature that the 2nd byte of them may be 7bit code (0x40-0x7E).

We have not need care of EUC encoding in gnuplot because all 
bytes of EUC-JP Japanese characters are 8bit code (0x8E,0x8F,
and 0xA1-0xFE).

However, newly introduced degree_sign has a default value of 
8bit code 0260 (0xB0), which is a proper code of iso-8859-1 
encoding, but is not recognized in EUC-JP encoding.

To solve the problem, to make the new encoding support for 
EUC-JP, or to set the default value of degree_sign to 7bit
character strings, I think.

+========================================================+
 Shigeharu TAKENO     NIigata Institute of Technology
                       kashiwazaki,Niigata 945-1195 JAPAN
 sh...@ie...   TEL(&FAX): +81-257-22-8161
+========================================================+

Re: Fwd: Missing file

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

Hello

I will change the strategy.
Comparing the size of binaries linked with static libstdc++ to dynamic one, the static one gives smaller package size. I will use -static-libstdc++ at least for gnuplot small. 

Regards

Tatsuro

--- On Tue, 2011/11/1, Tatsuro MATSUOKA wrote:

> Hello
> 
> Sorry I  do not care in the previous mail.
> In the past, winbin-small did not require libstdc++.
> 
> I found wgdiplus.cpp is c++ code so that I need add libstdc++.
> 
> Regards
> 
> Tatsuro
> --- On Mon, 2011/10/31, Bastian Märkisch 
>  wrote:
> 
> > Dear Tatsuro Matsuoka,
> > 
> > The attached report concerns your binary distribution package winbin-small. I thought the idea of winbin-small was to omit C++ code altogether, so why is libstdc++ needed at all? Does the Makefile need any changes?
> > 
> > Kind regards,
> > 
> > Bastian
> > 
> > -------- Original-Nachricht --------
> > Betreff: Missing file
> > Datum: Mon, 31 Oct 2011 10:04:03 +0100
> > Von: Surrel Yves <ys...@us...>
> > An: Bastian Maerkisch <mar...@us...>
> > 
> > Hi
> > 
> > FYI, libstdc++-6.dll seems to be missing in gp45-winbin-small.zip in Dr.
> > Matsuoka\'s binary website
> > http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/
> > 
> > 
> >
> 

Re: svg : gnuplot_plot_1

[Tait <gnu...@t4...>]

I dislike option 2, for the reasons already stated. (It's not a
terminal property, and I don't want to re-"set term" for every plot.)

I'm okay with "set doctitle" as long as it defaults, if unspecified, to
whatever "set title" is.


> There seem to be two ways to satisfy this sort of case:
> 
> 1. a new global variable like set title , let's call it set doctitle. 
> This could be reset without reopening the terminal.
> 
> 2. use existing gnuplot and reopen the terminal with a new "name". This 
> is somewhat of a work around but seems a reasonable one.
> 
> ...
> Your code example (with more realistic plot titles) becomes :
> 
>        set term foo
> 
>        set output 'plot1.foo'
> set doctitle "Corell A vs B"
>        set title "Correlation ceofficient of quantity A against quantity B"
>        plot "A.dat" title "A", "B.dat" title "B"
> 
>        set output 'plot2.foo'
> set doctitle "Corell C vs DE"
>        set title "Correlation ceofficient of quantity C against quantity 
> D and E"
>        plot "C.dat", "D.dat", "E.dat"

Re: svg : opera

[<pl...@pi...>]

On 10/24/11 11:19, Tait wrote:
> pl...@pi... said (on 2011/10/21):
>> I have given up using opera for svg since it opens local svg files
>> as text. A bug I reported over a year ago and remains AFAIK
>> unaddressed. I have to upload somewhere and access via http so I no
>> long bother.
>
> Odd... I don't have that problem. Local SVGs open fine for me. I'm
> currently using 11.52 on Windows, but I've been using Opera to view
> SVGs since at least 9.something.
>

Thanks for that information. I had a look at prefs for Opera and there
was a text/svg entry. I removed that and now they open as expected.

I don't know why it was there or why it thought such a mime type fitted
gnuplot output. Anyway , that will make testing gnuplots svg on Opera a
lot easier and more likely.

Thanks again. Peter.