5.2 rc2 tarball now available

classic Classic list List threaded Threaded
35 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

5.2 rc2 tarball now available

Gnuplot - Dev mailing list
One month of -rc1 turned up one serious bug, a couple of minor bugs that
were easily triggered, and a bunch of odd corner cases found by fuzz-testing
that could only be hit by invalid command syntax or strange input data.
Not too bad.

So here is -rc2

Release Notes date: 03-Jul-2017

CHANGES SINCE rc1
=================
* FIX: terminal initialization must complete before executing ~/.gnuplot
* FIX: incorrect clipping of polar border and raxis
* FIX: add sanity checks to detect and handle various types of bad input data
       or command syntax found by fuzz-testing
* FIX: windows terminal (various minor tweaks)


        Ethan

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 5.2 rc2 tarball now available

tmacchant
----- Original Message -----

> From: sfeam via gnuplot-beta
> To: [hidden email]
> Cc:
> Date: 2017/7/4, Tue 11:18
> Subject: 5.2 rc2 tarball now available
>
> One month of -rc1 turned up one serious bug, a couple of minor bugs that
> were easily triggered, and a bunch of odd corner cases found by fuzz-testing
> that could only be hit by invalid command syntax or strange input data.
> Not too bad.
>
> So here is -rc2
>
> Release Notes date: 03-Jul-2017
>
> CHANGES SINCE rc1
> =================
> * FIX: terminal initialization must complete before executing ~/.gnuplot
> * FIX: incorrect clipping of polar border and raxis
> * FIX: add sanity checks to detect and handle various types of bad input data
>        or command syntax found by fuzz-testing
> * FIX: windows terminal (various minor tweaks)
>
>
>     Ethan

I have built windows binary packages for -rc2 and uploeded SourceForge site.

Tatsuro


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 5.2 rc2 tarball now available

Petr Mikulik
  Hello,

I have troubles compiling rc2 on Linux (OpenSUSE 42.2, and some Ubuntu) -
linking fails.

It is this problem:
     https://sourceforge.net/p/gnuplot/support-requests/196/

The workaround
     configure --with-X11
described above does not help, while
     TERMLIBS="-lX11" ./configure
let me gnuplot compile.

Can this be fixed?

***

Further, I can see that
  set term qt; test
does not pass the test of character width (testing rectangle is too narrow),
while x11 and wxt pass well.

***

Those two dummy terminals show 90123456789 instead of 0123...90123...9 in the
character width test:
  set term dumb; test
  set term caca; test

***

Is caca still experimental?
It's just fun, but it's nice, mouseable and it seems to work, so I propose to
have it not experimental.

***

Greetings,
   Petr

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 5.2 rc2 tarball now available

Gnuplot - Dev mailing list
On Tuesday, 04 July 2017 17:26:11 Petr Mikulik wrote:

>   Hello,
>
> I have troubles compiling rc2 on Linux (OpenSUSE 42.2, and some Ubuntu) -
> linking fails.
>
> It is this problem:
>      https://sourceforge.net/p/gnuplot/support-requests/196/
>
> The workaround
>      configure --with-X11
> described above does not help, while
>      TERMLIBS="-lX11" ./configure
> let me gnuplot compile.
>
> Can this be fixed?

   No.  It is a bug in the configuration files distributed for libwxgtk.

> ***
>
> Further, I can see that
>   set term qt; test
> does not pass the test of character width (testing rectangle is too narrow),
> while x11 and wxt pass well.

  I don't see this problem here.
  Is it maybe an issue with the font?

> ***
>
> Those two dummy terminals show 90123456789 instead of 0123...90123...9 in the
> character width test:
>   set term dumb; test
>   set term caca; test

  The horizontal arrow is being drawn on top of test string 01234567890123456789
  Probably the arrows should be smaller, or drawn in back of the text

> ***
>
> Is caca still experimental?
> It's just fun, but it's nice, mouseable and it seems to work, so I propose to
> have it not experimental.

  Good point.
  Also I have just noticed that the caca terminal documentation
  is not always included in user manual.

>
> ***
>
> Greetings,
>    Petr


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 5.2 rc2 tarball now available

Gnuplot - Dev mailing list
On Tuesday, 04 July 2017 12:01:33 Dmitri A. Sergatskov wrote:

> On Tue, Jul 4, 2017 at 10:59 AM, sfeam via gnuplot-beta <
> [hidden email]> wrote:
>
> >
> > > Further, I can see that
> > >       set term qt; test
> > > does not pass the test of character width (testing rectangle is too
> > narrow),
> > > while x11 and wxt pass well.
> >
> >   I don't see this problem here.
> >   Is it maybe an issue with the font?
> >
> >
>
> ​I can reproduce it and it is definitely font/font size dependent but ​
> ​mostly wrong than right​.
>
> Attached are screenshots with fonts set to "DroidSans,9" (bad)
> and "DroidSans,14" (OK).
Huh.  It works fine for me.  Mageia 5/Qt5

screenshot attached from
   set term qt font "DroidSans,9"; test

I am still guessing it is an error in font handling, external to gnuplot.

        Ethan


> This is on Fedora 26/Qt5
>
> Dmitri.
> --

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

qt+DroidSans9.png (84K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 5.2 rc2 tarball now available

Gnuplot - Dev mailing list
In reply to this post by Gnuplot - Dev mailing list
On Tuesday, 04 July 2017 08:59:56 sfeam via gnuplot-beta wrote:

> On Tuesday, 04 July 2017 17:26:11 Petr Mikulik wrote:
> > ***
> >
> > Is caca still experimental?
> > It's just fun, but it's nice, mouseable and it seems to work, so I propose to
> > have it not experimental.
>
>   Good point.
>   Also I have just noticed that the caca terminal documentation
>   is not always included in user manual.
>

Hmm.  Maybe it still needs the EXPERIMENTAL warning.

I have not tried the caca terminal for a while, but here is what I see
when testing -rc2:

driver type raw: Segfaults immediately
                                (divide-by-zero because height and width are 0)
driver type ncurses: Many garbage characters in output stream
                                (incorrect handling of TERM setting?)
driver type x11: Font problems, many characters appear as
                                an empty box.  Usable but could be better.

I have lib64caca0-0.99-0.beta18.10
Do you have a more recent version?

In any case I will make sure the documentation is included in the
user manual for 5.2

        Ethan

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 5.2 rc2 tarball now available

Dmitri A. Sergatskov
In reply to this post by Gnuplot - Dev mailing list


On Tue, Jul 4, 2017 at 12:46 PM, sfeam <[hidden email]> wrote:
On Tuesday, 04 July 2017 12:01:33 Dmitri A. Sergatskov wrote:
> On Tue, Jul 4, 2017 at 10:59 AM, sfeam via gnuplot-beta <
> [hidden email]> wrote:
>
> >
> > > Further, I can see that
> > >       set term qt; test
> > > does not pass the test of character width (testing rectangle is too
> > narrow),
> > > while x11 and wxt pass well.
> >
> >   I don't see this problem here.
> >   Is it maybe an issue with the font?
> >
> >
>
> ​I can reproduce it and it is definitely font/font size dependent but ​
> ​mostly wrong than right​.
>
> Attached are screenshots with fonts set to "DroidSans,9" (bad)
> and "DroidSans,14" (OK).

Huh.  It works fine for me.  Mageia 5/Qt5

screenshot attached from
   set term qt font "DroidSans,9"; test

I am still guessing it is an error in font handling, external to gnuplot.

        Ethan


> This is on Fedora 26/Qt5
>
> Dmitri.
> --

​Perhaps. The kerning looks different (see e.g. the spacing between "t" and "e" in "test")

I will try on plasma desktop.

Dmitri​.
--




------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 5.2 rc2 tarball now available

Gnuplot - Dev mailing list
On Tuesday, 04 July 2017 12:58:08 Dmitri A. Sergatskov wrote:

> On Tue, Jul 4, 2017 at 12:46 PM, sfeam <[hidden email]> wrote:
>
> > On Tuesday, 04 July 2017 12:01:33 Dmitri A. Sergatskov wrote:
> > > On Tue, Jul 4, 2017 at 10:59 AM, sfeam via gnuplot-beta <
> > > [hidden email]> wrote:
> > >
> > > >
> > > > > Further, I can see that
> > > > >       set term qt; test
> > > > > does not pass the test of character width (testing rectangle is too
> > > > narrow),
> > > > > while x11 and wxt pass well.
> > > >
> > > >   I don't see this problem here.
> > > >   Is it maybe an issue with the font?
> > > >
> > > >
> > >
> > > ​I can reproduce it and it is definitely font/font size dependent but ​
> > > ​mostly wrong than right​.
> > >
> > > Attached are screenshots with fonts set to "DroidSans,9" (bad)
> > > and "DroidSans,14" (OK).
> >
> > Huh.  It works fine for me.  Mageia 5/Qt5
> >
> > screenshot attached from
> >    set term qt font "DroidSans,9"; test
> >
> > I am still guessing it is an error in font handling, external to gnuplot.
> >
> >         Ethan
> >
> >
> > > This is on Fedora 26/Qt5
> > >
> > > Dmitri.
> > > --
> >
>
> ​Perhaps. The kerning looks different (see e.g. the spacing between "t" and
> "e" in "test")
>
> I will try on plasma desktop.

I have the Droid fonts courtesy of TexLive.  They provide them as *.ttf and as
*.afm  + *.pfb

I specifically tested the ttf variant.  Can you check if you are using an Adobe
variant instead?   Or for that matter a TeX-processed *.vf or *.tfm version?
The pre-processed versions in particular would be likely to scale badly.

        Ethan




------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 5.2 rc2 tarball now available

Dmitri A. Sergatskov
On Tue, Jul 4, 2017 at 1:12 PM, sfeam <[hidden email]> wrote:
On Tuesday, 04 July 2017 12:58:08 Dmitri A. Sergatskov wrote:
> On Tue, Jul 4, 2017 at 12:46 PM, sfeam <[hidden email]> wrote:
>
> > On Tuesday, 04 July 2017 12:01:33 Dmitri A. Sergatskov wrote:
> > > On Tue, Jul 4, 2017 at 10:59 AM, sfeam via gnuplot-beta <
> > > [hidden email]> wrote:
> > >
> > > >
> > > > > Further, I can see that
> > > > >       set term qt; test
> > > > > does not pass the test of character width (testing rectangle is too
> > > > narrow),
> > > > > while x11 and wxt pass well.
> > > >
> > > >   I don't see this problem here.
> > > >   Is it maybe an issue with the font?
> > > >
> > > >
> > >
> > > ​I can reproduce it and it is definitely font/font size dependent but ​
> > > ​mostly wrong than right​.
> > >
> > > Attached are screenshots with fonts set to "DroidSans,9" (bad)
> > > and "DroidSans,14" (OK).
> >
> > Huh.  It works fine for me.  Mageia 5/Qt5
> >
> > screenshot attached from
> >    set term qt font "DroidSans,9"; test
> >
> > I am still guessing it is an error in font handling, external to gnuplot.
> >
> >         Ethan
> >
> >
> > > This is on Fedora 26/Qt5
> > >
> > > Dmitri.
> > > --
> >
>
> ​Perhaps. The kerning looks different (see e.g. the spacing between "t" and
> "e" in "test")
>
> I will try on plasma desktop.

I have the Droid fonts courtesy of TexLive.  They provide them as *.ttf and as
*.afm  + *.pfb

I specifically tested the ttf variant.  Can you check if you are using an Adobe
variant instead?   Or for that matter a TeX-processed *.vf or *.tfm version?
The pre-processed versions in particular would be likely to scale badly.


​I used Google's Droid fonts.
I have tried many fonts, and all of them have this problem. if you play
with the size, you can find a range where it is almost OK, but usually it is not.
Here is with dejavu sans mono 9 (this is actually the best fit I could get --
it gets worse for either smaller or bigger sizes).
​(This is still on Gnome desktop).​

 
 
        Ethan


 


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

dejavusansmono9.png (97K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 5.2 rc2 tarball now available

Gnuplot - Dev mailing list
On Tuesday, 04 July 2017 13:33:50 Dmitri A. Sergatskov wrote:

> On Tue, Jul 4, 2017 at 1:12 PM, sfeam <[hidden email]> wrote:
>
> > On Tuesday, 04 July 2017 12:58:08 Dmitri A. Sergatskov wrote:
> > > On Tue, Jul 4, 2017 at 12:46 PM, sfeam <[hidden email]>
> > wrote:
> > >
> > > > On Tuesday, 04 July 2017 12:01:33 Dmitri A. Sergatskov wrote:
> > > > > On Tue, Jul 4, 2017 at 10:59 AM, sfeam via gnuplot-beta <
> > > > > [hidden email]> wrote:
> > > > >
> > > > > >
> > > > > > > Further, I can see that
> > > > > > >       set term qt; test
> > > > > > > does not pass the test of character width (testing rectangle is
> > too
> > > > > > narrow),
> > > > > > > while x11 and wxt pass well.
> > > > > >
> > > > > >   I don't see this problem here.
> > > > > >   Is it maybe an issue with the font?
> > > > > >
> > > > > >
> > > > >
> > > > > ​I can reproduce it and it is definitely font/font size dependent
> > but ​
> > > > > ​mostly wrong than right​.
> > > > >
> > > > > Attached are screenshots with fonts set to "DroidSans,9" (bad)
> > > > > and "DroidSans,14" (OK).
> > > >
> > > > Huh.  It works fine for me.  Mageia 5/Qt5
> > > >
> > > > screenshot attached from
> > > >    set term qt font "DroidSans,9"; test
> > > >
> > > > I am still guessing it is an error in font handling, external to
> > gnuplot.
> > > >
> > > >         Ethan
> > > >
> > > >
> > > > > This is on Fedora 26/Qt5
> > > > >
> > > > > Dmitri.
> > > > > --
> > > >
> > >
> > > ​Perhaps. The kerning looks different (see e.g. the spacing between "t"
> > and
> > > "e" in "test")
> > >
> > > I will try on plasma desktop.
> >
> > I have the Droid fonts courtesy of TexLive.  They provide them as *.ttf
> > and as
> > *.afm  + *.pfb
> >
> > I specifically tested the ttf variant.  Can you check if you are using an
> > Adobe
> > variant instead?   Or for that matter a TeX-processed *.vf or *.tfm
> > version?
> > The pre-processed versions in particular would be likely to scale badly.
> >
> >
> ​I used Google's Droid fonts.
> I have tried many fonts, and all of them have this problem. if you play
> with the size, you can find a range where it is almost OK, but usually it
> is not.
> Here is with dejavu sans mono 9 (this is actually the best fit I could get
> --
> it gets worse for either smaller or bigger sizes).
> ​(This is still on Gnome desktop).​

I believe you, but I have never seen this problem here with any "normal" font.
That is, I see it for weird stuff like
    set term qt font "Bernard MT Condensed"
or
    set term qt font "Felix Titling"
but those are the only 2 that were imperfect out of dozens that I just tested.

More to the point...  Is it only the "test" command that has a problem?
If so I don't think we really care that much.  If boxed text in general is
failing that would be a bigger issue.  


        Ethan


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 5.2 rc2 tarball now available

Daniel J Sebald
In reply to this post by Dmitri A. Sergatskov
On 07/04/2017 01:33 PM, Dmitri A. Sergatskov wrote:
> On Tue, Jul 4, 2017 at 1:12 PM, sfeam <[hidden email]
> <mailto:[hidden email]>> wrote:
[snip]
> Here is with dejavu sans mono 9 (this is actually the best fit I could
> get --
> it gets worse for either smaller or bigger sizes).
> ​(This is still on Gnome desktop).​

I notice in the example test plot that people have sent that there is an
extra space between the terminal name and the "terminal test".  How
about the change in the attached diff file to make the terminal name
italic-bold and 1.5 times larger to illustrate multiple font features?
That looks pretty good and highlights the terminal in question, plus it
tests whether the user has a bold/italic font.

Dan

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

gnuplot-terminal_title_in_test-djs2017jul04.diff (720 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 5.2 rc2 tarball now available

Dmitri A. Sergatskov
In reply to this post by Gnuplot - Dev mailing list
On Tue, Jul 4, 2017 at 2:05 PM, sfeam <[hidden email]> wrote:

More to the point...  Is it only the "test" command that has a problem?
If so I don't think we really care that much.  If boxed text in general is
failing that would be a bigger issue.


​Here is the output of a script;

​set label "1234567890" at 0,-0.4 boxed font "DejaVuSans, 5"
set label "1234567890" at 0,-0.2 boxed font "DejaVuSans, 7"
set label "1234567890" at 0,0 boxed font "DejaVuSans, 9"
set label "1234567890" at 0,0.2 boxed font "DejaVuSans, 12"
set label "1234567890" at 0,0.4 boxed font "DejaVuSans, 14"
set label "1234567890" at 0,0.6 boxed font "DejaVuSans, 18"
set label "1234567890" at 0,0.8 boxed font "DejaVuSans, 24"
plot sin(x)

One can see that the problem is still there at very small (and perhaps very large) font sizes.
​The problem seems to be qt related. It looks fine reploted  to e.g. pngcairo.
 

        Ethan


​Dmitri.
--
 


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

t_fonts.png (82K) Download Attachment
t2.png (61K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 5.2 rc2 tarball now available

Daniel J Sebald
In reply to this post by Daniel J Sebald
Also, I'm wondering about the default terminal sizes:

wxt: 640x384
qt: 640x480
x11: 640x450

not that it matters much; it's just that the WXT terminal test output
looks vertically scrunched compared to Qt.  Other terminals such as PNG
use 640x480 default.

Dan


On 07/04/2017 02:17 PM, Daniel J Sebald wrote:

> On 07/04/2017 01:33 PM, Dmitri A. Sergatskov wrote:
>> On Tue, Jul 4, 2017 at 1:12 PM, sfeam <[hidden email]
>> <mailto:[hidden email]>> wrote:
> [snip]
>> Here is with dejavu sans mono 9 (this is actually the best fit I could
>> get --
>> it gets worse for either smaller or bigger sizes).
>> ​(This is still on Gnome desktop).​
>
> I notice in the example test plot that people have sent that there is an
> extra space between the terminal name and the "terminal test".  How
> about the change in the attached diff file to make the terminal name
> italic-bold and 1.5 times larger to illustrate multiple font features?
> That looks pretty good and highlights the terminal in question, plus it
> tests whether the user has a bold/italic font.
>
> Dan

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 5.2 rc2 tarball now available

Gnuplot - Dev mailing list
On Tuesday, 04 July 2017 14:31:20 Daniel J Sebald wrote:
> Also, I'm wondering about the default terminal sizes:
>
> wxt: 640x384
> qt: 640x480
> x11: 640x450
>
> not that it matters much; it's just that the WXT terminal test output
> looks vertically scrunched compared to Qt.  Other terminals such as PNG
> use 640x480 default.

Given that we're already at -rc2, let's limit any further changes to
actual bug fixes.

   thanks,

                Ethan



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 5.2 rc2 tarball now available

Daniel J Sebald
In reply to this post by Dmitri A. Sergatskov
On 07/04/2017 02:29 PM, Dmitri A. Sergatskov wrote:

> On Tue, Jul 4, 2017 at 2:05 PM, sfeam <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>
>     More to the point...  Is it only the "test" command that has a problem?
>     If so I don't think we really care that much.  If boxed text in
>     general is
>     failing that would be a bigger issue.
>
>
> ​Here is the output of a script;
>
> ​set label "1234567890" at 0,-0.4 boxed font "DejaVuSans, 5"
> set label "1234567890" at 0,-0.2 boxed font "DejaVuSans, 7"
> set label "1234567890" at 0,0 boxed font "DejaVuSans, 9"
> set label "1234567890" at 0,0.2 boxed font "DejaVuSans, 12"
> set label "1234567890" at 0,0.4 boxed font "DejaVuSans, 14"
> set label "1234567890" at 0,0.6 boxed font "DejaVuSans, 18"
> set label "1234567890" at 0,0.8 boxed font "DejaVuSans, 24"
> plot sin(x)
>
> One can see that the problem is still there at very small (and perhaps
> very large) font sizes.
> ​The problem seems to be qt related. It looks fine reploted  to e.g.
> pngcairo.

With a rudimentary browsing of the code, it doesn't seem to me that we
should expect the boxed text to be too accurate.  As for the test image,
it's

     /* test width and height of characters */
     (*t->linetype) (LT_SOLID);
     newpath();
     (*t->move) (x0 + xmax_t / 2 - t->h_char * 10, y0 + ymax_t / 2 +
t->v_char / 2);
     (*t->vector) (x0 + xmax_t / 2 + t->h_char * 10, y0 + ymax_t / 2 +
t->v_char / 2);
     (*t->vector) (x0 + xmax_t / 2 + t->h_char * 10, y0 + ymax_t / 2 -
t->v_char / 2);
     (*t->vector) (x0 + xmax_t / 2 - t->h_char * 10, y0 + ymax_t / 2 -
t->v_char / 2);
     (*t->vector) (x0 + xmax_t / 2 - t->h_char * 10, y0 + ymax_t / 2 +
t->v_char / 2);
     closepath();

which is only a rough estimate at the font-processed string width in
pixels, assuming a constant-width character.  The test image code should
be placing a box similar to the way in with text/label items are placing
a box.

But even in the case of labels with the "boxed" qualifier, I don't see
any mechanism for either feeding the string width from the terminal back
to gnuplot so that it can draw a box, or specifying to the terminal that
it should put a box around the text it is requesting.  That is, the
proper Qt mechanism is to use a QFontMetrics, in particular its
boundingRect() function which accepts a string as an input.  E.g.,

https://stackoverflow.com/questions/8633433/qt-get-the-pixel-length-of-a-string-in-a-qlabel

gnuplot Qt terminal does appear to attempt such a thing by:


#ifdef EAM_BOXED_TEXT
exit(25);
                if (m_inTextBox) {
                        m_currentTextBox |= rect;
                        m_currentBoxRotation = m_textAngle;
                        m_currentBoxOrigin = point;
                }
#endif

[snip]

                case TEXTBOX_OUTLINE:
                        /* Stroke bounding box */
                        outline = m_currentTextBox.adjusted(
                                 -m_textMargin.x(), -m_textMargin.y(),
                                  m_textMargin.x(), m_textMargin.y());
exit(26);
                        rectItem = addRect(outline, m_currentPen, Qt::NoBrush);
                        rectItem->setZValue(m_currentZ++);
                        rectItem->setTransformOriginPoint(m_currentBoxOrigin);
                        rectItem->setRotation(-m_currentBoxRotation);
                        m_currentGroup.append(rectItem);
                        m_inTextBox = false;
                        break;

However, with your test example, the above code doesn't get called.  So
there are certainly some issues for Qt terminal.

Ethan, how well developed is the boxed label/text?  Is this something
that needs more development and better left for a next release?  Or
should a proper Qt fix be a simple matter?

Dan

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 5.2 rc2 tarball now available

Petr Mikulik
In reply to this post by Gnuplot - Dev mailing list
>> I have troubles compiling rc2 on Linux (OpenSUSE 42.2, and some Ubuntu) -
>> linking fails.
>>
>> It is this problem:
>>      https://sourceforge.net/p/gnuplot/support-requests/196/
>>
>> The workaround
>>      configure --with-X11
>> described above does not help, while
>>      TERMLIBS="-lX11" ./configure
>> let me gnuplot compile.
>>
>> Can this be fixed?
>
>   No.  It is a bug in the configuration files distributed for libwxgtk.

Unfortunately it seems to be a wide-spread bug. It is quite embarassing that a
compile needs googling to fix it locally.

Cannot "./configure" take care of this? I.e. add the "-lX11" flag if
"something"?

---
Petr


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 5.2 rc2 tarball now available

Gnuplot - Dev mailing list
On Wednesday, 05 July 2017 01:08:35 Petr Mikulik wrote:

> >> I have troubles compiling rc2 on Linux (OpenSUSE 42.2, and some Ubuntu) -
> >> linking fails.
> >>
> >> It is this problem:
> >>      https://sourceforge.net/p/gnuplot/support-requests/196/
> >>
> >> The workaround
> >>      configure --with-X11
> >> described above does not help, while
> >>      TERMLIBS="-lX11" ./configure
> >> let me gnuplot compile.
> >>
> >> Can this be fixed?
> >
> >   No.  It is a bug in the configuration files distributed for libwxgtk.
>
> Unfortunately it seems to be a wide-spread bug. It is quite embarassing that a
> compile needs googling to fix it locally.
>
> Cannot "./configure" take care of this? I.e. add the "-lX11" flag if
> "something"?

That "something" is exactly the problem.   Only some versions of
wxWidgets need this, and only for some configurations.   The
wx-config tool is supposed to tell us what libraries are needed so
we can link them.  But it doesn't mention X11.    So how are we to know?

I'll go further and say it is a wxgtk bug that this should be visible
to the calling program at all.  The calling program doesn't use or
need to know about libX11.   If wxgtk wants to call into it, fine,
but why expose this to the calling program?

FWIW wxgtk 2.8 still works and doesn't have this problem.
It is only versions >= 2.9 that are broken.

        Ethan


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 5.2 rc2 tarball now available

Gnuplot - Dev mailing list
In reply to this post by Daniel J Sebald
On Tuesday, 04 July 2017 17:47:56 Daniel J Sebald wrote:

> On 07/04/2017 02:29 PM, Dmitri A. Sergatskov wrote:
> > On Tue, Jul 4, 2017 at 2:05 PM, sfeam <[hidden email]
> > <mailto:[hidden email]>> wrote:
> >
> >
> >     More to the point...  Is it only the "test" command that has a problem?
> >     If so I don't think we really care that much.  If boxed text in
> >     general is
> >     failing that would be a bigger issue.
> >
> >
> > ​Here is the output of a script;
> >
> > ​set label "1234567890" at 0,-0.4 boxed font "DejaVuSans, 5"
> > set label "1234567890" at 0,-0.2 boxed font "DejaVuSans, 7"
> > set label "1234567890" at 0,0 boxed font "DejaVuSans, 9"
> > set label "1234567890" at 0,0.2 boxed font "DejaVuSans, 12"
> > set label "1234567890" at 0,0.4 boxed font "DejaVuSans, 14"
> > set label "1234567890" at 0,0.6 boxed font "DejaVuSans, 18"
> > set label "1234567890" at 0,0.8 boxed font "DejaVuSans, 24"
> > plot sin(x)
> >
> > One can see that the problem is still there at very small (and perhaps
> > very large) font sizes.
> > ​The problem seems to be qt related. It looks fine reploted  to e.g.
> > pngcairo.
>
> With a rudimentary browsing of the code, it doesn't seem to me that we
> should expect the boxed text to be too accurate.  As for the test image,
> it's
>  [snip]
> which is only a rough estimate at the font-processed string width in
> pixels, assuming a constant-width character.  The test image code should
> be placing a box similar to the way in with text/label items are placing
> a box.

The code in "test" predates the boxed text option by many years.
It is, as you say, only a rough estimate.   It used to be the best we could do.
Now the boxed text option is a better alternative.

> But even in the case of labels with the "boxed" qualifier, I don't see
> any mechanism for either feeding the string width from the terminal back
> to gnuplot so that it can draw a box,

Correct.  The core code gets no feedback from the terminals.
For many terminals it is impossible even in theory (e.g. PostScript).

> or specifying to the terminal that
> it should put a box around the text it is requesting.  

Not correct.  The boxed text option works exactly by telling the terminal
it should put a box around the next block of text that is sent.
The terminal does this by itself with no additional help from any core routines.

[snip]

> Ethan, how well developed is the boxed label/text?  

There are additional options I would like to see added, but as to the
size of the bounding box  It should be perfect for the terminals that
support it at all.

> Is this something
> that needs more development and better left for a next release?  Or
> should a proper Qt fix be a simple matter?

For me the Qt output is perfect.  The bounding box of an object is a
fundamental property in Qt.   If Dmitri's Qt version is getting it wrong,
I'd say that is a serious bug in Qt.  I found one bug report against
Qt 5.5.1 and 5.6beta that might be relevant, but the text bounding boxes
are fine on my machines with Qt 5.4.2 and 5.6.2

        Ethan



> Dan


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 5.2 rc2 tarball now available

Daniel J Sebald
On 07/04/2017 06:45 PM, sfeam wrote:
> On Tuesday, 04 July 2017 17:47:56 Daniel J Sebald wrote:
[snip]

>> But even in the case of labels with the "boxed" qualifier, I don't see
>> any mechanism for either feeding the string width from the terminal back
>> to gnuplot so that it can draw a box,
>
> Correct.  The core code gets no feedback from the terminals.
> For many terminals it is impossible even in theory (e.g. PostScript).
>
>> or specifying to the terminal that
>> it should put a box around the text it is requesting.
>
> Not correct.  The boxed text option works exactly by telling the terminal
> it should put a box around the next block of text that is sent.
> The terminal does this by itself with no additional help from any core routines.

OK, if that is the case, I'll look at this a little bit and see if I can
find anything.

Dan

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 5.2 rc2 tarball now available

Daniel J Sebald
In reply to this post by Gnuplot - Dev mailing list
On 07/04/2017 06:23 PM, sfeam via gnuplot-beta wrote:

> On Wednesday, 05 July 2017 01:08:35 Petr Mikulik wrote:
>>>> I have troubles compiling rc2 on Linux (OpenSUSE 42.2, and some Ubuntu) -
>>>> linking fails.
>>>>
>>>> It is this problem:
>>>>      https://sourceforge.net/p/gnuplot/support-requests/196/
>>>>
>>>> The workaround
>>>>      configure --with-X11
>>>> described above does not help, while
>>>>      TERMLIBS="-lX11" ./configure
>>>> let me gnuplot compile.
>>>>
>>>> Can this be fixed?
>>>
>>>   No.  It is a bug in the configuration files distributed for libwxgtk.
>>
>> Unfortunately it seems to be a wide-spread bug. It is quite embarassing that a
>> compile needs googling to fix it locally.
>>
>> Cannot "./configure" take care of this? I.e. add the "-lX11" flag if
>> "something"?
>
> That "something" is exactly the problem.   Only some versions of
> wxWidgets need this, and only for some configurations.   The
> wx-config tool is supposed to tell us what libraries are needed so
> we can link them.  But it doesn't mention X11.    So how are we to know?

Actually, I think this is gnuplot's responsibility.  If I do

sebald@ ~ $ wx-config --libs
-L/usr/lib/x86_64-linux-gnu -pthread   -lwx_gtk2u_xrc-3.0
-lwx_gtk2u_html-3.0 -lwx_gtk2u_qa-3.0 -lwx_gtk2u_adv-3.0
-lwx_gtk2u_core-3.0 -lwx_baseu_xml-3.0 -lwx_baseu_net-3.0 -lwx_baseu-3.0

in that list is "pthread" which I believe is to inform the gcc/c++
compiler that posix threads are to be used in compiling and linking.  (I
think pthread is standard across compilers, but I'm not sure.)  In other
words, it's supposed to be the responsibility of the compiler to deal
with all the threads issues so long as wxWidgets follows posix.

In the fix for this bug

http://gnuplot.10905.n7.nabble.com/crash-when-using-wxt-in-Ubuntu-12-04-td17318.html

the following line was added:

/* Define a new application type, each gui should derive a class from
wxApp */
class wxtApp : public wxApp
{
public:
#if defined(WXT_MULTITHREADED) && defined(WX_NEEDS_XINITTHREADS) &&
defined(X11)
        /* Magic fix needed by wxgtk3.0 */
         wxtApp() : wxApp() { XInitThreads(); }
#endif

There's no way for wx-config to anticipate that this forced thread
initialization is going to appear in the code and that X11 library is
needed to satisfy that.

It could be that "-pthread" doesn't even use the X11 library but maybe
has it's own similar code.  Maybe XInitThreads() is a hunk of code that
just happens to solve the internal linux issue.

So, I would say the problem is that the fix for that bug report linked
above, i.e., forcing XInitThreads(), isn't the proper way of going about
things.  Let's find a proper way to fix that original bug.  For
reference, wxWidgets multithreading is discussed here:

http://docs.wxwidgets.org/trunk/overview_thread.html

Dan

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
12
Loading...