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

Re: funny behavior at making wgnuplot.chm on mingw from cvs source

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

On 24.02.2011 22:12, Tatsuro MATSUOKA wrote:
>>> -	-../src/$(TARGET) -e "winhelp=1" $(D)plotstyles.gnu
>>> +	../src/$(TARGET) -e "winhelp=1" $(D)plotstyles.gnu
>
> -../src/$(TARGET)
> '-' before ../src/$(TARGET) gives error in my make system.

Then maybe your make system must be broken beyond repair.  'make' 
implementations do have their differences from each other, but 
prepending '-' to mean "ignore error states from the following command" 
is almost universally valid.

You didn't way: what error does that give, anyway?

> I think it should be corrected.

Like I said before, there is nothing wrong with that line, thus nothing 
to be corrected.

Re: funny behavior at making wgnuplot.chm on mingw from cvs source

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

Hello

Anyway I can make wgnuplot.chm now. I will write temporal commands to make wgnuplot.chm and make
binary packages with new help system.

I really appreciate Bastian M将」rkisch's Hans-Bernhard Br将モker's efforts for making windows help in
chm style.

Regards

Tatsuro

--- Tatsuro MATSUOKA wrote:

> Hello
> 
> --- Hans-Bernhard Brセュ．稾er wrote:
> 
> > On 24.02.2011 20:27, Tatsuro MATSUOKA wrote:
> > > There is a minor typo in makefile.mgw
> > 
> > No.  That's not a typo.  It's correct make syntax to signal that the 
> > return code of this command is to be ignored.
> > 
> > > -	-../src/$(TARGET) -e "winhelp=1" $(D)plotstyles.gnu
> > > +	../src/$(TARGET) -e "winhelp=1" $(D)plotstyles.gnu
> > 
> > > Please correct the above.
> > 
> > Nothing wrong there, so nothing to correct.
> > 
> > > When making png files at make process,
> > >
> > > ./doc2html ../docs/gnuplot.doc ../docs/windows/wgnuplot.html ../docs/windows/wgnuplot.hhc
> > > cd ../docs/
> > > ../src/gnuplot.exe -e "winhelp=1" ../docs/plotstyles.gnu
> > >
> > > set output out . 'figure_lines' . ext
> > >                                       ^
> > > cannot open file; output not changed
> > 
> > Whatever's actually wrong with that is in plotstyles.gnu, not in the 
> > makefile.
> Indeed. But '../src/gnuplot.exe -e "winhelp=1" ../docs/plotstyles.gnu' works correct when I
> execute it
> outside of the make.
> 
> Not understandable !!
> If someone suggest me the possibilities, it would be grateful.
> 
> Regards
> 
> Tatsuro
> 
> Regards
>  
> 
> 
> ------------------------------------------------------------------------------
> Free Software Download: Index, Search & Analyze Logs and other IT data in 
> Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
> generated by your applications, servers and devices whether physical, virtual
> or in the cloud. Deliver compliance at lower cost and gain new business 
> insights. http://p.sf.net/sfu/splunk-dev2dev 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: funny behavior at making wgnuplot.chm on mingw from cvs source

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

Hello

--- Hans-Bernhard Br将モker wrote:

> On 24.02.2011 20:27, Tatsuro MATSUOKA wrote:
> > There is a minor typo in makefile.mgw
> 
> No.  That's not a typo.  It's correct make syntax to signal that the 
> return code of this command is to be ignored.
> 
> > -	-../src/$(TARGET) -e "winhelp=1" $(D)plotstyles.gnu
> > +	../src/$(TARGET) -e "winhelp=1" $(D)plotstyles.gnu
> 
> > Please correct the above.
> 
> Nothing wrong there, so nothing to correct.
> 
> > When making png files at make process,
> >
> > ./doc2html ../docs/gnuplot.doc ../docs/windows/wgnuplot.html ../docs/windows/wgnuplot.hhc
> > cd ../docs/
> > ../src/gnuplot.exe -e "winhelp=1" ../docs/plotstyles.gnu
> >
> > set output out . 'figure_lines' . ext
> >                                       ^
> > cannot open file; output not changed
> 
> Whatever's actually wrong with that is in plotstyles.gnu, not in the 
> makefile.
Indeed. But '../src/gnuplot.exe -e "winhelp=1" ../docs/plotstyles.gnu' works correct when I execute it
outside of the make.

Not understandable !!
If someone suggest me the possibilities, it would be grateful.

Regards

Tatsuro

Regards
 

Fwd: Re: funny behavior at making wgnuplot.chm on mingw from cvs source

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

This is a forwarded message because I have forgotten cc. to the gnuplot-beta list.

--- Tatsuro MATSUOKA wrote:

> Date:Fri, 25 Feb 2011 06:12:01 +0900 (JST)
> From:Tatsuro MATSUOKA <tma...@ya...>
> Subject:Re: funny behavior at making  wgnuplot.chm on mingw from cvs source
> To:Hans-Bernhard Br将モker <HBB...@t-...>
> 
> > > -	-../src/$(TARGET) -e "winhelp=1" $(D)plotstyles.gnu
> > > +	../src/$(TARGET) -e "winhelp=1" $(D)plotstyles.gnu
> 
> -../src/$(TARGET)
> '-' before ../src/$(TARGET) gives error in my make system.
> I think it should be corrected.
> 
> --- Hans-Bernhard Br将モker wrote:
> 
> > On 24.02.2011 20:27, Tatsuro MATSUOKA wrote:
> > > There is a minor typo in makefile.mgw
> > 
> > No.  That's not a typo.  It's correct make syntax to signal that the 
> > return code of this command is to be ignored.
> > 
> > > -	-../src/$(TARGET) -e "winhelp=1" $(D)plotstyles.gnu
> > > +	../src/$(TARGET) -e "winhelp=1" $(D)plotstyles.gnu
> > 
> > > Please correct the above.
> > 
> > Nothing wrong there, so nothing to correct.
> > 
> > > When making png files at make process,
> > >
> > > ./doc2html ../docs/gnuplot.doc ../docs/windows/wgnuplot.html ../docs/windows/wgnuplot.hhc
> > > cd ../docs/
> > > ../src/gnuplot.exe -e "winhelp=1" ../docs/plotstyles.gnu
> > >
> > > set output out . 'figure_lines' . ext
> > >                                       ^
> > > cannot open file; output not changed
> > 
> > Whatever's actually wrong with that is in plotstyles.gnu, not in the 
> > makefile.
> > 
> 
> 

Re: funny behavior at making wgnuplot.chm on mingw from cvs source

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

On 24.02.2011 20:27, Tatsuro MATSUOKA wrote:
> There is a minor typo in makefile.mgw

No.  That's not a typo.  It's correct make syntax to signal that the 
return code of this command is to be ignored.

> -	-../src/$(TARGET) -e "winhelp=1" $(D)plotstyles.gnu
> +	../src/$(TARGET) -e "winhelp=1" $(D)plotstyles.gnu

> Please correct the above.

Nothing wrong there, so nothing to correct.

> When making png files at make process,
>
> ./doc2html ../docs/gnuplot.doc ../docs/windows/wgnuplot.html ../docs/windows/wgnuplot.hhc
> cd ../docs/
> ../src/gnuplot.exe -e "winhelp=1" ../docs/plotstyles.gnu
>
> set output out . 'figure_lines' . ext
>                                       ^
> cannot open file; output not changed

Whatever's actually wrong with that is in plotstyles.gnu, not in the 
makefile.

funny behavior at making wgnuplot.chm on mingw from cvs source

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

Hello

I am now trying to make wgnuplot.chm on MinGW using the cvs source.

There is a minor typo in makefile.mgw
************
--- makefile.mgw.orig	2011-02-22 02:51:47 +0900
+++ makefile.mgw	2011-02-25 04:03:48 +0900
@@ -467,7 +467,7 @@
 $(BUILDHELPFILE): doc2html.exe $(D)gnuplot.doc $(D)windows/wgnuplot.hhp $(D)windows/wgnuplot.hhk
$(D)windows/wgnuplot.stp $(D)plotstyles.gnu
 	./doc2html $(D)gnuplot.doc $(D)windows/wgnuplot.html $(D)windows/wgnuplot.hhc
 	cd $(D)
-	-../src/$(TARGET) -e "winhelp=1" $(D)plotstyles.gnu
+	../src/$(TARGET) -e "winhelp=1" $(D)plotstyles.gnu
 	cd ../src
 	-$(HHC) $(D)windows/wgnuplot.hhp
**************

Please correct the above.

When making png files at make process,

./doc2html ../docs/gnuplot.doc ../docs/windows/wgnuplot.html ../docs/windows/wgnuplot.hhc
cd ../docs/
../src/gnuplot.exe -e "winhelp=1" ../docs/plotstyles.gnu

set output out . 'figure_lines' . ext
                                     ^
cannot open file; output not changed
"../docs/plotstyles.gnu", line 21: util.c: No such file or directory

make: *** [../docs/windows/wgnuplot.chm] Error 1
make: Leaving directory `/home/gnuplotcvs/gnuplot/src'

However,  at <snip>/gnuplot/docs directory, I manually tried

***************************************************************
$ ../src/gnuplot.exe -e "winhelp=1" ../docs/plotstyles.gnu

$ /c/Progra~1/HELPWO~1/hhc ../docs/windows/wgnuplot.hhp
Microsoft HTML Help Compiler 4.74.8702

Compiling c:\usr\Tatsu\mingwhome\gnuplotcvs\gnuplot\docs\windows\wgnuplot.chm


Compile time: 0 minutes, 13 seconds
504     Topics
1,004   Local links
52      Internet links
34      Graphics


Created c:\usr\Tatsu\mingwhome\gnuplotcvs\gnuplot\docs\windows\wgnuplot.chm, 599,829 bytes
Compression decreased file by 1,118,522 bytes.
*******************************************

No error appear concerning ../docs/plotstyles.gnu.

???

Anyway I can get the wgnuplot.chm.  Thanks!!

Regards

Tatsuro

Re: Escaping special characters in LaTeX output [was: Lua/TikZ terminal patch update on patch tracker]

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

On Wed, Feb 23, 2011 at 22:36, Peter Hedwig wrote:
> Am Mittwoch, 23. Februar 2011 schrieb sfeam (Ethan Merritt):
>
> Providing a translation table would be better, because some characters can
> be escaped with a backslash, others like tilde "~" should be translated to
> \textasciitilde{} or $\sim$.

I agree at least with the point that one cannot treat special
characters in a uniform way (there is no simple transformation like
"add a backslash in front of a character" that would make all the
characters work).

>> But is there an all-purpose escape mechanism in TeX?

You could modify strings by replacing each $ with \$ etc., but it is
almost impossible to cover them all; in particular, modification that
might work with LaTeX may not work with ConTeXt etc.

The only really reliable way is to redefine \catcode-s of all special
characters and enter "a special mode" before reading the string and
quitting it after we're done.

>> That is, can you mark a string somehow so that every character in
>> it is printed with no interpretation or processing whatsoever?
>
> AFAIK there is no such mechanism. There are packages that do similar things,
> e.g. "verbatim", "listings" or "url" for LaTeX but I don't know any that
> works with all TeX flavors.

ConTeXt offers
    \type{some %$^ \command}
but LaTeX has a different syntax, requires different packages, plain
TeX is yet different, just like Peter said.

The only reliable way to do it is the following:

- First, you need to select a command that will start literal string,
but most important: a sequence that will end it (that is the most
tricky part). You could print out something like
    \beginverbatim some \weird %$^_ string \not \interpreted \endverbatim
Implementing \beginverbatim is easy ... apart from the fact that you
need to catch \endverbatim and you need to be aware that
    set title "abc \some \harmless \command $% \enverbatim %"
will fail or you will need even more extra trickery.

- You need to define \beginverbatim at the begining of file that you
output with latex terminal (or one could put that definition to
gnuplot-tikz-common.tex for example). It has to redefine all the
catcodes, lccodes etc. Basically it needs to reimplement what packages
like verbatim or listings do in LaTeX, so that it won't switch the
font to typewriter, yet it will handle characters literally. It has to
be portable between plain/latex/context. (Honestly I'm not sure how to
handle UTF-8 characters in plain TeX.)

This requires a skilled TeX freak (or somebody who takes time to study
the TeXbook and code that handles verbatim in LaTeX and/or ConTeXt as
some hints). I know only approximately what needs to be done, but I
would need an enormous amount of time to come up with implementation
(I'm not sure how to implement the string that quits verbatim).
However there are some mailing list where people might be willing to
help with that.

Mojca

Re: text alignment

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

Am 24.02.2011 08:02, schrieb Benjamin Lindner:
>> working with the windows terminal I noticed that it places characters
>> significantly lower than other terminals. The reason for this is that
>> this terminal places text with respect to the baseline of the font,
>> whereas other terminals seem to place fonts wrt the bottom of the
>> character cell. Why is the behaviour of the windows terminal not correct?
>
> What exactly is not correct?
> Are you referring to subscripting text?
> Or do you mean that text positioned at x,y is actually placed below y?
> Or do you mean the vertical alignment of e.g. ytic labels is shifted downwards?
>

Yes, the vertical placement of strings wrt to the tics for example is 
different for windows. Relative placement within (enhanced) text is fine.

This is why I checked when this turned up: version 4.0 has TA_BOTTOM 
alignment and version 4.2 onward use TA_BASELINE.


> The latter is due to the fact that gnuplot determines the height of
> the character to be displayed using the GetTextExtent API which
> returns the nominal total height of the font in question *not* of the
> string/character under test, and is thus too large.
> Try setting
>     GetTextMetrics(hdc,(TEXTMETRIC FAR *)&tm);
>     cy = lpgw->fontsize;
> in wgraph.c:MakeFonts(), and compare the positioning of the ytic labels
>
>
>> Anyway, this probably means that we should revert my changes from almost
>> exactly 5 years back and replace TA_BASELINE with TA_BOTTOM in
>> src/win/wgraph.c. Makes me wonder why nobody (including me) noticed this
>> earlier.
>
> Are you really sure that this is the correct way of doing it?
> IIRC tex sets charaters wrt to the baseline of the font, and not the
> bottom line.
> The bottom line varies from character to charater, the baseline by
> definition not.
> So setting 'a' followed by 'g' wrt to the bottom line would shift the
> 'g' upwards which certainly is not what's intended, isn't it?
>

You are correct. Simply using TA_BOTTOM is not the solution. But I am 
not talking about placement of different characters within a string 
(using the same font and size). That is done correctly in both cases 
since all characters of a font share the same box. But it does no longer 
work with TA_BOTTOM if you change fonts or sizes. This is why I changed 
the windows code from TA_BOTTOM to TA_BASELINE when I introduced 
enhanced text for the windows terminal. Otherwise this would not be on 
the same baseline:

set label 1 at 1, 4 "Will {/*2 this} be {/*4 aligned}{/*5?}"

The problem becomes apparent given this information from Hans-Bernhard 
Bröker:
   "Actually, no.  The terminal API defines the reference to be the
   center line of the font (basically the upper edge of an 'm').
   That's what many of those offsets by lpgw->vchar / 2 are about.
   See "vshift" also. "

So this is what I meant: the windows terminal interprets the vertical 
placement of the string with respect to the baseline, whereas the 
gnuplot core code expects alignment wrt to the centre of the character box.

This gets more obvious if you look at the output of "test": "wxt" eg. 
puts the test string "123456..." vertically centred, whereas for 
"windows" it is clearly shifted down.


That aside, there seem to be rather strong disagreements about the 
vertical placements of enhanced text. Try the following script on 
different terminals:

   set termoption enhanced
   set xrange [0:10]
   set yrange [0:10]
   set xtics 1
   set ytics 1
   set grid
   set label 1 at 1, 8 "y=8: Is {/*2 this} text {/*4 aligned}{/*5?}"
   set label 2 at 1, 6 "y=6: What about {/=24 Symbols}  {/Symbol=24 
abcdef} {/Symbol=48 ghijklm}?"
   set label 3 at 1, 4 "y=4: Normal big label in 32pt" font ",32"
   set label 4 at 1, 2 "y=2: Normal big label in 64pt" font ",64"
   plot NaN not

It tried this with `font "Arial/Helvetica, 16pt"` and found large 
differences between windows, wxt, pngcairo, png (classic) and 
postscript. I am convinced that those differences cannot be explained 
solely by the different knowledge terminals have about the fonts.

Some observations:
png: keeps the baseline stable for all labels, but displays label 3 and 
4 in 16pt. The vertical position seems to be determined by the first 
character.

pngcairo: label 3 is centred, whereas labels 1 and 2 are shifted 
downwards. label 1 does not even touch the y=8 line. label 3 and 4 look 
vertically centred.

wxt: not the same as pngcairo

postscript: Vertical position seems to be centred wrt to the bounding 
box of the label.


Those are admittedly extreme test cases. But as a user I would expect 
more consistent behaviour.


Bastian

Re: text alignment

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

> working with the windows terminal I noticed that it places characters
> significantly lower than other terminals. The reason for this is that
> this terminal places text with respect to the baseline of the font,
> whereas other terminals seem to place fonts wrt the bottom of the
> character cell. Why is the behaviour of the windows terminal not correct?

What exactly is not correct?
Are you referring to subscripting text?
Or do you mean that text positioned at x,y is actually placed below y?
Or do you mean the vertical alignment of e.g. ytic labels is shifted downwards?

The latter is due to the fact that gnuplot determines the height of
the character to be displayed using the GetTextExtent API which
returns the nominal total height of the font in question *not* of the
string/character under test, and is thus too large.
Try setting
   GetTextMetrics(hdc,(TEXTMETRIC FAR *)&tm);
   cy = lpgw->fontsize;
in wgraph.c:MakeFonts(), and compare the positioning of the ytic labels


> Anyway, this probably means that we should revert my changes from almost
> exactly 5 years back and replace TA_BASELINE with TA_BOTTOM in
> src/win/wgraph.c. Makes me wonder why nobody (including me) noticed this
> earlier.

Are you really sure that this is the correct way of doing it?
IIRC tex sets charaters wrt to the baseline of the font, and not the
bottom line.
The bottom line varies from character to charater, the baseline by
definition not.
So setting 'a' followed by 'g' wrt to the bottom line would shift the
'g' upwards which certainly is not what's intended, isn't it?

benjamin

text alignment

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

Hello,

working with the windows terminal I noticed that it places characters 
significantly lower than other terminals. The reason for this is that 
this terminal places text with respect to the baseline of the font, 
whereas other terminals seem to place fonts wrt the bottom of the 
character cell. Why is the behaviour of the windows terminal not correct?

Anyway, this probably means that we should revert my changes from almost 
exactly 5 years back and replace TA_BASELINE with TA_BOTTOM in 
src/win/wgraph.c. Makes me wonder why nobody (including me) noticed this 
earlier.

Bastian

Re: wgnuplot help texts

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

On Wednesday, February 23, 2011 06:39:20 am Bastian Märkisch wrote:
> 
> Some of the help texts defined in win.trm are not really related to the 
> `windows` terminal, but to the graphical windows front end "wgnuplot". 
> In my opinion those sections (text-menu, wgnuplot.mnu, parts of 
> wgnuplot.ini) should be moved to gnuplot.doc. Which section would be 
> appropriate? "Graphical User Interfaces?"

That sounds reasonable.

wgnuplot help texts

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

Some of the help texts defined in win.trm are not really related to the 
`windows` terminal, but to the graphical windows front end "wgnuplot". 
In my opinion those sections (text-menu, wgnuplot.mnu, parts of 
wgnuplot.ini) should be moved to gnuplot.doc. Which section would be 
appropriate? "Graphical User Interfaces?"

Bastian

Re: gnuplot manual misprint (no.35)

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

On Tuesday, February 22, 2011, Bastian Märkisch wrote:
> Thanks for noticing. Some of your observations were caused by a specific 
> change made by me. I disabled some html anchors in gnuplot.doc, like this:
> 
> ^ <a name="start-up"></a>
> 
> I thought they were leftovers from times when the (real) HTML 
> documentation was generated directly from gnuplot.doc.
> It turns out that really doc2tex(!) interprets them.

It interprets them as an internal link, which mean they could be replaced
by "see `start-up`"    (NB: The word "see" is required).

The other doc2XXX routines ignore lines starting with '^'.

But some of them are nonsense anyhow. They should be deleted.
For example:
^ <a name="arrowtype"></a>
^ <a name="arrowwidth"></a>

There are no entries for arrowtype or arrowwidth, so these links are dead.

	Ethan


> 
> In addition to the anchor definitions you have found
> 
>    "start-up", "Time/Date data", "Time/date", "positive", "negative"
> 
> the following have also been removed by me:
> 
>    "save set", "set style <style>", "arrowtype", "arrowwidth"
> 
> We could easily put those definitions back in, but I doubt that this is 
> the best solution. Any propositions?
> 
> I will look at doc2* to find out what other surprises there are.
> 
> Bastian
> 
> 
> Am 22.02.2011 12:08, schrieb Shigeharu TAKENO:
> > shige 02/22 2011
> > ----------------
> >
> > In docs/gnuplot.doc of current CVS version
> >
> >   C RCS $Id: gnuplot.doc,v 1.651 2011/02/21 17:58:39 markisch Exp $
> >
> > I found the following points:
> >
> > 1) they may not be referenced by the .tex document translated by
> >    doc2tex (`start-up`, `positive`, `negative`, `Time/date`, and
> >    `Seeking-assistance`)
> > 2) they may be misprints (strings ->  string, stdout ->  string,
> >    interpolation ->  interpolate)
> > 3) they may not be translated to tabular lines correctly in win
> >    help (for rand)
> >
> > +========================================================+
> >   Shigeharu TAKENO     NIigata Institute of Technology
> >                         kashiwazaki,Niigata 945-1195 JAPAN
> >   sh...@ie...   TEL(&FAX): +81-257-22-8161
> > +========================================================+

Escaping special characters in LaTeX output [was: Lua/TikZ terminal patch update on patch tracker]

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

See also 
Feature Request 1848048 	"latex driver could intelligently add escape sequences" 	
https://sourceforge.net/tracker/index.php?func=detail&aid=1848048&group_id=2055&atid=352055

On Tuesday, February 22, 2011, Peter Hedwig wrote:
> [I]magine a file where you have a column with e.g. currencies or percent
> symbols that should be added to the plot. Giving a simple way to achieve
> this could be nice, too. Not everyone is into sed and awk.

That much sounds easy on the gnuplot end.  Add a new keyword
  set datafile literal_strings
and then wrap any strings read from that particular file with escape
characters appropriate to the current terminal.

But is there an all-purpose escape mechanism in TeX?
That is, can you mark a string somehow so that every character in
it is printed with no interpretation or processing whatsoever?

	Ethan

Re: gnuplot manual misprint (no.35)

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

Thanks for noticing. Some of your observations were caused by a specific 
change made by me. I disabled some html anchors in gnuplot.doc, like this:

^ <a name="start-up"></a>

I thought they were leftovers from times when the (real) HTML 
documentation was generated directly from gnuplot.doc.
It turns out that really doc2tex(!) interprets them.

In addition to the anchor definitions you have found

   "start-up", "Time/Date data", "Time/date", "positive", "negative"

the following have also been removed by me:

   "save set", "set style <style>", "arrowtype", "arrowwidth"

We could easily put those definitions back in, but I doubt that this is 
the best solution. Any propositions?

I will look at doc2* to find out what other surprises there are.

Bastian


Am 22.02.2011 12:08, schrieb Shigeharu TAKENO:
> shige 02/22 2011
> ----------------
>
> In docs/gnuplot.doc of current CVS version
>
>   C RCS $Id: gnuplot.doc,v 1.651 2011/02/21 17:58:39 markisch Exp $
>
> I found the following points:
>
> 1) they may not be referenced by the .tex document translated by
>    doc2tex (`start-up`, `positive`, `negative`, `Time/date`, and
>    `Seeking-assistance`)
> 2) they may be misprints (strings ->  string, stdout ->  string,
>    interpolation ->  interpolate)
> 3) they may not be translated to tabular lines correctly in win
>    help (for rand)
>
> ----- From here -----
> --- gnuplot.doc.ORG	2011-02-22 19:28:07.000000000 +0900
> +++ gnuplot.doc	2011-02-22 19:32:49.000000000 +0900
> @@ -674,7 +674,7 @@
>    If GNUTERM is defined, it is used as the name of the terminal type to be
>    used.  This overrides any terminal type sensed by `gnuplot` on start-up, but
>    is itself overridden by the .gnuplot (or equivalent) start-up file
> - (see `start-up`) and, of course, by later explicit changes.
> + (see `startup`) and, of course, by later explicit changes.
>
>    GNUHELP may be defined to be the pathname of the HELP file (gnuplot.gih).
>
> @@ -854,11 +854,11 @@
>   ^<tr>	<td>gprintf("format",x)</td>	<td>any</td>	<td>string result from applying gnuplot's format parser</td></tr>
>   ^<tr>	<td>sprintf("format",x,...)</td>	<td>multiple</td>	<td>string result from C-language sprintf</td></tr>
>   ^<tr>	<td>strlen("string")</td>	<td>string</td>	<td>int length of string</td></tr>
> -^<tr>	<td>strstrt("string","key")</td>	<td>strings</td>	<td>int index of first character of substring "key"</td></tr>
> +^<tr>	<td>strstrt("string","key")</td>	<td>string</td>	<td>int index of first character of substring "key"</td></tr>
>   ^<tr>	<td>substr("string",beg,end)</td>	<td>multiple</td>	<td>string "string"[beg:end]</td></tr>
>   ^<tr>	<td>strftime("timeformat",t)</td>	<td>any</td>	<td>string result from applying gnuplot's time parser</td></tr>
>   ^<tr>	<td>strptime("timeformat",s)</td>	<td>string</td>	<td>seconds since year 2000 as given in string s</td></tr>
> -^<tr>	<td>system("command")</td>	<td>string</td>	<td>stdout containing output stream of shell command</td></tr>
> +^<tr>	<td>system("command")</td>	<td>string</td>	<td>string containing output stream of shell command</td></tr>
>   ^<tr>	<td>word("string",n)</td>	<td>string, int</td>	<td>returns the nth word in "string"</td></tr>
>   ^<tr>	<td>words("string")</td>	<td>string</td>	<td>returns the number of words in "string"</td></tr>
>   ^</tbody>
> @@ -1226,10 +1226,10 @@
>   ?rand
>   #rand(x)&  int&  pseudo random number in the interval [0:1] \\
>   %rand(x)@int@pseudo random number in the interval [0:1]
> - `rand(0)`  returns a pseudo random number in the interval [0:1]
> - `rand(-1)` resets both seeds to a standard value.
> - `rand(x)`  for integer 0<  x<  2^31-1 sets both internal seeds to x
> - `rand({x,y})` for integer 0<  x,y<  2^31-1 sets seed1 to x and seed2 to y.
> +  `rand(0)`  returns a pseudo random number in the interval [0:1]
> +  `rand(-1)` resets both seeds to a standard value.
> +  `rand(x)`  for integer 0<  x<  2^31-1 sets both internal seeds to x
> +  `rand({x,y})` for integer 0<  x,y<  2^31-1 sets seed1 to x and seed2 to y.
>   4 real
>   ?expressions functions real
>   ?functions real
> @@ -9960,7 +9960,7 @@
>    is interpolated m-times and n-times in the respective direction.  For negative
>    m and n, the interpolation frequency is chosen so that there will be at least
>    |m| and |n| points drawn; you can consider this as a special gridding function.
> - Zeros, i.e. `interpolation 0,0`, will automatically choose an optimal number of
> + Zeros, i.e. `interpolate 0,0`, will automatically choose an optimal number of
>    interpolated surface points.
>   4 deprecated_options
>   ?pm3d deprecated_options
> @@ -10106,7 +10106,7 @@
>    mapping functions are listed by `show palette rgbformulae`.  Default is
>    `7,5,15`, some other examples are `3,11,6`, `21,23,3` or `3,23,21`.  Negative
>    numbers, like `3,-11,-6`, mean inverted color (i.e.  1-gray passed into the
> - formula, see also `positive` and `negative` options below).
> + formula).
>
>    Some nice schemes in RGB color space
>       7,5,15   ... traditional pm3d (black-blue-red-yellow)
> @@ -11438,7 +11438,7 @@
>    the UNIX98 spec, but conventions vary widely and two-digit year values are
>    inherently ambiguous.
>
> - See also `set xdata` and `Time/date` for more information.
> + See also `set xdata` and `time/date` for more information.
>
>    Example:
>          set timefmt "%d/%m/%Y\t%H:%M"
> @@ -11697,7 +11697,7 @@
>    for this  unless the `set format x "string"` has supplied something that does
>    not look like a decimal format (more than one '%' or neither %f nor %g).
>
> - See also `Time/date` for more information.
> + See also `time/date` for more information.
>   3 xdtics
>   ?commands set xdtics
>   ?commands unset xdtics
> @@ -12972,7 +12972,7 @@
>    Or upload the report to the gnuplot web site on SourceForge.
>    Please give complete information on the version of gnuplot you are using
>    and, if possible, a test script that demonstrates the bug.
> - See `Seeking-assistance`.
> + See `seeking-assistance`.
>
>    The sections below list problems known to be present in gnuplot version 4.4 at
>    the time of release.  Some of these are actually bugs in external support
> ----- To here -----
>
> +========================================================+
>   Shigeharu TAKENO     NIigata Institute of Technology
>                         kashiwazaki,Niigata 945-1195 JAPAN
>   sh...@ie...   TEL(&FAX): +81-257-22-8161
> +========================================================+
>
> ------------------------------------------------------------------------------
> Index, Search&  Analyze Logs and other IT data in Real-Time with Splunk
> Collect, index and harness all the fast moving IT data generated by your
> applications, servers and devices whether physical, virtual or in the cloud.
> Deliver compliance at lower cost and gain new business insights.
> Free Software Download: http://p.sf.net/sfu/splunk-dev2dev
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

gnuplot manual misprint (no.35)

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

shige 02/22 2011
----------------

In docs/gnuplot.doc of current CVS version

 C RCS $Id: gnuplot.doc,v 1.651 2011/02/21 17:58:39 markisch Exp $

I found the following points:

1) they may not be referenced by the .tex document translated by
  doc2tex (`start-up`, `positive`, `negative`, `Time/date`, and
  `Seeking-assistance`)
2) they may be misprints (strings -> string, stdout -> string,
  interpolation -> interpolate)
3) they may not be translated to tabular lines correctly in win 
  help (for rand) 

----- From here -----
--- gnuplot.doc.ORG	2011-02-22 19:28:07.000000000 +0900
+++ gnuplot.doc	2011-02-22 19:32:49.000000000 +0900
@@ -674,7 +674,7 @@
  If GNUTERM is defined, it is used as the name of the terminal type to be
  used.  This overrides any terminal type sensed by `gnuplot` on start-up, but
  is itself overridden by the .gnuplot (or equivalent) start-up file
- (see `start-up`) and, of course, by later explicit changes.
+ (see `startup`) and, of course, by later explicit changes.
 
  GNUHELP may be defined to be the pathname of the HELP file (gnuplot.gih).
 
@@ -854,11 +854,11 @@
 ^<tr>	<td>gprintf("format",x)</td>	<td>any</td>	<td>string result from applying gnuplot's format parser</td></tr>
 ^<tr>	<td>sprintf("format",x,...)</td>	<td>multiple</td>	<td>string result from C-language sprintf</td></tr>
 ^<tr>	<td>strlen("string")</td>	<td>string</td>	<td>int length of string</td></tr>
-^<tr>	<td>strstrt("string","key")</td>	<td>strings</td>	<td>int index of first character of substring "key"</td></tr>
+^<tr>	<td>strstrt("string","key")</td>	<td>string</td>	<td>int index of first character of substring "key"</td></tr>
 ^<tr>	<td>substr("string",beg,end)</td>	<td>multiple</td>	<td>string "string"[beg:end]</td></tr>
 ^<tr>	<td>strftime("timeformat",t)</td>	<td>any</td>	<td>string result from applying gnuplot's time parser</td></tr>
 ^<tr>	<td>strptime("timeformat",s)</td>	<td>string</td>	<td>seconds since year 2000 as given in string s</td></tr>
-^<tr>	<td>system("command")</td>	<td>string</td>	<td>stdout containing output stream of shell command</td></tr>
+^<tr>	<td>system("command")</td>	<td>string</td>	<td>string containing output stream of shell command</td></tr>
 ^<tr>	<td>word("string",n)</td>	<td>string, int</td>	<td>returns the nth word in "string"</td></tr>
 ^<tr>	<td>words("string")</td>	<td>string</td>	<td>returns the number of words in "string"</td></tr>
 ^</tbody>
@@ -1226,10 +1226,10 @@
 ?rand
 #rand(x) & int & pseudo random number in the interval [0:1] \\
 %rand(x)@int@pseudo random number in the interval [0:1]
- `rand(0)`  returns a pseudo random number in the interval [0:1]
- `rand(-1)` resets both seeds to a standard value.
- `rand(x)`  for integer 0 < x < 2^31-1 sets both internal seeds to x
- `rand({x,y})` for integer 0 < x,y < 2^31-1 sets seed1 to x and seed2 to y.
+  `rand(0)`  returns a pseudo random number in the interval [0:1]
+  `rand(-1)` resets both seeds to a standard value.
+  `rand(x)`  for integer 0 < x < 2^31-1 sets both internal seeds to x
+  `rand({x,y})` for integer 0 < x,y < 2^31-1 sets seed1 to x and seed2 to y.
 4 real
 ?expressions functions real
 ?functions real
@@ -9960,7 +9960,7 @@
  is interpolated m-times and n-times in the respective direction.  For negative
  m and n, the interpolation frequency is chosen so that there will be at least
  |m| and |n| points drawn; you can consider this as a special gridding function.
- Zeros, i.e. `interpolation 0,0`, will automatically choose an optimal number of
+ Zeros, i.e. `interpolate 0,0`, will automatically choose an optimal number of
  interpolated surface points.
 4 deprecated_options
 ?pm3d deprecated_options
@@ -10106,7 +10106,7 @@
  mapping functions are listed by `show palette rgbformulae`.  Default is
  `7,5,15`, some other examples are `3,11,6`, `21,23,3` or `3,23,21`.  Negative
  numbers, like `3,-11,-6`, mean inverted color (i.e.  1-gray passed into the
- formula, see also `positive` and `negative` options below).
+ formula).
 
  Some nice schemes in RGB color space
     7,5,15   ... traditional pm3d (black-blue-red-yellow)
@@ -11438,7 +11438,7 @@
  the UNIX98 spec, but conventions vary widely and two-digit year values are
  inherently ambiguous.
 
- See also `set xdata` and `Time/date` for more information.
+ See also `set xdata` and `time/date` for more information.
 
  Example:
        set timefmt "%d/%m/%Y\t%H:%M"
@@ -11697,7 +11697,7 @@
  for this  unless the `set format x "string"` has supplied something that does
  not look like a decimal format (more than one '%' or neither %f nor %g).
 
- See also `Time/date` for more information.
+ See also `time/date` for more information.
 3 xdtics
 ?commands set xdtics
 ?commands unset xdtics
@@ -12972,7 +12972,7 @@
  Or upload the report to the gnuplot web site on SourceForge.
  Please give complete information on the version of gnuplot you are using
  and, if possible, a test script that demonstrates the bug.
- See `Seeking-assistance`.
+ See `seeking-assistance`.
 
  The sections below list problems known to be present in gnuplot version 4.4 at
  the time of release.  Some of these are actually bugs in external support
----- To here -----

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

Re: Cannot find htmlhelp.h in cvs source (2011-2011-02-21) for MinGW build

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

Hello

Thanks. I found it in the html directory trees. I will try it later.

Regards

Tatsuro
--- Hans-Bernhard Br将モker <HBB...@t-...> wrote:

> On 21.02.2011 20:23, Tatsuro MATSUOKA wrote:
> 
> > command.c:134:25: fatal error: htmlhelp.h: No such file or directory
> > compilation terminated.
> >
> > I have searched htmlhelp.h by windows explorer but I cannot find it.
> > Where can I find htmlhelp.h?
> 
> An up-to-date set of Windows API headers (a.k.a. SDK) is supposed to 
> contain it.  MinGW should have its own, but if nothing else helps, you 
> can grab the one installed along with HTML help workshop.
> 

Re: Cannot find htmlhelp.h in cvs source (2011-2011-02-21) for MinGW build

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

On 21.02.2011 20:23, Tatsuro MATSUOKA wrote:

> command.c:134:25: fatal error: htmlhelp.h: No such file or directory
> compilation terminated.
>
> I have searched htmlhelp.h by windows explorer but I cannot find it.
> Where can I find htmlhelp.h?

An up-to-date set of Windows API headers (a.k.a. SDK) is supposed to 
contain it.  MinGW should have its own, but if nothing else helps, you 
can grab the one installed along with HTML help workshop.

Re: Cannot find htmlhelp.h in cvs source (2011-2011-02-21) for MinGW build

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

Hello,

you have to have the Windows HTML Help Workshop installed. You find it at:
http://go.microsoft.com/fwlink/?LinkId=154968

Please also update the variable for the installation path HHWPATH in 
makefile.mgw accordingly.

Thanks for trying it out that quickly!

Best wishes,
Bastian


Am 21.02.2011 20:23, schrieb Tatsuro MATSUOKA:
> Hello
>
> I have trying new build system for windows help in chm style.
> I have met following error.
>
> gcc -shared-libgcc -c -I/home/gnuplotcvs/gnuplot/src -I/c/Programs/gpnewlib/include -O3 -I.. -I.
> -D_Windows -DHAVE_CONFIG_H -DPIPES -DWGP_CONSOLE -DUSE_MOUSE=1 -DWIN_IPC -DWITH_HTML_HELP
> -I/c/rogra~1/HTML\ Help\ Workshop/include -DHAVE_LIBGD -DHAVE_LIBPNG -DHAVE_GD_GIF -DGIF_ANIMATION
> -DHAVE_GD_PNG -DHAVE_GD_JPEG -DHAVE_GD_TTF -DHAVE_CAIROPDF -DWXWIDGETS -DHAVE_LUA command.c
> command.c:134:25: fatal error: htmlhelp.h: No such file or directory
> compilation terminated.
>
> I have searched htmlhelp.h by windows explorer but I cannot find it.
> Where can I find htmlhelp.h?
>
> Regards
>
> Tatsuro
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Cannot find htmlhelp.h in cvs source (2011-2011-02-21) for MinGW build

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

Hello

I have trying new build system for windows help in chm style.
I have met following error.

gcc -shared-libgcc -c -I/home/gnuplotcvs/gnuplot/src -I/c/Programs/gpnewlib/include -O3 -I.. -I.
-D_Windows -DHAVE_CONFIG_H -DPIPES -DWGP_CONSOLE -DUSE_MOUSE=1 -DWIN_IPC -DWITH_HTML_HELP
-I/c/rogra~1/HTML\ Help\ Workshop/include -DHAVE_LIBGD -DHAVE_LIBPNG -DHAVE_GD_GIF -DGIF_ANIMATION
-DHAVE_GD_PNG -DHAVE_GD_JPEG -DHAVE_GD_TTF -DHAVE_CAIROPDF -DWXWIDGETS -DHAVE_LUA command.c
command.c:134:25: fatal error: htmlhelp.h: No such file or directory
compilation terminated.

I have searched htmlhelp.h by windows explorer but I cannot find it.
Where can I find htmlhelp.h?

Regards

Tatsuro

Re: Lua on Ubuntu - again

[Christoph B. <us...@be...>]

Hi,

On 20.02.2011 21:46, sfeam (Ethan Merritt) wrote:
> On Sunday, February 20, 2011, Hans-Bernhard Bröker wrote:
>> Or maybe just move the entire AC_SEARCH_LIBS call into the else branch
>> of the PKG_CHECK_MODULES one.
>
> OK.  Let's try it that way.
> I've put a revised configure.in into CVS.

this current version works for me on Debian squeeze (6.0), where I had 
the same problems described by Péter.

Christoph

Re: Lua on Ubuntu - again

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

On Sunday, February 20, 2011, Hans-Bernhard Bröker wrote:
> Or maybe just move the entire AC_SEARCH_LIBS call into the else branch 
> of the PKG_CHECK_MODULES one.

OK.  Let's try it that way.
I've put a revised configure.in into CVS.

Re: Lua on Ubuntu - again

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

On 18.02.2011 21:42, Ethan A Merritt wrote:

>> In practice this means that the variable LUA_LIBS will be set to "-llua"
>> even if it was explicitly overridden on the command line.
>
> That's not what the AC_SEARCH_LIBS macro is supposed to do,
> according to its documentation.

I don't think the problem is what AC_SEARCH_LIBS does by itself.  It's 
what we do with the result in our call of it.  In our ACTION-IF-FOUND we 
explicitly set LUA_LIBS='-llua' if AC_SEARCH_LIBS succeeded, even though 
we don't know if -llua actually was the library that fulfilled the test. 
  Then later we append $(LUA_LIBS) to TERMLIBS.

> That's because it had already constructed a correct environment by
> executing pkgconfig.

But we don't trust it, and thus decide to override the result.  That's 
where the problem is.

We need to check the result variable ac_cv_search_luaL_openlibs.  If it 
contains "none_needed", we should leave alone LUA_LIBS, otherweise 
append $(ac_cv_search_luaL_openlibs) instead of a hardcoded value.

> The intent is that even if we failed to find or invoke pkgconfig, we can
> still test if -llua is sufficient to pull in the library.

But as-is we unconditionally pull in -llua, even if the actual library 
name is a different one.

> OK.  That line
>      LUA_LIBS='-llua'
> is quite possibly wrong.  But if you remove it, then you also have to
> also remove the fourth line below it:
>      LIBS='$_libs"

It should suffice to move the line into the ACTION-IF-NOT-FOUND branch 
of the AC_SEARCH_LIBS call.

Or maybe just move the entire AC_SEARCH_LIBS call into the else branch 
of the PKG_CHECK_MODULES one.

Re: Identifying system with macro

[Andrea D'A. <and...@gm...>]

2011/2/18 Hans-Bernhard Bröker <HBB...@t-...>:
> The old one that (still) defined _Macintosh, and the new one that defines
> __APPLE__ instead.

Do you mean changing that would break support for Apple's System serie
of operating systems?

Is there anyone on the list that can confirm such systems can still
build current gnuplot sources?

> Speaking of which, __APPLE__ seems a little too loose to
> be the identifying macro of Mac OS (whatever the current version of it is).

>From what I can see there's little choice, I've seen quite a few
sources in MacPorts and they all use __APPLE__, these are macros on my
system:

$ gcc -dM -E - < /dev/null | grep -i "APPLE\|MAC\|DAR"
#define __APPLE_CC__ 5664
#define __APPLE__ 1
#define __VERSION__ "4.2.1 (Apple Inc. build 5664)"
#define __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ 1066
#define __MACH__ 1


>>> I.e. are there really fonts in
>>> directories like /System/Library/Fonts etc. on a current-day MacOS?
>> Yes, there are.
> Well, OK then.

Even if there weren't fonts an existing empty directory is still
better than a directory not existing at all.

Anyway those are defaults paths for font on OS X, they are
respectively: system, installation specific and user fonts.


Regards

-- 
Andrea

Re: Identifying system with macro

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

On 18.02.2011 22:00, Andrea D'Amore wrote:
> 2011/2/18 Hans-Bernhard Bröker<HBB...@t-...>:

>> Yeah.  But are those platforms themselves as consistent across versions as
>> you're making gnuplot treat them?
>
> What platforms are you referring to with "those"?

The old one that (still) defined _Macintosh, and the new one that 
defines __APPLE__ instead.  Speaking of which, __APPLE__ seems a little 
too loose to be the identifying macro of Mac OS (whatever the current 
version of it is).

>> I.e. are there really fonts in
>> directories like /System/Library/Fonts etc. on a current-day MacOS?

> Yes, there are.

Well, OK then.