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

'set key opaque' in aqua terminal

[Jun T. <tak...@kb...>]

(CVS at sourceforge is down; I hope the mailing list is alive.)

Attached are two pdf files generated by

gnuplot> set key opaque
gnuplot> plot [0:1] x**0.5, x, x**2

with aqua and qt terminals. As you can see, the key's background
in aqua.pdf is almost black. This is due to that the linetype -4
is set to 'almost black' at line 390 of aquaterm.trm.

The following patch sets linetype -4 to white.
Since 'set term aqua' does not have the option 'backdround',
I think it safe to assume that the background is always white.


--- term/aquaterm.trm.ORG	2015-02-25 09:23:14.000000000 +0900
+++ term/aquaterm.trm	2015-07-21 21:14:12.000000000 +0900
@@ -387,7 +387,7 @@
    * Set up the basic indexed colormap for gnuplot
    */
   /*  Special colors */
-  [adapter setColormapEntry:0 red:0.1 green:0.1 blue:0.1]; /* linetype -4 */
+  [adapter setColormapEntry:0 red:1.0 green:1.0 blue:1.0]; /* linetype -4 */
   [adapter setColormapEntry:1 red:0.9 green:0.9 blue:0.9]; /* linetype -3 (xor;interactive) light gray */
   [adapter setColormapEntry:2 red:0.0 green:0.0 blue:0.0]; /* linetype -2 (border) black */
   [adapter setColormapEntry:3 red:0.8 green:0.8 blue:0.8]; /* linetype -1 (gridlines) light grey */

Re: set xtics 0 rejected on the current cvs (ChangeLog 2015-07-11)

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

----- Original Message -----

> From: Hans-Bernhard Bröker 
> To: Tatsuro MATSUOKA ; gnuplot-beta
> Cc: 
> Date: 2015/7/11, Sat 18:14
> Subject: Re: set xtics 0 rejected on the current cvs (ChangeLog 2015-07-11)
> 
> Am 11.07.2015 um 09:13 schrieb Tatsuro MATSUOKA:
> 
>>  gnuplot> set xtics 0
>>            ^
>>            "imageNaN.dem", line 23: increment must be positive
> 
> 
> That's because the demo is wrong.  The program was wrong, too, and it's 
> now been fixed.



I have confirmed the fix. Thanks.

Tatsuro

Update to helpbook-like documentation for WXT and Qt terminals

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

I've updated a patch for adding the "wxhelp" in helpbook format to the 
WXT and Qt terminal windows:

https://sourceforge.net/p/gnuplot/patches/707/
https://sourceforge.net/p/gnuplot/patches/_discuss/thread/5dca9423/7c9e/5833/attachment/gnuplot-htmlhelp-2015jul11.patch

It is a nice way to access the documentation--fast, search-able, can 
freely navigate forward and back using scrollbar, plot examples.

Note that the patch does some reorganization because the documentation 
serves as a basis for both terminals, e.g., rather "helpbook" takes the 
place of "windows" in the source tree.  There are docs/wx and docs/qt 
subdirectories for the different bundles, and then when installed they 
end up in help/wx and help/qt subdirectories of the install location.

On the matter of html version of the documentation, the recent changes 
to the docs make file and usual mods occasionally finding their way into 
code have resulted in

make html
make install-html

not working so well.  Some issues:

1) Building html appears to put all sorts of PDF files in the docs 
subdirectory.  It might be better for that to be in some directory like 
docs/pdf.

2) Building gnuplot/html from outside the install directory seems to 
fail with a long, long stream of warnings about img3 (image003), img4 
(image004), etc. not being found.

3) Building gnuplot/html from inside the install directory works better 
but still has problems such as:

[snip]

Package: loading /usr/share/latex2html/styles/inputenc.perl
Warning: No implementation found for option: `utf8x' for `inputenc' package

Warning: No implementation found for option: `hyperindex' for `hyperref' 
package

Warning: No implementation found for option: `bookmarks' for `hyperref' 
package

Warning: No implementation found for option: `bookmarksnumbered_true' 
for `hyperref' package

[snip]

@@@@@@@@@@@@@@@@@@@@@@

*** no brace for \usebox , before:
\GpVersion{{
*** using "\GpVersion" as the argument instead; is this correct?  ***

@@@@@@@@@@@@@@@

*** no brace for \usebox , before:
\GpVersion
*** using "\GpVersion" as the argument instead; is this correct?  ***

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@


Dan

windows binaries in which gd-jpeg libraries bug are fixed

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

Hello

There has been a bug report:

****************************************
#1643 jpeg terminal broken in windows binaries

https://sourceforge.net/p/gnuplot/bugs/1643/


The bug comes from gd and jpeg libraries were created in inconsistent way.
I found the origin of inconsistency and create fixed gd and jpeg libraries.
(jpeg library is changed from jpeg-9a to libjpeg-turbo-1.4.1)

The fixed binaries are available at
http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/


**********************************************
> From here, inquiry to the developers.

I think it is better re-create windows gnuplot-5.0.1 binaries.
(Also a user pointed out help file lacks figures for 5.0.1)

For 4.6 version, 4.6.6 binaries have gd-jpeg library bugs.
I think it will be better 4.6.7 windows binaries because it is the last version of gnuplot ver. 4.6.

Tatsuro

Re: set xtics 0 rejected on the current cvs (ChangeLog 2015-07-11)

[Hans-Bernhard B. <HBB...@t-...>]

Am 11.07.2015 um 09:13 schrieb Tatsuro MATSUOKA:

> gnuplot> set xtics 0
>           ^
>           "imageNaN.dem", line 23: increment must be positive


That's because the demo is wrong.  The program was wrong, too, and it's 
now been fixed.

Re: set xtics 0 rejected on the current cvs (ChangeLog 2015-07-11)

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

----- Original Message -----

> From: Tatsuro MATSUOKA 
> To: gnuplot-beta
> Cc: 
> Date: 2015/7/11, Sat 16:13
> Subject: set xtics 0 rejected on the current cvs (ChangeLog 2015-07-11)
> 
>g nuplot>  set xtics 0
> 
>          ^
>          increment must be positive
> 
> So that demo imageNaN.dem fails:
> gnuplot> load 'imageNaN.dem'
> 
> gnuplot> set xtics 0
>          ^
>          "imageNaN.dem", line 23: increment must be positive
> 
> 
> 
> Perhaps the change
> 
> 2015-07-11  Ethan A Merritt  <merritt@u.washington.edu>
> 
>     * src/set.c (load_tic_series): Incorrect nesting of brackets caused
>     "set xtics 0" to be accepted rather than rejected.  This could 
> lead
>     to various bad outcomes (as found by fuzz-testing).
> does not work for me.
> 
> 
> At the moment, I have built the current only on Ubuntu 14.04 LTS amd64.
> I have preparing built on Cygwin and native windows.
> 
I have also confirmed the change breaks imageNaN.dem on Cygwin and windows.

Tatsuro

set xtics 0 rejected on the current cvs (ChangeLog 2015-07-11)

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

gnuplot>  set xtics 0

         ^
         increment must be positive

So that demo imageNaN.dem fails:
gnuplot> load 'imageNaN.dem'

gnuplot> set xtics 0
         ^
         "imageNaN.dem", line 23: increment must be positive



Perhaps the change

2015-07-11  Ethan A Merritt  <merritt@u.washington.edu>

    * src/set.c (load_tic_series): Incorrect nesting of brackets caused
    "set xtics 0" to be accepted rather than rejected.  This could lead
    to various bad outcomes (as found by fuzz-testing).
does not work for me.


At the moment, I have built the current only on Ubuntu 14.04 LTS amd64.
I have preparing built on Cygwin and native windows.


Tatsuro

Re: pm3dcolors demo broken

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

>> set terminal png transparent nocrop enhanced size 450,320 font "arial,8"
>> set output 'pm3dcolors.1.png'
>> load 'C:\Programs\gp510-64\demo\pm3dcolors.dem'
>> set output
>>
>> <http://gnuplot.10905.n7.nabble.com/file/n19585/pm3dcolors.png>
>>
>> This is the same as on the web site.
>>
>> Is this a png terminal bug?
>
> Possibly, but I don't think so.  It may be that libgd is limited in
> terms of colors.  In term/gd.trm is stated:
>
>   /* TODO: how to recover from a multiplot with two colour pm3d maps?
>      They must use the same palette! Or palette size must be
>      restricted to certain number of colours---a new user's option
>   */

Old time ago, "gd" was a library for gif files only, so limited to 256 
colours, and thus the reason for adding "set palette maxcolors" in gnuplot 
(very old "new user's option").

I think there might have been an error message like "no more available colours".

Do you think that it is worth to add such a message, saying also "use option 
truecolor", and removing (I think mine) old TODO?

---
PM

Re: pm3dcolors demo broken

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

----- Original Message -----

> From: Tatsuro MATSUOKA
> To: Merritt Ethan ; gnuplot-beta
> Cc: 
> Date: 2015/7/2, Thu 15:34
> Subject: Re: pm3dcolors demo broken
> 
> ----- Original Message -----
> 
>>  From: sfeam 
>>  To: gnuplot-betat
>>  Cc: tmacchant 
>>  Date: 2015/7/2, Thu 15:09
>>  Subject: Re: pm3dcolors demo broken
>> 
>>  On Wednesday, 01 July 2015 10:24:49 PM tmacchant wrote:
>>>   In the last post I have generated the plot in wxt terminal.
>>>   That worked correctly
>>> 
>>>   However, as in written web site I have re-generate it using 
>>> 
>>>   set terminal png transparent nocrop enhanced size 450,320 font 
>>  "arial,8"
>>>   set output 'pm3dcolors.1.png' 
>>>   load 
> 'C:\Programs\gp510-64\demo\pm3dcolors.dem'
>>>   set output 
>>>    
>>>   <http://gnuplot.10905.n7.nabble.com/file/n19585/pm3dcolors.png> 
>>> 
>>>   This is the same as on the web site.
>>> 
>>>   Is this a png terminal bug?
>> 
>>  The web site is generated using the pngcairo terminal.
>> 
>>  The png (libgd) terminal by default creates a file with 
>>  indexed colors, 245 colors maximum.  This is not enough
>>  to create multiple smooth palettes.  To create files with
>>  full 24-bit RGB color you must say
>> 
>>  set term png truecolor ...
>> 
>>>   Is this better to be filed into bug ticket?
>>>     Tatsuro
>> 
>>  I do not think there is a bug here.
>> 
>>      Ethan
> Ok. I have confirmed that truecolor option resolve the issue on png terminal.
> And it is not a bug.
> 
>>  The web site is generated using the pngcairo terminal.
> 
> 
> I have believed so but 
> 
> In the page
> http://gnuplot.sourceforge.net/demo/pm3dcolors.html
> 
> 
> Click herefor minimal script to generate this plot
> 
> 
> And clicked here.
> 
> 
> There described.
> # set terminal png transparent nocrop enhanced size 450,320 font 
> "arial,8" 
> # set output 'pm3dcolors.1.png'
> g(x)=x
> GPFUN_g = "g(x)=x"
> splot g(x)
> 
> So I tried to generate the plot by 
> set terminal png transparent nocrop enhanced size 450,320 font 
> "arial,8" 
> set output 'pm3dcolors.1.png' 
> 
> The image downloaded from the web site and generated the above setting using 
> gnuplot 5.1
> is almost the same.
> 
> As far as this image, the image created by png terminal with the above option 
> but not pngcairo terminal.
> 
> Anyway the page should be revised.
> Tatsuro
> 
I have confirmed that the page
http://gnuplot.sourceforge.net/demo/pm3dcolors.html

is updated with pngcairo.

Thanks!

Tatsuro

Re: Summary of state of utf-8 supported terminals

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

On 07/03/2015 04:01 PM, Daniel J Sebald wrote:

> I made the following substitutions to achieve the intended text:
>
> #  =>   \#
> $  =>   \$
> %  =>   \%
> &   =>   \&
> <   =>   \textless
>>   =>   \textgreater
> \  =>   \textbackslash
> ^  =>   \^
> _  =>   \_
>
> One question is should such translations be added to the latex terminal
> when requesting a text string?  We could make it an option to the latex
> terminal, e.g., "textsubstitute".  An alternative is to use one of the
> LaTeX verbatim constructs but that risks the user typing in the exit
> character from verbatim, causing more confusion.

The problem with the above idea is that one can no longer enter LaTeX 
command words.  Actually, when one thinks about it, this concept is 
essentially the same as saying "noenhanced", isn't it?  I mean, LaTeX is 
inherently "enhanced", so an option "noenhanced" making the above 
substitutions would be pretty consistent with other terminals.

Dan

Re: Summary of state of utf-8 supported terminals

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

On 07/03/2015 12:32 PM, sfeam wrote:
> On Friday, 03 July 2015 03:46:28 AM Daniel J Sebald wrote:
>> On 07/03/2015 12:42 AM, sfeam wrote:
>
>>> Did I miss a terminal you were interested in?
>>
>> JPEG works...
>>
>> I think I will just treat all working under utf8, except PostScript and
>> try to resolve the libgd issue separately.
>
> If JPEG works then PNG must work also.
> It is the same driver.
>
>> Note, I think there is an invalid ASCII character in the utf8.dem demo.
>
> Umm. It is a demo of UTF-8, not ASCII.
>
>> When I tried compiling the latex output, the program complained about
>> an unfound character.
>
> I already noted that most latex installations do not handle the full
> range of characters.  Even if it handled \0177 is would almost certainly
> fail on the subsequent test lines.
>
>> I looked at the output in gvim and saw
>>
>> ...z{|}~}}
>>
>> the third last character which appears as ^? in gvim but may be another
>> glyph in your mail viewer.  That line in the demo is labeled 0061 -
>> 007E, but 7E is 126 and octal \177 is 127.  ASCII 127 is the [DEL],
>> which I'm guessing is not assigned a glyph.  I suggest removing \177
>> from utf8.dem.
>
> IMHO one goal of the demos is to provide a set of unit tests.
> The idea is to exercise everything and find out what may not be working
> on the system where the test is run.  It's kind of pointless to remove
> a test just because it succeeds in indicating a point of failure.

Here are test results for utf8 and latex terminal.

When compiling the gnuplot-generated LaTeX file, any characters that act 
as control-chars/tags in LaTeX cause a problem.  E.g.,

! You can't use `macro parameter character #' in restricted horizontal mode.
<argument> !"##
                \$\%\&'()*+,-./0123456789:;<=>?@
l.10 ...)[l]{!"#\$\%\&'()*+,-./0123456789:;<=>?@}}

I made the following substitutions to achieve the intended text:

#  =>  \#
$  =>  \$
%  =>  \%
&  =>  \&
<  =>  \textless
>  =>  \textgreater
\  =>  \textbackslash
^  =>  \^
_  =>  \_

One question is should such translations be added to the latex terminal 
when requesting a text string?  We could make it an option to the latex 
terminal, e.g., "textsubstitute".  An alternative is to use one of the 
LaTeX verbatim constructs but that risks the user typing in the exit 
character from verbatim, causing more confusion.

After those changes, the \177 character produces the following error:

! Text line contains an invalid character.
l.12 ...(0,0)[l]{abcdefghijklmnopqrstuvwxyz{|}~^^?
                                                   }}

After removing that \177 character, LaTeX compiles the file correctly, 
basically ignoring all the rest of the UTF-8 characters.  All those 
lines appear blank.

Dan

Re: Summary of state of utf-8 supported terminals

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

On 07/03/2015 12:32 PM, sfeam wrote:
> On Friday, 03 July 2015 03:46:28 AM Daniel J Sebald wrote:
>> On 07/03/2015 12:42 AM, sfeam wrote:
>
>>> Did I miss a terminal you were interested in?
>>
>> JPEG works...
>>
>> I think I will just treat all working under utf8, except PostScript and
>> try to resolve the libgd issue separately.
>
> If JPEG works then PNG must work also.
> It is the same driver.
>
>> Note, I think there is an invalid ASCII character in the utf8.dem demo.
>
> Umm. It is a demo of UTF-8, not ASCII.

ASCII is the first code book of utf8, if I understand correctly.  The 
eighth bit in the first utf8 byte is an indication of longer than one 
byte code.  Most references group U+007F in with control codes:

https://en.wikipedia.org/wiki/UTF-8
http://www.utf8-chartable.de/


>> When I tried compiling the latex output, the program complained about
>> an unfound character.
>
> I already noted that most latex installations do not handle the full
> range of characters.  Even if it handled \0177 is would almost certainly
> fail on the subsequent test lines.
>
>> I looked at the output in gvim and saw
>>
>> ...z{|}~}}
>>
>> the third last character which appears as ^? in gvim but may be another
>> glyph in your mail viewer.  That line in the demo is labeled 0061 -
>> 007E, but 7E is 126 and octal \177 is 127.  ASCII 127 is the [DEL],
>> which I'm guessing is not assigned a glyph.  I suggest removing \177
>> from utf8.dem.
>
> IMHO one goal of the demos is to provide a set of unit tests.
> The idea is to exercise everything and find out what may not be working
> on the system where the test is run.  It's kind of pointless to remove
> a test just because it succeeds in indicating a point of failure.

We've found that LaTeX and gvim don't like control characters in UTF-8 
format.  If gnuplot isn't processing control codes in some way, what is 
being tested?  If the U+007F is intentional, why not label the line 0061 
- 007F rather than 7E?

Dan

Re: Summary of state of utf-8 supported terminals

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

On Friday, 03 July 2015 03:46:28 AM Daniel J Sebald wrote:
> On 07/03/2015 12:42 AM, sfeam wrote:

> > Did I miss a terminal you were interested in?
> 
> JPEG works...
> 
> I think I will just treat all working under utf8, except PostScript and 
> try to resolve the libgd issue separately.

If JPEG works then PNG must work also.
It is the same driver.

> Note, I think there is an invalid ASCII character in the utf8.dem demo. 

Umm. It is a demo of UTF-8, not ASCII.

> When I tried compiling the latex output, the program complained about 
> an unfound character.  

I already noted that most latex installations do not handle the full
range of characters.  Even if it handled \0177 is would almost certainly
fail on the subsequent test lines.

> I looked at the output in gvim and saw
> 
> ...z{|}~}}
> 
> the third last character which appears as ^? in gvim but may be another 
> glyph in your mail viewer.  That line in the demo is labeled 0061 - 
> 007E, but 7E is 126 and octal \177 is 127.  ASCII 127 is the [DEL], 
> which I'm guessing is not assigned a glyph.  I suggest removing \177 
> from utf8.dem.

IMHO one goal of the demos is to provide a set of unit tests.
The idea is to exercise everything and find out what may not be working
on the system where the test is run.  It's kind of pointless to remove
a test just because it succeeds in indicating a point of failure.

	Ethan

Re: random.dem

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

----- Original Message -----

> From: Tatsuro MATSUOKA 
> To: tmacchant3; gnuplot-beta
> Cc: 
> Date: 2015/7/3, Fri 17:58
> Subject: Re: random.dem 
> 
> 
> 
> ----- Original Message -----
>>  From: Tatsuro MATSUOKA 
>>  To: gnuplot-beta
>>  Cc: 
>>  Date: 2015/7/3, Fri 17:10
>>  Subject: random.dem 
>> 
>>  On windows build, random.dem fails both 32 bit and 64 bit.
>> 
>>  gnuplot> plot $random using 
> (bin(sqrt($1**2+$2**2+$3**2))):(1.0*scale/nsamp) 
>>  every :::::0 smooth
>>   frequency with steps         title "scaled bin frequency",       
>   
>>  maxwell(x, 1/sqrt(2)) with l
>>  ines title "Maxwell p.d.f.",         $random using 
>>  (sqrt($1**2+$2**2+$3**2)):(scale/nsamp) bins=
>>  25 with impulse lw 5 title "assign samples to 25 bins"
>>                                                                              
>     
>>                  
>>                                                                              
>     
>>                  
>>                                                                              
>     
>>             ^
>>           "random.dem", line 171: unexpected or unrecognized token
>> 
>>  On Ubuntu make check runs without errors.
>> 
>>  On previous changelog (2015-06-28) source, random.dem fails.
>> 
>>  I also confirmed the same failure in Kakuto's build (MSVC) (64 bit 
> ChangeLOG 
>>  2015-06-28)
>> 
>>  I do not figure out when random.dem starts to fail on windows build.
>> 
>>  Tatsuro
>> 
> 
> 
> Perhaps 
> 
> #define SMOOTH_BINS_OPTION
> 
> 
> should be added to config.mgw.
> 
> Now I am building with modified config.mgw
> 
> The results will be reported here.
> 
> All other build systems without configure config.xxx should be revised.
> 
>  
Addition of #define SMOOTH_BINS_OPTION to config.mgw solve the issue.

I filed to the bug ticket
https://sourceforge.net/p/gnuplot/bugs/1645/


Tatsuro

Re: random.dem

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

----- Original Message -----
> From: Tatsuro MATSUOKA 
> To: gnuplot-beta
> Cc: 
> Date: 2015/7/3, Fri 17:10
> Subject: random.dem 
> 
> On windows build, random.dem fails both 32 bit and 64 bit.
> 
> gnuplot> plot $random using (bin(sqrt($1**2+$2**2+$3**2))):(1.0*scale/nsamp) 
> every :::::0 smooth
>  frequency with steps         title "scaled bin frequency",         
> maxwell(x, 1/sqrt(2)) with l
> ines title "Maxwell p.d.f.",         $random using 
> (sqrt($1**2+$2**2+$3**2)):(scale/nsamp) bins=
> 25 with impulse lw 5 title "assign samples to 25 bins"
>                                                                                 
>                 
>                                                                                 
>                 
>                                                                                 
>            ^
>          "random.dem", line 171: unexpected or unrecognized token
> 
> On Ubuntu make check runs without errors.
> 
> On previous changelog (2015-06-28) source, random.dem fails.
> 
> I also confirmed the same failure in Kakuto's build (MSVC) (64 bit ChangeLOG 
> 2015-06-28)
> 
> I do not figure out when random.dem starts to fail on windows build.
> 
> Tatsuro
> 


Perhaps 

#define SMOOTH_BINS_OPTION


should be added to config.mgw.

Now I am building with modified config.mgw

The results will be reported here.

All other build systems without configure config.xxx should be revised.

 
Tatsuro

Re: Summary of state of utf-8 supported terminals

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

On 07/03/2015 12:42 AM, sfeam wrote:
> On Friday, 03 July 2015 12:03:18 AM Daniel J Sebald wrote:
>> Ethan,
>>
>> Could you give a brief summary of the support of utf-8 symbols in the
>> terminals?  {/Symbol xyz} wasn't working for me in Qt (probably missing
>> the symbol font, as others reported the symbols appeared in Qt plots).
>> So I tried utf-8 as described in the documentation and that works nicely
>> for Qt terminal.  It seems to me that WXT and Qt work well with utf-8
>> symbols, while the rest of the terminals (x11, png, postscript) have a
>> better chance of working correctly with {/Symbol xyz} format.  Does that
>> sound about right?
>
> The Adobe Symbol font was designed for PostScript.
> Using it for anything else is probably not optimal.
>
> PostScript (the language) predates UTF-8 and basically cannot sanely
> handle any character set larger that 255.  Use PDF instead.

Ah, that explains PostScript.


> X11 handles UTF-8 just fine, but it is a little bit complicated to
> select the fonts properly.  This is described in the docs.
> For an example, see the comments at the top of utf8.dem

OK.  I've had problems with x11 terminal window crashing (i.e., 
disappearing) with the utf8.dem and enhanced_utf8.dem demos but I can't 
reproduce this consistently.


> Both libgd and cairo use utf-8 with no problem so you shouldn't have
> any trouble with png.

This one I'm having trouble with, primarily.  I'm surprised it's not 
working.


> SVG is natively UTF-8.  If anything the difficultly would be
> creating an svg file using some other encoding.

No problems here.


> The latex terminals will pass through text without interpretation,
> so on the gnuplot end the encoding shouldn't matter.  But it is
> still rare to have a LaTeX configuration that handles the full
> range of UTF-8 characters.
>
> Did I miss a terminal you were interested in?

JPEG works...

I think I will just treat all working under utf8, except PostScript and 
try to resolve the libgd issue separately.

Note, I think there is an invalid ASCII character in the utf8.dem demo. 
  When I tried compiling the latex output, the program complained about 
an unfound character.  I looked at the output in gvim and saw

...z{|}~}}

the third last character which appears as ^? in gvim but may be another 
glyph in your mail viewer.  That line in the demo is labeled 0061 - 
007E, but 7E is 126 and octal \177 is 127.  ASCII 127 is the [DEL], 
which I'm guessing is not assigned a glyph.  I suggest removing \177 
from utf8.dem.

Thanks,

Dan

random.dem

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

On windows build, random.dem fails both 32 bit and 64 bit.

gnuplot> plot $random using (bin(sqrt($1**2+$2**2+$3**2))):(1.0*scale/nsamp) every :::::0 smooth
 frequency with steps         title "scaled bin frequency",         maxwell(x, 1/sqrt(2)) with l
ines title "Maxwell p.d.f.",         $random using (sqrt($1**2+$2**2+$3**2)):(scale/nsamp) bins=
25 with impulse lw 5 title "assign samples to 25 bins"
                                                                                                
                                                                                                
                                                                                           ^
         "random.dem", line 171: unexpected or unrecognized token

On Ubuntu make check runs without errors.

On previous changelog (2015-06-28) source, random.dem fails.

I also confirmed the same failure in Kakuto's build (MSVC) (64 bit ChangeLOG 2015-06-28)

I do not figure out when random.dem starts to fail on windows build.

Tatsuro

Re: Summary of state of utf-8 supported terminals

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

On Friday, 03 July 2015 12:03:18 AM Daniel J Sebald wrote:
> Ethan,
> 
> Could you give a brief summary of the support of utf-8 symbols in the 
> terminals?  {/Symbol xyz} wasn't working for me in Qt (probably missing 
> the symbol font, as others reported the symbols appeared in Qt plots). 
> So I tried utf-8 as described in the documentation and that works nicely 
> for Qt terminal.  It seems to me that WXT and Qt work well with utf-8 
> symbols, while the rest of the terminals (x11, png, postscript) have a 
> better chance of working correctly with {/Symbol xyz} format.  Does that 
> sound about right?

The Adobe Symbol font was designed for PostScript.
Using it for anything else is probably not optimal.

PostScript (the language) predates UTF-8 and basically cannot sanely
handle any character set larger that 255.  Use PDF instead.

X11 handles UTF-8 just fine, but it is a little bit complicated to
select the fonts properly.  This is described in the docs.
For an example, see the comments at the top of utf8.dem

Both libgd and cairo use utf-8 with no problem so you shouldn't have
any trouble with png.

SVG is natively UTF-8.  If anything the difficultly would be
creating an svg file using some other encoding.

The latex terminals will pass through text without interpretation,
so on the gnuplot end the encoding shouldn't matter.  But it is
still rare to have a LaTeX configuration that handles the full
range of UTF-8 characters.  

Did I miss a terminal you were interested in?

	Ethan

Re: Colorbox granularity (number of rectangles)

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

On Thursday, 02 July 2015 11:29:15 PM Juhász Péter wrote:
> Dear.all;
> 
> Consider the result of the following script (on full screen if
> possible):
> 
> #####################
> cutoff = 300
> set palette defined \
>  (0 'white', cutoff-1 'pink',\
>  cutoff '#7f0000', cutoff+5 '#ff0000',\
>  cutoff+10 '#ff007f', cutoff+15 '#ff7f00',\
>  cutoff+20 '#ffff00')
> 
> set isosa 1000
> set xr [0:10]
> set yr [0:cutoff+20]
> set cbr [0:cutoff+20]
> 
> plot '++' w image
> ######################
> 
> This is actually a minimal version of a real script.
> The contrived looking palette is intended to show that variation in the
> data is only interesting as long as it's above the cutoff. The palette
> is rapidly changing above the cutoff, however, and this emphasizes the
> effect of the limited resolution of the colorbox.
> 
> 
> The culprit is apparently this line in
> draw_inside_color_smooth_box_bitmap in color.c:
> 
>     int steps = 128; /* I think that nobody can distinguish more colours
> drawn in the palette */
> 
> Apparently this assumption is false, especially on large resolution
> bitmap terminals.

I think the comment is correct, 128 colors in a smooth gradient
is probably sufficient.   

The artifact you see is not because of a limited number of colors,
since for most terminals there is no limit to the number of colors.
I think what you are noticing is that the colorbar is composed of
a fixed number of equal-sized rectangles.

> Would it be sensible to adjust the number of steps based on the space
> available (yes, I guess, on bitmap terminals, but what about
> vector-based ones)? Or perhaps to make it user-settable?

I don't think any constant number of steps will be correct,
user-settable or not.

What you want is to vary the size of the colorbar rectangles
depending on the local palette gradient.  Or looked at another way,
each interval in a defined palette ("set palette defined") should
be split into a sufficient number of rectangles to create a 
smooth gradient.

That sounds possible, but complicated.
I suppose the number of sub-rectangles should depend on the
resolution of the terminal, the span of the defined palette
interval (1 rectangle is sufficient for a solid color), and
the number of available colors if the terminal has a maximum
number of palette colors. 

	Ethan


> 
> Péter Juhász
> 
> 
> 
> ------------------------------------------------------------------------------
> Don't Limit Your Business. Reach for the Cloud.
> GigeNET's Cloud Solutions provide you with the tools and support that
> you need to offload your IT needs and focus on growing your business.
> Configured For All Businesses. Start Your Cloud Today.
> https://www.gigenetcloud.com/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Summary of state of utf-8 supported terminals

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

Ethan,

Could you give a brief summary of the support of utf-8 symbols in the 
terminals?  {/Symbol xyz} wasn't working for me in Qt (probably missing 
the symbol font, as others reported the symbols appeared in Qt plots). 
So I tried utf-8 as described in the documentation and that works nicely 
for Qt terminal.  It seems to me that WXT and Qt work well with utf-8 
symbols, while the rest of the terminals (x11, png, postscript) have a 
better chance of working correctly with {/Symbol xyz} format.  Does that 
sound about right?

Thanks,

Dan

Re: Colorbox granularity (number of rectangles)

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

On 07/02/2015 04:29 PM, Juhász Péter wrote:
> Dear.all;
>
> Consider the result of the following script (on full screen if
> possible):
>
> #####################
> cutoff = 300
> set palette defined \
>   (0 'white', cutoff-1 'pink',\
>   cutoff '#7f0000', cutoff+5 '#ff0000',\
>   cutoff+10 '#ff007f', cutoff+15 '#ff7f00',\
>   cutoff+20 '#ffff00')
>
> set isosa 1000
> set xr [0:10]
> set yr [0:cutoff+20]
> set cbr [0:cutoff+20]
>
> plot '++' w image
> ######################
>
> This is actually a minimal version of a real script.
> The contrived looking palette is intended to show that variation in the
> data is only interesting as long as it's above the cutoff. The palette
> is rapidly changing above the cutoff, however, and this emphasizes the
> effect of the limited resolution of the colorbox.
>
>
> The culprit is apparently this line in
> draw_inside_color_smooth_box_bitmap in color.c:
>
>      int steps = 128; /* I think that nobody can distinguish more colours
> drawn in the palette */
>
> Apparently this assumption is false, especially on large resolution
> bitmap terminals.
>
> Would it be sensible to adjust the number of steps based on the space
> available (yes, I guess, on bitmap terminals, but what about
> vector-based ones)? Or perhaps to make it user-settable?

I seem to recall that limitation and thinking 128 steps isn't much. 
Other than the number of steps being limited by the size of the palette 
(having more steps would mean interpolation that doesn't add any 
detail), there shouldn't be a limit.  As with sampling in general, the 
step size should reflect the frequency content of the color components 
of the palette.  That is, a palette could be quickly changing at some 
levels and inadequate step size at the level could result in some 
noticeable artifacts.  We don't want to deal with non-uniform sampling, 
so increasing the number of steps would be the way to deal with that.

User settable with some reasonable default seems best to me.

set colorbox {steps N}
set colorbox {samples N}

?

Dan

Colorbox granularity (number of rectangles)

[Juhász P. <pet...@gm...>]

Dear.all;

Consider the result of the following script (on full screen if
possible):

#####################
cutoff = 300
set palette defined \
 (0 'white', cutoff-1 'pink',\
 cutoff '#7f0000', cutoff+5 '#ff0000',\
 cutoff+10 '#ff007f', cutoff+15 '#ff7f00',\
 cutoff+20 '#ffff00')

set isosa 1000
set xr [0:10]
set yr [0:cutoff+20]
set cbr [0:cutoff+20]

plot '++' w image
######################

This is actually a minimal version of a real script.
The contrived looking palette is intended to show that variation in the
data is only interesting as long as it's above the cutoff. The palette
is rapidly changing above the cutoff, however, and this emphasizes the
effect of the limited resolution of the colorbox.


The culprit is apparently this line in
draw_inside_color_smooth_box_bitmap in color.c:

    int steps = 128; /* I think that nobody can distinguish more colours
drawn in the palette */

Apparently this assumption is false, especially on large resolution
bitmap terminals.

Would it be sensible to adjust the number of steps based on the space
available (yes, I guess, on bitmap terminals, but what about
vector-based ones)? Or perhaps to make it user-settable?

Péter Juhász

Re: pm3dcolors demo broken

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

----- Original Message -----

> From: sfeam 
> To: gnuplot-betat
> Cc: tmacchant 
> Date: 2015/7/2, Thu 15:09
> Subject: Re: pm3dcolors demo broken
> 
> On Wednesday, 01 July 2015 10:24:49 PM tmacchant wrote:
>>  In the last post I have generated the plot in wxt terminal.
>>  That worked correctly
>> 
>>  However, as in written web site I have re-generate it using 
>> 
>>  set terminal png transparent nocrop enhanced size 450,320 font 
> "arial,8"
>>  set output 'pm3dcolors.1.png' 
>>  load 'C:\Programs\gp510-64\demo\pm3dcolors.dem'
>>  set output 
>>   
>>  <http://gnuplot.10905.n7.nabble.com/file/n19585/pm3dcolors.png> 
>> 
>>  This is the same as on the web site.
>> 
>>  Is this a png terminal bug?
> 
> The web site is generated using the pngcairo terminal.
> 
> The png (libgd) terminal by default creates a file with 
> indexed colors, 245 colors maximum.  This is not enough
> to create multiple smooth palettes.  To create files with
> full 24-bit RGB color you must say
> 
> set term png truecolor ...
> 
>>  Is this better to be filed into bug ticket?
>>    Tatsuro
> 
> I do not think there is a bug here.
> 
>     Ethan
Ok. I have confirmed that truecolor option resolve the issue on png terminal.
And it is not a bug.

> The web site is generated using the pngcairo terminal.


I have believed so but 

In the page
http://gnuplot.sourceforge.net/demo/pm3dcolors.html


Click herefor minimal script to generate this plot


And clicked here.


There described.
# set terminal png transparent nocrop enhanced size 450,320 font "arial,8" 
# set output 'pm3dcolors.1.png'
g(x)=x
GPFUN_g = "g(x)=x"
splot g(x)

So I tried to generate the plot by 
set terminal png transparent nocrop enhanced size 450,320 font "arial,8" 
set output 'pm3dcolors.1.png' 

The image downloaded from the web site and generated the above setting using gnuplot 5.1
is almost the same.

As far as this image, the image created by png terminal with the above option but not pngcairo terminal.

Anyway the page should be revised.
Tatsuro

Re: pm3dcolors demo broken

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

On 07/02/2015 12:24 AM, tmacchant wrote:
> In the last post I have generated the plot in wxt terminal.
> That worked correctly
>
> However, as in written web site I have re-generate it using
>
> set terminal png transparent nocrop enhanced size 450,320 font "arial,8"
> set output 'pm3dcolors.1.png'
> load 'C:\Programs\gp510-64\demo\pm3dcolors.dem'
> set output
>
> <http://gnuplot.10905.n7.nabble.com/file/n19585/pm3dcolors.png>
>
> This is the same as on the web site.
>
> Is this a png terminal bug?

Possibly, but I don't think so.  It may be that libgd is limited in 
terms of colors.  In term/gd.trm is stated:

   /* TODO: how to recover from a multiplot with two colour pm3d maps?
      They must use the same palette! Or palette size must be
      restricted to certain number of colours---a new user's option
   */

There is an immediate solution, which is to add the option truecolor, i.e.,

set term png truecolor

works for me.


> Is this better to be filed into bug ticket?

If you wish.

Dan

Re: pm3dcolors demo broken

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

On Wednesday, 01 July 2015 10:24:49 PM tmacchant wrote:
> In the last post I have generated the plot in wxt terminal.
> That worked correctly
> 
> However, as in written web site I have re-generate it using 
> 
> set terminal png transparent nocrop enhanced size 450,320 font "arial,8"
> set output 'pm3dcolors.1.png' 
> load 'C:\Programs\gp510-64\demo\pm3dcolors.dem'
> set output 
>   
> <http://gnuplot.10905.n7.nabble.com/file/n19585/pm3dcolors.png> 
> 
> This is the same as on the web site.
> 
> Is this a png terminal bug?

The web site is generated using the pngcairo terminal.

The png (libgd) terminal by default creates a file with 
indexed colors, 245 colors maximum.  This is not enough
to create multiple smooth palettes.  To create files with
full 24-bit RGB color you must say

set term png truecolor ...

> Is this better to be filed into bug ticket?
>   Tatsuro

I do not think there is a bug here.

	Ethan