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

Re: Print warnings at configuration time? Build time?

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

> Question
> ========
> 
> Should we have ./configure print out a warning if snprintf is not found?
> 
> WARNING:  Could not find a working snprintf() function.
> 	  Buffer overflows and segfaults may be triggered by
> 	  overlong format specifiers provided to gnuplot by the user.
> 	  Please consider providing snprintf via an external library.
> 
> Should we issue the same warning at build time?  Run time?

I see this comment:

 * FIXME: 10 is a purely arbitrary upper limit on args

This could probably be changed so that the arguments are allocated using the heap, making it not limited.

And here is the source of the problem, right?

/* FIXME - this is bad; we should dummy up an snprintf equivalent */

Do we really want to go the route of implementing our own snprintf?  That is a fairly low level routine, isn't it?  Of course, implementing a crude version wouldn't be too difficult.  There is already a search for

    next_length = strcspn(next_start,"%");

one can then look for a size specification fairly easily by trying to read what follows the % as an int, if it fails, then assume some size of, oh, 20 characters.

Would there be some way we can use buffered i/o in the case of not having snprintf?  E.g., send the data to a file, when all done, check the file size then create a memory buffer big enough to hold the contents, then read it back in?  It would be slow on machines that don't have snprintf, but so be it.

Dan

Re: Print warnings at configuration time? Build time?

[<br...@ph...>]

Ethan Merritt wrote:

> This is a general problem, and is mentioned in our TODO
> file but not in the README or INSTALL files.

A note should be added to INSTALL.

> Should we have ./configure print out a warning if snprintf is not found?

Probably.

> Should we issue the same warning at build time?  Run time?

./configure time is build time.  A message at run time would be 
excessive and annoying.

Print warnings at configuration time? Build time?

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

Bernhard Simon has reported a problem with "make check"
run under an older version of AIX.  The stringvar demo
caused a segfault. He obligingly traced it to a buffer
overflow from a code path using sprintf, which we use
only if the system does not provide snprintf. We handle
the test case correctly if snprintf is present.

This is a general problem, and is mentioned in our TODO
file but not in the README or INSTALL files.

Simple test
===========
  manually edit config.h to #undef HAVE_SNPRINTF
  build gnuplot
  run test input
	set format xy "%4096g"
	plot x

With snprintf:
   util.c:595: Warning: too many digits for format
Without snprintf:
   *** glibc detected *** realloc(): invalid next size: 0x085c64c8 ***
   Abort
or (different test machine):
   segfault


Question
========

Should we have ./configure print out a warning if snprintf is not found?

WARNING:  Could not find a working snprintf() function.
	  Buffer overflows and segfaults may be triggered by
	  overlong format specifiers provided to gnuplot by the user.
	  Please consider providing snprintf via an external library.

Should we issue the same warning at build time?  Run time?

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

Re: Problem: incompatible handling of svg files

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

>> I would expect "raw" writes raw 8bit chars or UTF-8 chars, without any
>> textual conversion to &#
>
> Correct. That is what it does.

OK


I've tried the two patches at [ 1578600 ] Two variants of the SVG driver
and patch nb 2 works always, while nb 1 failed (utf-8, svg enha, Czech 
text). I propose to commit nb 2.

---
PM

Re: Problem: incompatible handling of svg files

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

On Tuesday 17 October 2006 12:21 am, Petr Mikulik wrote:
> > Both add a new terminal option
> > 	set term svg {raw|escaped}
> >
> > Variant 1 treats all encodings the same: if the "escaped" option
> > is selected, then non-ascii character are replaced one byte at a
> > time by the corresponding sequence &#xNN;
> 
> I would expect "raw" writes raw 8bit chars or UTF-8 chars, without any 
> textual conversion to &#

Correct. That is what it does.
 
> Then there should be two kinds of the "escape" option, one yours and one for 
> the previous.

Huh? I don't understand what you mean here.
The "escape" option leaves in place what it was doing previously.
Except that the second version knows enough to escape utf-8
sequences correctly, which the previous version didn't. 

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

Re: Problem: incompatible handling of svg files

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

> Both add a new terminal option
> 	set term svg {raw|escaped}
>
> Variant 1 treats all encodings the same: if the "escaped" option
> is selected, then non-ascii character are replaced one byte at a
> time by the corresponding sequence &#xNN;

I would expect "raw" writes raw 8bit chars or UTF-8 chars, without any 
textual conversion to &#

Thus it is easy to "recode", "cstocs" etc to change the encoding and freely 
edit the text.

Then there should be two kinds of the "escape" option, one yours and one for 
the previous.

---
PM

Re: Problem: incompatible handling of svg files

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

On Monday 16 October 2006 02:49 pm, Ethan Merritt wrote:
> Petr Mikulik wrote>
> >
> > Without Hans-Bernhard's patch, SVG output is correct for both UTF-8
> > and 8859-2. I propose to remove this patch (and don't do &#nnnn; et
> > all).
>
> That works for me, after some struggles to change the default font
> paths.  But I think we need to know more about what exactly was the
> problem that Hans-Bernhard's patch was originally trying to fix.

In order to facilitate testing of various combinations of character
escaping and svg viewers, I have posted two variants of the svg.trm
driver to SourceForge. (These are complete files, not patches).

Both add a new terminal option
	set term svg {raw|escaped}

Variant 1 treats all encodings the same: if the "escaped" option
is selected, then non-ascii character are replaced one byte at a
time by the corresponding sequence &#xNN;

Variant 2 behaves exactly the same if an explicit encoding is set.
However, if no encoding is set then it is assumed to be UTF-8.
In this case non-ascii sequences are re-encoded by conversion from
UTF-8 to Unicode code points, rather than byte-by-byte.

Yes, we should probably have a specific S_ENC_UTF8 that can be
selected by "set encoding utf8".  But we can deal with that as a
separate issue if it turns out that we need the UTF-8 specific
code.

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

Re: Problem: incompatible handling of svg files

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

>> I've just tried after your latest patch, it works with UTF-8 and 'set
>> enco default', but not for latin2. Try this:
>>
>> Write b.gp in UTF-8:
>>
>> set encoding iso_8859_2
>> set term svg
>> set out 'b.svg'
>> set title "P=F8=EDli=B9 =BElu=BBou=E8k=FD k=F9=F2 =FAp=ECl =EF=E1belsk=
=E9 =F3dy."
>> set xlabel "P=F8=EDli=B9 =BElu=BBou=E8k=FD k=F9=F2 =FAp=ECl =EF=E1belsk=
=E9 =F3dy."
>> set ylabel "P=F8=EDli=B9 =BElu=BBou=E8k=FD k=F9=F2 =FAp=ECl =EF=E1belsk=
=E9 =F3dy."
>> plot x
>>
>> recode utf8..latin2 b.gp
>> gnuplot b.gp
>>
>>
>> =3D> the file is rendered incorrectly; the text appears as:
>>
>> <text>P&#xf8;&#xed;li&#xb9; &#xbe;lu&#xbb;ou&#xe8;k&#xfd;
>> k&#xf9;&#xf2; &#xfa;p&#xec;l &#xef;&#xe1;belsk&#xe9; &#xf3;dy.</text>
>
> But that is what it was doing already, *before* my utf-8 patch.

Thus, it looks to me a "feature" of svg -- the following

 =09<?xml version=3D"1.0" encoding=3D"iso-8859-2"  standalone=3D"no"?>
 =09...
 =09<text>--=F8-- --&#xf8;--</text>

does not print =F8 twice even though F8 is its code in iso-8859-2. Cannot i=
t=20
be that &#nnnn; are always interpreted as UTF-8 chars, whatever header says=
?

In that case, in non-"set encoding default", gnuplot cannot do=20
transformation of 8bit chars into hex string, as the string will get all=20
wrong! (All =3D=3D without iso latin 1, which is a subset of utf-8, by desi=
gn.)

> The change to write non-ascii characters in the form &#xbb;
> was due to this patch:
>
> 2006-10-03  Hans-Bernhard Broeker  <br...@ph...>
>
>        * term/svg.trm: Change sprintf() and fprintf() to strcpy and
>        fputs, all over the place.
>        (SVG_put_text): Fix handling of XML reserved characters in
>        non-enhanced text output.
>
> That patch broke things for me, also, which is what started me
> on the path to reworking the code so that at least it works in
> my utf-8 environment.
>
> So I think we have a problem here.
> Apparently Hans-Bernhard's svg viewer does not like the inline
> non-ascii characters, whereas your viewers and mine require them
> in order to process the encoding correctly.

Yes, then it is a bug of that particular svg viewer.

Without Hans-Bernhard's patch, SVG output is correct for both UTF-8 and=20
8859-2. I propose to remove this patch (and don't do &#nnnn; et all).

---
PM

Problem: incompatible handling of svg files

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

On Sunday 15 October 2006 11:10 pm, Petr Mikulik wrote:
>
> I've just tried after your latest patch, it works with UTF-8 and 'set
> enco default', but not for latin2. Try this:
>
> Write b.gp in UTF-8:
>
> set encoding iso_8859_2
> set term svg
> set out 'b.svg'
> set title "P=C5=99=C3=ADli=C5=A1 =C5=BElu=C5=A5ou=C4=8Dk=C3=BD k=C5=AF=C5=
=88 =C3=BAp=C4=9Bl =C4=8F=C3=A1belsk=C3=A9 =C3=B3dy."
> set xlabel "P=C5=99=C3=ADli=C5=A1 =C5=BElu=C5=A5ou=C4=8Dk=C3=BD k=C5=AF=
=C5=88 =C3=BAp=C4=9Bl =C4=8F=C3=A1belsk=C3=A9 =C3=B3dy."
> set ylabel "P=C5=99=C3=ADli=C5=A1 =C5=BElu=C5=A5ou=C4=8Dk=C3=BD k=C5=AF=
=C5=88 =C3=BAp=C4=9Bl =C4=8F=C3=A1belsk=C3=A9 =C3=B3dy."
> plot x
>
> recode utf8..latin2 b.gp
> gnuplot b.gp
>
>
> =3D> the file is rendered incorrectly; the text appears as:
>
> <text>P&#xf8;&#xed;li&#xb9; &#xbe;lu&#xbb;ou&#xe8;k&#xfd;
> k&#xf9;&#xf2; &#xfa;p&#xec;l &#xef;&#xe1;belsk&#xe9; &#xf3;dy.</text>

But that is what it was doing already, *before* my utf-8 patch.

The change to write non-ascii characters in the form &#xbb;
was due to this patch:

2006-10-03  Hans-Bernhard Broeker  <br...@ph...>

        * term/svg.trm: Change sprintf() and fprintf() to strcpy and
        fputs, all over the place.
        (SVG_put_text): Fix handling of XML reserved characters in
        non-enhanced text output.

That patch broke things for me, also, which is what started me
on the path to reworking the code so that at least it works in
my utf-8 environment.

So I think we have a problem here.
Apparently Hans-Bernhard's svg viewer does not like the inline
non-ascii characters, whereas your viewers and mine require them
in order to process the encoding correctly.

The minimal reversion to pre-Oct 3 behavior is

=2D-- gnuplot/term/svg.trm        2006-10-12 10:53:40.000000000 -0700
+++ gnuplot-cvs/term/svg.trm    2006-10-16 09:37:36.000000000 -0700
@@ -945,10 +945,12 @@
        fputs("&amp;", gpoutfile);
        break;
    default:
+#if (0)
        /* Some SVG viewers really dislike non-ascii characters */
        if (symb < ' ' || symb > '~')
            fprintf(gpoutfile, "&#x%2.2x;", symb);
        else
+#endif
            fputc(*str, gpoutfile);
        break;
    }

That only changes the non-enhanced mode output, however.
If you need to change the enhanced mode output also, then add

@@ -1222,12 +1224,14 @@
     /* Kludge for phantom box accounting */
     ENHsvg_charcount++;
=20
+#if (0)
     /* My SVG viewers really dislike non-ascii characters */
     if (symb < ' ' || symb > '~') {
        sprintf(enhanced_cur_text, "&#x%2.2x;", symb);
        enhanced_cur_text +=3D 6;
        return;
     }
+#endif
=20
     /* Escape SVG reserved characters. Are there any besides '<' and=20
'&' ? */
     switch (c) {




=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: Please test UTF-8 support in revised SVG driver

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

>> For "set encoding iso8859_2" and the text in that encoding, it gets
>> displayed wrong.
>
> OK. That's exactly the sort of feedback I needed.
> I can't test this easily because I don't have a 8859-2 locale installed.

I've just tried after your latest patch, it works with UTF-8 and 'set enco=
=20
default', but not for latin2. Try this:

Write b.gp in UTF-8:

set encoding iso_8859_2
set term svg
set out 'b.svg'
set title "P=F8=EDli=B9 =BElu=BBou=E8k=FD k=F9=F2 =FAp=ECl =EF=E1belsk=E9 =
=F3dy."
set xlabel "P=F8=EDli=B9 =BElu=BBou=E8k=FD k=F9=F2 =FAp=ECl =EF=E1belsk=E9 =
=F3dy."
set ylabel "P=F8=EDli=B9 =BElu=BBou=E8k=FD k=F9=F2 =FAp=ECl =EF=E1belsk=E9 =
=F3dy."
plot x

recode utf8..latin2 b.gp
gnuplot b.gp


=3D> the file is rendered incorrectly; the text appears as:

<text>P&#xf8;&#xed;li&#xb9; &#xbe;lu&#xbb;ou&#xe8;k&#xfd; k&#xf9;&#xf2;=20
&#xfa;p&#xec;l &#xef;&#xe1;belsk&#xe9; &#xf3;dy.</text>

---
PM

Re: Please test UTF-8 support in revised SVG driver

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

On Sunday 15 October 2006 01:09 pm, Petr Mikulik wrote:
> > This weekend I decided to sit down and try to understand how utf-8
> > encoded works.  Afterwards I modified the svg terminal driver
> > to re-encode utf-8 strings as escaped Unicode hex constants. This
> > makes it work properly on my machine using either firefox or
> > konqueror, whereas without re-encoding it worked only partially.
>=20
> I've tried it with a Czech text like
>  	P=C5=99=C3=ADli=C5=A1 =C5=BElu=C5=A5ou=C4=8Dk=C3=BD k=C5=AF=C5=88 =C3=
=BAp=C4=9Bl =C4=8F=C3=A1belsk=C3=A9 =C3=B3dy.
> It works with "set encoding default" and the text written in UTF-8.=20

Good. If you look in the *.svg output file, you will see that it now
starts with the line
<?xml version=3D"1.0" encoding=3D"utf-8"  standalone=3D"no"?>
The UTF-8 encoding part is working as intended in this case.

> For "set encoding iso8859_2" and the text in that encoding, it gets
> displayed wrong. =20

OK. That's exactly the sort of feedback I needed.
I can't test this easily because I don't have a 8859-2 locale installed.

> If I do so, and having Czech text in those encodings, the text appears
> correctly in both Firefox 1.5.0.7 and Konqueror 3.5.2.=20

I have now made the re-encoding dependent on the current setting of
gnuplot's "set encoding". It will re-encode into Unicode only for settings
"default" and "iso_8859_1".

Please give it another test.=20

> And, how is it supposed to work on Windows with cp1250 encoding?

Why is that special?

> Well, I wonder why it is not enough to have
>    <?xml version=3D"1.0" encoding=3D"utf-8"  standalone=3D"no"?>
> as the first line of the output file?=20

Two problems:

=2D Some older versions of svg.trm sort of worked, but there were bug repor=
ts
  about poor handling of characters with octal values >127, and we
  changed svg.trm to escape all of these byte-by-byte into the form
  &#xXX;  Since the individual bytes of a multi-byte UTF-8 sequence
  are not legal characters on their own, this comes out total garbage.

=2D Even if I revert to passing the bytes through without escaping, the
  viewers I have access to do not correctly handle multi-byte utf-8 sequenc=
es.
  I haven't figured out exactly what the limitations are, but mostly it
  doesn't come out right.  Perhaps they can handle 2-byte sequences, but
  not 3- and 4-byte sequences?  I don't know.

> Thus, I don't see any advantage of the reencoding.=20
> I prefer to keep the text as-written.

Well, up until now it has not worked for UTF-8.  Now it does.
Let's try and fix it so that the UTF-8 support doesn't break your
other encodings.

=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: Please test UTF-8 support in revised SVG driver

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

> This weekend I decided to sit down and try to understand how utf-8
> encoded works.  Afterwards I modified the svg terminal driver
> to re-encode utf-8 strings as escaped Unicode hex constants. This
> makes it work properly on my machine using either firefox or
> konqueror, whereas without re-encoding it worked only partially.

I've tried it with a Czech text like
 =09P=F8=EDli=B9 =BElu=BBou=E8k=FD k=F9=F2 =FAp=ECl =EF=E1belsk=E9 =F3dy.
It works with "set encoding default" and the text written in UTF-8. For "se=
t=20
encoding iso8859_2" and the text in that encoding, it gets displayed wrong.=
=20
So you reencoding is wrong. And, how is it supposed to work on Windows=20
with cp1250 encoding?

I think your patch should work only for the default encoding or "set=20
encoding utf8" (to be added), otherwise it should not do any &#xxxx;=20
changes.

Well, I wonder why it is not enough to have
   <?xml version=3D"1.0" encoding=3D"utf-8"  standalone=3D"no"?>
   <?xml version=3D"1.0" encoding=3D"iso-8859-2"  standalone=3D"no"?>
as the first line of the output file? Why it does not work for you and=20
UTF-8? If I do so, and having Czech text in those encodings, the text=20
appears correctly in both Firefox 1.5.0.7 and Konqueror 3.5.2.

Thus, I don't see any advantage of the reencoding. I prefer to keep the tex=
t=20
as-written.

If you need it, then I propose to force it by an option to "set term svg".

---
PM

Re: Please test UTF-8 support in revised SVG driver

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

On Sunday 15 October 2006 04:52 am, Hans-Bernhard Br=F6ker wrote:
> Ethan A Merritt wrote:
>=20
> > Known limitations:
> >   text centering in svg was not good to begin with, and if the
> >   text includes utf-8 characters the centering gets even worse.
>=20
> If so, that's a bug in the enhanced mode implementation.  Non-enhanced=20
> SVG_put_text passes this job to the only instance that can handle it:=20
> the SVG file itself, and its interpreter(s).

I agree. It's a failure of the enhanced mode implementation.
The current code is reduced to counting characters and approximating
their net width so that it can place them properly.  A better
implementation would somehow tell the svg interpreter to save/restore
a particular position so that we can return to it later.=20

The corresponding terminal entry points at ENHsvg_open() are marked
=46IXME, waiting for someone who knows svg better than I do.


=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: Please test UTF-8 support in revised SVG driver

[<br...@ph...>]

Ethan A Merritt wrote:

> Known limitations:
>   text centering in svg was not good to begin with, and if the
>   text includes utf-8 characters the centering gets even worse.

If so, that's a bug in the enhanced mode implementation.  Non-enhanced 
SVG_put_text passes this job to the only instance that can handle it: 
the SVG file itself, and its interpreter(s).

Please test UTF-8 support in revised SVG driver

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

Hi all,

This weekend I decided to sit down and try to understand how utf-8
encoded works.  Afterwards I modified the svg terminal driver
to re-encode utf-8 strings as escaped Unicode hex constants. This
makes it work properly on my machine using either firefox or
konqueror, whereas without re-encoding it worked only partially.

Please let me know if you find problems viewing the new svg output
in other svg viewers.

Known limitations:
  text centering in svg was not good to begin with, and if the
  text includes utf-8 characters the centering gets even worse.

  You need to select a utf-8 font, of course.  I tested with
	set term svg font "ArialUnicode MS"

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

Re: gnuplot 4.2 and aquaterm

[Daniel F. <boy...@gm...>]

Hello,

All sorted now thanks a lot folks.

I deleted both the fink and dawrinport installations of aquaterm and  
gnuplot. Re-installed the aquaterm from the Per's website. The built  
gnuplot 4.2 rc1 from sources. I also made a symbolic link from /usr/ 
local/lib/libaquaterm1.0.1.dylib to /usr/lib/libaquaterm.1.0.1.dylib  
to make double sure the linker would pick it up!

Thanks again,

Daniel.

On 13 Oct 2006, at 22:43, Per Persson wrote:

>
> On Oct 13, 2006, at 15:45, Daniel Farrell wrote:
>
>> Hi,
>>
>> Yes this has showed up on the config.log, it seems that it can't  
>> locate the, -laquaterm:
>> configure:6051: checking for aqtInit in -laquaterm
>> configure:6081: gcc -o conftest -g -O2   -I/usr/X11R6/include   
>> conftest.c -laquaterm -lobjc  >&5
>> /usr/bin/ld: can't locate file for: -laquaterm
>> ac_cv_lib_aquaterm_aqtInit=no
>>
>> Fink and Dawinports had an installation of aquaterm. I may have  
>> also using the installer from the aquaterm website. I have deleted  
>> the fink installation of aquaterm and gnuplot. However, the  
>> configure script cannot find -laquaterm, it's is in the  
>> Dawrinports installation directory, /opt/local/lib there may even  
>> be one where the aquaterm GUI installed puts on too.
>>
>> What do you think?
>
> Methinks you don't have AquaTerm.framework in /Library/Frameworks/
> Gnuplot's configure won't look in /sw (Fink) or /opt (DarwinPorts)  
> unless you explicitly tell it to.
> Get an AquaTerm installer from http://aquaterm.sourceforge.net and  
> (re)install it.
> That should fix it.
>
> /Per

Re: gnuplot 4.2 and aquaterm

[Per P. <per...@ma...>]

On Oct 13, 2006, at 15:45, Daniel Farrell wrote:

> Hi,
>
> Yes this has showed up on the config.log, it seems that it can't  
> locate the, -laquaterm:
> configure:6051: checking for aqtInit in -laquaterm
> configure:6081: gcc -o conftest -g -O2   -I/usr/X11R6/include   
> conftest.c -laquaterm -lobjc  >&5
> /usr/bin/ld: can't locate file for: -laquaterm
> ac_cv_lib_aquaterm_aqtInit=no
>
> Fink and Dawinports had an installation of aquaterm. I may have  
> also using the installer from the aquaterm website. I have deleted  
> the fink installation of aquaterm and gnuplot. However, the  
> configure script cannot find -laquaterm, it's is in the Dawrinports  
> installation directory, /opt/local/lib there may even be one where  
> the aquaterm GUI installed puts on too.
>
> What do you think?

Methinks you don't have AquaTerm.framework in /Library/Frameworks/
Gnuplot's configure won't look in /sw (Fink) or /opt (DarwinPorts)  
unless you explicitly tell it to.
Get an AquaTerm installer from http://aquaterm.sourceforge.net and  
(re)install it.
That should fix it.

/Per

Re: gnuplot 4.2 and aquaterm

[<br...@ph...>]

Daniel Farrell wrote:

> Yes this has showed up on the config.log, it seems that it can't  
> locate the, -laquaterm:
> configure:6051: checking for aqtInit in -laquaterm
> configure:6081: gcc -o conftest -g -O2   -I/usr/X11R6/include   
> conftest.c -laquaterm -lobjc  >&5
> /usr/bin/ld: can't locate file for: -laquaterm
> ac_cv_lib_aquaterm_aqtInit=no

That means that libaquaterm is not "installed" in the usable sense of 
the term.  For a library to be installed means that it's in some place 
where the linker automatically looks for libraries.  This can be 
arranged in various ways: you can extend the linker's search path, or 
you can install the library in one of the directories it already searches.

If your libaquaterm really has to remain elsewhere, re-read the 
INSTALL.gnu document or "configure --help" output to see how to teach 
configure to widen its search area.

Re: gnuplot 4.2 and aquaterm

[Daniel F. <boy...@gm...>]

Hi,

Yes this has showed up on the config.log, it seems that it can't  
locate the, -laquaterm:
configure:6051: checking for aqtInit in -laquaterm
configure:6081: gcc -o conftest -g -O2   -I/usr/X11R6/include   
conftest.c -laquaterm -lobjc  >&5
/usr/bin/ld: can't locate file for: -laquaterm
ac_cv_lib_aquaterm_aqtInit=no

Fink and Dawinports had an installation of aquaterm. I may have also  
using the installer from the aquaterm website. I have deleted the  
fink installation of aquaterm and gnuplot. However, the configure  
script cannot find -laquaterm, it's is in the Dawrinports  
installation directory, /opt/local/lib there may even be one where  
the aquaterm GUI installed puts on too.

What do you think?

Dan.

On 13 Oct 2006, at 08:34, Per Persson wrote:

>
>
>>
>> Message: 6
>> Date: Thu, 12 Oct 2006 18:40:48 +0100
>> From: Daniel Farrell <boy...@gm...>
>> Subject: Re: gnuplot 4.2 and aquaterm
>> To: Joe Koski <jko...@co...>
>> Cc: gnuplot-beta <gnu...@li...>
>> Message-ID: <5EE...@gm...>
>> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
>>
>> Hi Joe,
>>
>> Thanks for that, this seems quite strange but probably means I'm
>> doing something wrong! I just replaced the old version with the new
>> developer version (4.2 rc1) in /usr/local/bin and left my system
>> configuration the same too. gnuplot 4.2 rc1 gives out the following
>> when started:
>>
>> set term aqua
>>           ^
>> ".gnuplot", line 1: unknown or ambiguous terminal type; type just
>> 'set terminal' for a list
>>
>> Pretty clear then that my version at least don't know what aqua term
>> is! Also, in the 'help set term' documentation aqua is not listed as
>> an option.
>>
>> I pulled it from cvs, the actually version of is:
>> $Revision: 1.16 $, dated $Date: 2006/09/10 10:43:50 $.
>>
>> I'm running MacOS 10.4.8 with XCode 2.4 on a 1.5Ghz G4 PPC.
>
> For some reason AquaTerm is not picked up by the configure script.  
> Check the output from configure or look through config.log.
> Could you also check the version of AquaTerm and its install location?
> Do you have multiple copies of AquaTerm installed (e.g. from Fink  
> or DarwinPorts/MacPorts)?
>
> /Per

Re: gnuplot 4.2 and aquaterm

[Per P. <per...@ma...>]

>
> Message: 6
> Date: Thu, 12 Oct 2006 18:40:48 +0100
> From: Daniel Farrell <boy...@gm...>
> Subject: Re: gnuplot 4.2 and aquaterm
> To: Joe Koski <jko...@co...>
> Cc: gnuplot-beta <gnu...@li...>
> Message-ID: <5EE...@gm...>
> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
>
> Hi Joe,
>
> Thanks for that, this seems quite strange but probably means I'm
> doing something wrong! I just replaced the old version with the new
> developer version (4.2 rc1) in /usr/local/bin and left my system
> configuration the same too. gnuplot 4.2 rc1 gives out the following
> when started:
>
> set term aqua
>           ^
> ".gnuplot", line 1: unknown or ambiguous terminal type; type just
> 'set terminal' for a list
>
> Pretty clear then that my version at least don't know what aqua term
> is! Also, in the 'help set term' documentation aqua is not listed as
> an option.
>
> I pulled it from cvs, the actually version of is:
> $Revision: 1.16 $, dated $Date: 2006/09/10 10:43:50 $.
>
> I'm running MacOS 10.4.8 with XCode 2.4 on a 1.5Ghz G4 PPC.

For some reason AquaTerm is not picked up by the configure script.  
Check the output from configure or look through config.log.
Could you also check the version of AquaTerm and its install location?
Do you have multiple copies of AquaTerm installed (e.g. from Fink or  
DarwinPorts/MacPorts)?

/Per

Re: [ gnuplot-Bugs-1575425 ] "with image" ignores gamma for postscript output (fwd)

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

>> if (sm_palette.colorMode == SMPAL_COLOR_MODE_GRAY)
>>     fprintf(gppsfile, "%s{1.0 %g div exp} settransfer\n", space, sm_palette.gamma);

I've changed it to
    {pm3dGamma exp} settransfer
and applied the patch.

> "settransfer" is Level 2 PostScript, so your patch needs to be check the
> "level1" flag and/or check for support dynamically.

It's OK, the whole image section is within not(Level1).

---
PM

Re: SVG terminal driver

[<br...@ph...>]

Ethan Merritt wrote:

> On the other hand, the additional special-char tests in the
> 3 Oct patch were not necessary for my two test svg-viewers.
> So I conclude that they were intended to fix a problem with
> a different set of viewers.  Please re-test the current
> version to make sure I haven't broken it for you at the same
> time I was fixing it for me.

FWIW: the problem that triggered my (admittedly somewhat excessive) 
action on October 3rd is still fixed.

> Assuming it works for you also, should we copy the cvs
> version over to the 4.2 branch for inclusion in -rc2?

Yes.  The 4.2 branch should kept current on all simple bugfixes for the 
time being.  Only dangerous patches and new features have to be kept off it.

SVG terminal driver

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

I had to re-work the logic for handling special characters
in SVG_put_text in order to make it work again on my machines.
It was suffering from bug #1575007 and also from a 3 Oct 2006
patch that changed the non-enhanced text code path.

I put the revised version in cvs, but not yet in the
4.2-rc branch.

With the revised logic, I am able to build the entire
all.dem test set as SVG web pages and have not noticed any
errors in the character string handling for 'normal'
character encodings.

On the other hand, the additional special-char tests in the
3 Oct patch were not necessary for my two test svg-viewers.
So I conclude that they were intended to fix a problem with
a different set of viewers.  Please re-test the current
version to make sure I haven't broken it for you at the same
time I was fixing it for me.

Assuming it works for you also, should we copy the cvs
version over to the 4.2 branch for inclusion in -rc2?

[ This is a bigger change than most of the -rc1 bug fixes,
 but I don't think the version of svg.trm that went into
 -rc1 was heavily tested anyhow, so it's not like we have 
 diverged from something known to be solid. ]

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

Re: gnuplot 4.2 and aquaterm

[<br...@ph...>]

Daniel Farrell wrote:

> I have recently need to apply a patch to gnuplot to add some  
> functionality. I applied it to the developer version of gnuplot  
> (4.2). However, it seem that the aqua terminal is not an option for  
> this version. 

It's an option for this version alright --- just not for your 
compilation of it.  Something must have gone wrong at "configure" time. 
    Probably you don't have all the libraries and headers installed to 
compile programs using aqua; or they're in the wrong place.

Re: gnuplot 4.2 and aquaterm

[Joe K. <jko...@co...>]

on 10/12/06 11:40 AM, Daniel Farrell at boy...@gm... wrote:

> Hi Joe,
> 
> Thanks for that, this seems quite strange but probably means I'm
> doing something wrong! I just replaced the old version with the new
> developer version (4.2 rc1) in /usr/local/bin and left my system
> configuration the same too. gnuplot 4.2 rc1 gives out the following
> when started:
> 
> set term aqua
>           ^
> ".gnuplot", line 1: unknown or ambiguous terminal type; type just
> 'set terminal' for a list
> 
> Pretty clear then that my version at least don't know what aqua term
> is! Also, in the 'help set term' documentation aqua is not listed as
> an option.
> 
> I pulled it from cvs, the actually version of is:
> $Revision: 1.16 $, dated $Date: 2006/09/10 10:43:50 $.
> 
> I'm running MacOS 10.4.8 with XCode 2.4 on a 1.5Ghz G4 PPC.
> 
> Regards,
> 
> Daniel.
> 
Daniel,

Your config.log should tell you where the configuration script had problems
with aqua. It's probably a misplaced header file or some such.

Joe

> 
> On 12 Oct 2006, at 17:06, Joe Koski wrote:
> 
>> on 10/12/06 9:01 AM, Daniel Farrell at boy...@gm... wrote:
>> 
>>> Hello,
>>> 
>>> I have recently need to apply a patch to gnuplot to add some
>>> functionality. I applied it to the developer version of gnuplot
>>> (4.2). However, it seem that the aqua terminal is not an option for
>>> this version. Do you have any advice? Should I apply the patch to the
>>> current release version instead? Or are there some compile options
>>> that I can turn on to make it available?
>>> 
>>> Regards,
>>> 
>>> Daniel.
>>> 
>> Daniel,
>> 
>> AquaTerm works with gnuplot-4.2.rc1 on my G5 Mac built with OS X
>> 10.4.8 and
>> Xcode-2.4 developer tools. I did nothing more than my old
>> configuration for
>> gnuplot-4.0 to build it. All my old gnuplot and octave routines work
>> properly with AquaTerm.
>> 
>> The only issue that I have with AquaTerm is that octave now passes
>> figure
>> numbers via the gnuplot command line, not with set term. This means
>> that all
>> figures are Figure 0 for octave/gnuplot/aqua, which can become
>> confusing
>> when several windows are open. The wxt terminal will have the same
>> issue.
>> 
>> Joe
>> 
>> 
>