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

Re: 5.2 rc2 tarball now available

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

default terminal size

windows: depends on resolution on the current setting ?


Am I right?

Tatsuro



----- Original Message -----
> From: Daniel J Sebald <dan...@ie...>
> To: gnu...@li...
> Cc: 
> Date: 2017/7/5, Wed 04:31
> Subject: Re: 5.2 rc2 tarball now available
> 
> 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 <sf...@us...
>>>  <mailto:sf...@us...>> 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
> gnu...@li...
> Membership management via: 
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: 5.2 rc2 tarball now available

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

On 07/04/2017 07:53 PM, Daniel J Sebald wrote:
> 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.

I've posted an initial patch for Qt terminal alignment with this bug report:

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

There is a test plot screen capture there for you to look at.  I think 
it is going in the right direction, but needs some adjustment after 
discussion.

Dan

Re: 5.2 rc2 tarball now available

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

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

>> /* 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
>
> I'm not having any problems building/running if I just comment out this
> line.  Then again, from my wx-config test, I might be using GTK2 rather
> than GTK3, which might be the issue if "wxgtk3.0" is in the comment.
>
> This looks to have been a thread from 2013.  Maybe we should open a bug
> report and move the discussion there in hopes of finding someone for
> which that crash can be replicated when there is no XInitThreads().

Actually, I can replicate the problem, and I found the bug report. 
FWIW, I posted some comments and links here:

https://sourceforge.net/p/gnuplot/bugs/1401/?limit=25&page=1#aab6

I suspect a fix not involving manual XInitThreads() might be work beyond 
the current release.  (Is it that graphics/GUI action is taking place in 
the secondary thread when it isn't supposed to?)

Anyway, I think gnuplot configure is obligated to add -lX11, given the 
situation.

Dan

Re: 5.2 rc2 tarball now available

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

On 07/04/2017 08:07 PM, Daniel J Sebald wrote:
> 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

I'm not having any problems building/running if I just comment out this 
line.  Then again, from my wx-config test, I might be using GTK2 rather 
than GTK3, which might be the issue if "wxgtk3.0" is in the comment.

This looks to have been a thread from 2013.  Maybe we should open a bug 
report and move the discussion there in hopes of finding someone for 
which that crash can be replicated when there is no XInitThreads().

Dan

Re: 5.2 rc2 tarball now available

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

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

Re: 5.2 rc2 tarball now available

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

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

Re: 5.2 rc2 tarball now available

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

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 <sf...@us...
> > <mailto:sf...@us...>> 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

Re: 5.2 rc2 tarball now available

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

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

Re: 5.2 rc2 tarball now available

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

>> 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

Re: 5.2 rc2 tarball now available

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

On 07/04/2017 02:29 PM, Dmitri A. Sergatskov wrote:
> On Tue, Jul 4, 2017 at 2:05 PM, sfeam <sf...@us...
> <mailto:sf...@us...>> 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

Re: 5.2 rc2 tarball now available

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

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

Re: 5.2 rc2 tarball now available

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

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 <sf...@us...
>> <mailto:sf...@us...>> 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

Re: 5.2 rc2 tarball now available

[Dmitri A. S. <das...@gm...>]

On Tue, Jul 4, 2017 at 2:05 PM, sfeam <sf...@us...> 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.
-- 
​

Re: 5.2 rc2 tarball now available

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

On 07/04/2017 01:33 PM, Dmitri A. Sergatskov wrote:
> On Tue, Jul 4, 2017 at 1:12 PM, sfeam <sf...@us...
> <mailto:sf...@us...>> 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

Re: 5.2 rc2 tarball now available

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

On Tuesday, 04 July 2017 13:33:50 Dmitri A. Sergatskov wrote:
> On Tue, Jul 4, 2017 at 1:12 PM, sfeam <sf...@us...> wrote:
> 
> > On Tuesday, 04 July 2017 12:58:08 Dmitri A. Sergatskov wrote:
> > > On Tue, Jul 4, 2017 at 12:46 PM, sfeam <sf...@us...>
> > 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 <
> > > > > gnu...@li...> 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

Re: 5.2 rc2 tarball now available

[Dmitri A. S. <das...@gm...>]

On Tue, Jul 4, 2017 at 1:12 PM, sfeam <sf...@us...> wrote:

> On Tuesday, 04 July 2017 12:58:08 Dmitri A. Sergatskov wrote:
> > On Tue, Jul 4, 2017 at 12:46 PM, sfeam <sf...@us...>
> 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 <
> > > > gnu...@li...> 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
>
>

Re: 5.2 rc2 tarball now available

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

On Tuesday, 04 July 2017 12:58:08 Dmitri A. Sergatskov wrote:
> On Tue, Jul 4, 2017 at 12:46 PM, sfeam <sf...@us...> 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 <
> > > gnu...@li...> 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

Re: 5.2 rc2 tarball now available

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

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

Re: 5.2 rc2 tarball now available

[Dmitri A. S. <das...@gm...>]

On Tue, Jul 4, 2017 at 12:46 PM, sfeam <sf...@us...> 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 <
> > gnu...@li...> 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​.
--

Re: 5.2 rc2 tarball now available

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

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 <
> gnu...@li...> 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.
> --

Re: 5.2 rc2 tarball now available

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

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

Re: 5.2 rc2 tarball now available

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

 	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

Re: 5.2 rc2 tarball now available

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

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

> From: sfeam via gnuplot-beta 
> To: gnu...@li...
> 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

5.2 rc2 tarball now available

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

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

Re: Version number in the page "Ongoing development of gnuplot"

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

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

> From: Tatsuro MATSUOKA
> To: gnuplot-beta
> Cc: 
> Date: 2017/6/26, Mon 07:22
> Subject: Version number in the page "Ongoing development of gnuplot"
> 
> Version number in the page "Ongoing development of gnuplot"
> (http://www.gnuplot.info/development/index.html)
> is 5.0 alpha.
> It should be 5.3.
> 
> Tatsuro
> 
I have confirmed the fix.
Thanks!

Tatsuro