plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] Qt5 support, strange driver output

[Alan W. I. <Ala...@gm...>]

On 2018-12-25 17:54-0000 António Rodrigues Tomé wrote:

> Hi alan
> I do not pretend to understand everything you are asking for.
> But i think the changes I purpose completely solve the alpha problem in qt
> raster drivers.
> 1) I send you three files of the same plot with a yellow background with
> alpha=1, alpha=0.5, Alpha=0 (full background transparency).
> then I upload them to a template of the libreoffice impress just to
> ilustrate the effect.

Hi António:

Merry Christmas!

Those illustrations do look like your changes have solved the
transparency issue for at least the qt raster devices.  For example,
that checkerboard pattern is a traditional indication for
non-compositing desktops that you have had semi-transparency success,
indicating in better compositing environments (like your pdf example)
you will actually show the appropriate amount of semi-transparency.

In my own case, the ImageMagick "display" application for
semi-transparent images displays those with a checkerboard background
pattern to indicate a semi-transparent background was detected.  I am
not seeing that pattern currently for qt devices, but it appears from
your own results there is a good chance your change will fix that.

> 2) I think to commit these changes by git someone must give me permition in
> the plplot git repository.

For now, the "git commit" command should be used to commit your
changes to your own local topic branch.  Last I heard from you on that
issue it appeared all you needed to do was to execute "git add" first.
Was that a success?

If so, the current status should be you have two separate commits on
your local topic branch (one for your changes to allow use of qt
devices from a QT application, and the other the above transparency
changes), and the next question is how to communicate those git
commits to us for evaluation.

That is done with the git format-patch command as documented in README.developers.

Once we have your commits in that format, we will likely test them and
amend them (e.g., by adding additional "Tested by:" stanzas to the
your commit message).  And assuming those tests are a success we will
then push your amended commit to the master branch of our SF git
server with the normal git credit to you for your (amended) git
commits.

With regard to the question of pushing your commits directly yourself,
that privilege is reserved to core PLplot developers.  And you become
one of those by showing sustained interest using the above git
format-patch method of getting your development work (eventually)
pushed.

That said, we are always looking for future core PLplot developers and
especially someone with Qt expertise who has a sustained interest!  So
let's see how it goes with the above git format-patch approach.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Qt5 support, strange driver output

[António R. T. <ar...@gm...>]

Hi alan
I do not pretend to understand everything you are asking for.
But i think the changes I purpose completely solve the alpha problem in qt
raster drivers.
1) I send you three files of the same plot with a yellow background with
alpha=1, alpha=0.5, Alpha=0 (full background transparency).
then I upload them to a template of the libreoffice impress just to
ilustrate the effect.
2) I think to commit these changes by git someone must give me permition in
the plplot git repository. The other way is I to send to you the qt.cpp and
plqt.cpp changed files.

cheers,



On Mon, Dec 24, 2018 at 2:48 AM Alan W. Irwin <Ala...@gm...>
wrote:

> On 2018-12-23 10:14-0000 António Rodrigues Tomé wrote:
>
> > Just an update.
> > qt drivers do not behave well with alfa values.
> [...]
> > I'll try to upload this changes using git as I cannot find any other
> > problem with qt drivers at least for the use I make of them.
> > (well memqt does not work quite well but neither did memcairo)
>
> Make sure you split your changes into separate commits with appropriate
> commit message.
>
> Will the transparency change you refer to above give us a nice
> semi-transparent background (e.g.,
> with the -bg 000_0.1 command-line option to give a black background with
> alpha=0.1) with
> all qt devices?
>
> I see lots of cool semi-transparent desktop effects on my KDE desktop,
> where you can view one desktop through another.  I would also like to
> see similar effects possible with PLplot where you, for example, can
> view the command-line that produced a plot through the plot, if you use
> a semi-transparent background.
>
> > Have a nice Christmas
>
> You too.
>
> Alan
>
> __________________________
> Alan W. Irwin
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
>


-- 

António Rodrigues Tomé
Universidade da Beira Interior
Instituto D. Luís (lab associado)
email address:
ar...@gm...
ar...@ub...
http://www.researcherid.com/rid/A-5681-2013

Re: [Plplot-devel] Qt5 support, strange driver output

[Alan W. I. <Ala...@gm...>]

On 2018-12-23 10:14-0000 António Rodrigues Tomé wrote:

> Just an update.
> qt drivers do not behave well with alfa values.
[...]
> I'll try to upload this changes using git as I cannot find any other
> problem with qt drivers at least for the use I make of them.
> (well memqt does not work quite well but neither did memcairo)

Make sure you split your changes into separate commits with appropriate
commit message.

Will the transparency change you refer to above give us a nice semi-transparent background (e.g.,
with the -bg 000_0.1 command-line option to give a black background with alpha=0.1) with
all qt devices?

I see lots of cool semi-transparent desktop effects on my KDE desktop,
where you can view one desktop through another.  I would also like to
see similar effects possible with PLplot where you, for example, can
view the command-line that produced a plot through the plot, if you use
a semi-transparent background.

> Have a nice Christmas

You too.

Alan

__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Qt5 support, strange driver output

[António R. T. <ar...@gm...>]

Just an update.
qt drivers do not behave well with alfa values.
as the background was being filled with the instruction

QBrush brush( QColor( r, g, b, (int) ( alpha * 255 ) ) );
m_painterP->fillRect( 0, 0, width(), height(), brush );

however has explained in
http://curtis.humphreyonline.us/code/qt-code/making-a-qpixmap-transparent-wrong-way-right-way

things are esaily solved if in QtRasterDevice::QtRasterDevice( int
i_iWidth, int i_iHeight ) :
QImage::Format_RGB32  is replaced by QImage::Format_ARGB32

and  fill(Qt::transparent); is added in the constructor
QtRasterDevice::QtRasterDevice( int i_iWidth, int i_iHeight ) :
    QtPLDriver( i_iWidth, i_iHeight ),
    QImage( i_iWidth, i_iHeight, QImage::Format_ARGB32 )
{
    // Painter initialised in the constructor contrary
    // to buffered drivers, which paint only in doPlot().
    m_painterP = new QPainter( this );
    fill(Qt::transparent);

    QBrush b = m_painterP->brush();
    b.setStyle( Qt::SolidPattern );
    m_painterP->setBrush( b );
    m_painterP->setRenderHint( QPainter::Antialiasing, (bool) lines_aa );
}

I'll try to upload this changes using git as I cannot find any other
problem with qt drivers at least for the use I make of them.
(well memqt does not work quite well but neither did memcairo)

Have a nice Christmas




On Sat, Dec 22, 2018 at 10:16 PM António Rodrigues Tomé <ar...@gm...>
wrote:

> Hi Alan
> I think the small change I purpose will do the trick. In no way it will
> mess up with the normal functionality of the driver but  it will allow all
> qt drivers to be used inside a qt
> program. I've tested it.
> I Think Alban Rochel never considered necessary to use the drivers from a
> qt program he decided that from a qt program the normal way was to use the
> the qt widget  driver (not acceptable in my point of view).
> With the small change I made the qt-example is not affected and all the
> others drivers can be called from a qt program to produce image files.
>
> cheers,
>
>
>
> On Sat, Dec 22, 2018 at 9:30 PM Alan W. Irwin <Ala...@gm...>
> wrote:
>
>> On 2018-12-20 13:21-0800 Alan W. Irwin wrote:
>>
>> > On 2018-12-20 18:56-0000 António Rodrigues Tomé wrote:
>> >
>> >> Hi Alan
>> >> I do not completely understand the need of using a mutex in the qt
>> driver
>> >> however
>> >> without any change in the actual driver approach it is easy to allow
>> the
>> >> driver to work well within a qt app and also in any other c or c++
>> program
>> >> if in the file qt.cpp function  bool initQtApp( bool isGUI )
>> >> we add after the ++appCounter; line (line 90)
>> >> the instruction
>> >>    if(appCounter == 1 && qApp != NULL) ++appCounter;
>> >> this will prevent the call
>> >> delete qApp;
>> >> when one closes the driver within a qt application, that would crash
>> teh
>> >> application,  and it does  not conflict with the actual behavior of
>> the qt
>> >> driver it onnly takes account for the fact that there is a qApp that
>> was
>> >> not started by the driver.
>> >
>> > Hi António:
>> [...]
>> > So from the point of view of a non-expert for this code, I would
>> > suggest if you think the mutex is no longer needed because of your
>> > change, then go ahead an remove it to see whether that combined change
>> > passes all tests you care to make including ideally running the
>> > comprehensive test script as documented in
>> > doc/wiki_source/Testing_PLplot.
>>
>> With regard to the mutex, I have included what Alban initially said about
>> it way back when.
>>
>> From his comment my guess is the mutex is a necessity to keep the Qt
>> components of PLplot thread-safe because the PLplot core is not thread
>> safe (although fixing that bad state of affairs is on our long-term
>> agenda).
>> And subsequently there was a whole lot of plplot-devel traffic about
>> properly setting up that mutex with no question from anyone about its
>> necessity.
>>
>> Anyhow, forget my naive idea above that you might want to drop the mutex.
>>
>> Alan
>>
>> ---------- Forwarded message ----------
>> Date: Fri, 20 Mar 2009 17:00:49 +0000
>> From: Alban Rochel <a.r...@im...>
>> To: Alan W. Irwin <ir...@be...>
>> Subject: Qt driver update
>>
>> Alan,
>>
>> I've made a break from QSAS for an hour and I've made a couple of
>> improvements
>> to the Qt driver.
>>
>> - I've introduced a mutex to make some parts thread-safe (I haven't
>> checked if
>> all the driver was).
>> - Someone noticed that when 2 qtwidgets were running on 2 streams,
>> closing them
>> didn't close the driver properly. This should be fixed by now. When qApp
>> is
>> run, all the qtwidgets created before are tagged as being run, and so the
>> driver shouldn't try to run one qApp per widget.
>>
>> Cheers,
>>
>> Alban
>>
>> __________________________
>> Alan W. Irwin
>>
>> Programming affiliations with the FreeEOS equation-of-state
>> implementation for stellar interiors (freeeos.sf.net); the Time
>> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
>> software package (plplot.sf.net); the libLASi project
>> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
>> and the Linux Brochure Project (lbproject.sf.net).
>> __________________________
>>
>> Linux-powered Science
>> __________________________
>>
>
>
> --
>
> António Rodrigues Tomé
> Universidade da Beira Interior
> Instituto D. Luís (lab associado)
> email address:
> ar...@gm...
> ar...@ub...
> http://www.researcherid.com/rid/A-5681-2013
>
>

-- 

António Rodrigues Tomé
Universidade da Beira Interior
Instituto D. Luís (lab associado)
email address:
ar...@gm...
ar...@ub...
http://www.researcherid.com/rid/A-5681-2013

Re: [Plplot-devel] Qt5 support, strange driver output

[António R. T. <ar...@gm...>]

Hi Alan
I think the small change I purpose will do the trick. In no way it will
mess up with the normal functionality of the driver but  it will allow all
qt drivers to be used inside a qt
program. I've tested it.
I Think Alban Rochel never considered necessary to use the drivers from a
qt program he decided that from a qt program the normal way was to use the
the qt widget  driver (not acceptable in my point of view).
With the small change I made the qt-example is not affected and all the
others drivers can be called from a qt program to produce image files.

cheers,



On Sat, Dec 22, 2018 at 9:30 PM Alan W. Irwin <Ala...@gm...>
wrote:

> On 2018-12-20 13:21-0800 Alan W. Irwin wrote:
>
> > On 2018-12-20 18:56-0000 António Rodrigues Tomé wrote:
> >
> >> Hi Alan
> >> I do not completely understand the need of using a mutex in the qt
> driver
> >> however
> >> without any change in the actual driver approach it is easy to allow the
> >> driver to work well within a qt app and also in any other c or c++
> program
> >> if in the file qt.cpp function  bool initQtApp( bool isGUI )
> >> we add after the ++appCounter; line (line 90)
> >> the instruction
> >>    if(appCounter == 1 && qApp != NULL) ++appCounter;
> >> this will prevent the call
> >> delete qApp;
> >> when one closes the driver within a qt application, that would crash teh
> >> application,  and it does  not conflict with the actual behavior of the
> qt
> >> driver it onnly takes account for the fact that there is a qApp that was
> >> not started by the driver.
> >
> > Hi António:
> [...]
> > So from the point of view of a non-expert for this code, I would
> > suggest if you think the mutex is no longer needed because of your
> > change, then go ahead an remove it to see whether that combined change
> > passes all tests you care to make including ideally running the
> > comprehensive test script as documented in
> > doc/wiki_source/Testing_PLplot.
>
> With regard to the mutex, I have included what Alban initially said about
> it way back when.
>
> From his comment my guess is the mutex is a necessity to keep the Qt
> components of PLplot thread-safe because the PLplot core is not thread
> safe (although fixing that bad state of affairs is on our long-term
> agenda).
> And subsequently there was a whole lot of plplot-devel traffic about
> properly setting up that mutex with no question from anyone about its
> necessity.
>
> Anyhow, forget my naive idea above that you might want to drop the mutex.
>
> Alan
>
> ---------- Forwarded message ----------
> Date: Fri, 20 Mar 2009 17:00:49 +0000
> From: Alban Rochel <a.r...@im...>
> To: Alan W. Irwin <ir...@be...>
> Subject: Qt driver update
>
> Alan,
>
> I've made a break from QSAS for an hour and I've made a couple of
> improvements
> to the Qt driver.
>
> - I've introduced a mutex to make some parts thread-safe (I haven't
> checked if
> all the driver was).
> - Someone noticed that when 2 qtwidgets were running on 2 streams, closing
> them
> didn't close the driver properly. This should be fixed by now. When qApp
> is
> run, all the qtwidgets created before are tagged as being run, and so the
> driver shouldn't try to run one qApp per widget.
>
> Cheers,
>
> Alban
>
> __________________________
> Alan W. Irwin
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
>


-- 

António Rodrigues Tomé
Universidade da Beira Interior
Instituto D. Luís (lab associado)
email address:
ar...@gm...
ar...@ub...
http://www.researcherid.com/rid/A-5681-2013

Re: [Plplot-devel] Qt5 support, strange driver output

[Alan W. I. <Ala...@gm...>]

On 2018-12-20 13:21-0800 Alan W. Irwin wrote:

> On 2018-12-20 18:56-0000 António Rodrigues Tomé wrote:
>
>> Hi Alan
>> I do not completely understand the need of using a mutex in the qt driver
>> however
>> without any change in the actual driver approach it is easy to allow the
>> driver to work well within a qt app and also in any other c or c++ program
>> if in the file qt.cpp function  bool initQtApp( bool isGUI )
>> we add after the ++appCounter; line (line 90)
>> the instruction
>>    if(appCounter == 1 && qApp != NULL) ++appCounter;
>> this will prevent the call
>> delete qApp;
>> when one closes the driver within a qt application, that would crash teh
>> application,  and it does  not conflict with the actual behavior of the qt
>> driver it onnly takes account for the fact that there is a qApp that was
>> not started by the driver.
>
> Hi António:
[...]
> So from the point of view of a non-expert for this code, I would
> suggest if you think the mutex is no longer needed because of your
> change, then go ahead an remove it to see whether that combined change
> passes all tests you care to make including ideally running the
> comprehensive test script as documented in
> doc/wiki_source/Testing_PLplot.

With regard to the mutex, I have included what Alban initially said about
it way back when.

>From his comment my guess is the mutex is a necessity to keep the Qt
components of PLplot thread-safe because the PLplot core is not thread
safe (although fixing that bad state of affairs is on our long-term agenda).
And subsequently there was a whole lot of plplot-devel traffic about
properly setting up that mutex with no question from anyone about its
necessity.

Anyhow, forget my naive idea above that you might want to drop the mutex.

Alan

---------- Forwarded message ----------
Date: Fri, 20 Mar 2009 17:00:49 +0000
From: Alban Rochel <a.r...@im...>
To: Alan W. Irwin <ir...@be...>
Subject: Qt driver update

Alan,

I've made a break from QSAS for an hour and I've made a couple of improvements 
to the Qt driver.

- I've introduced a mutex to make some parts thread-safe (I haven't checked if 
all the driver was).
- Someone noticed that when 2 qtwidgets were running on 2 streams, closing them 
didn't close the driver properly. This should be fixed by now. When qApp is 
run, all the qtwidgets created before are tagged as being run, and so the 
driver shouldn't try to run one qApp per widget.

Cheers,

Alban

__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

[Plplot-devel] git blog

[Alan W. I. <Ala...@gm...>]

On 2018-12-22 17:46-0000 António Rodrigues Tomé wrote:

> Hi
> I must confess that I'm completely unable to work with git.
> As git is a widely used tool it is certainly my problem.
> After many hours just to be able to perform first instructions in develop
> file specially because I tried to read a git instruction to do a new branch
> but always get the info not a git repository. Only after many hours I
> conclude that was my local folder that was not a git and not the remote
> plplot site.
> 
> so I made a clone
> git clone  https://git.code.sf.net/p/plplot/plplot SourceforgePlplot
> 
> ~/SourceforgePlplot> git checkout -b QtIssues
> Switched to a new branch 'QtIssues'
> 
> changed the file qt.cpp
> 
> git commit
> On branch QtIssues
> Changes not staged for commit:
>       modified:   drivers/qt.cpp
> 
> no changes added to commit
> 
> 
> no clue what to do next.

Hi António:

I like to use the subject line "git blog" for git questions.  So I have changed 
to that.

The short answer to your question is use "git status" to find out what
is possible to do with your files under git.  In this case you want to
stage your changed files for commit so use "git add" to do that before
you execute "git commit".

To give someone who is just getting started with git some good
background, I recommend reading the the first chapter of
<https://git-scm.com/book/en/v2> in its entirety.  In particular,
<https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository>
answers your question above with more background than I have given.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________


_______________________________________________
Plplot-devel mailing list
Plp...@li...
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Qt5 support, strange driver output

[Alan W. I. <Ala...@gm...>]

On 2018-12-22 17:46-0000 António Rodrigues Tomé wrote:

> Hi
> I must confess that I'm completely unable to work with git.
> As git is a widely used tool it is certainly my problem.
> After many hours just to be able to perform first instructions in develop
> file specially because I tried to read a git instruction to do a new branch
> but always get the info not a git repository. Only after many hours I
> conclude that was my local folder that was not a git and not the remote
> plplot site.
>
> so I made a clone
> git clone  https://git.code.sf.net/p/plplot/plplot SourceforgePlplot
>
> ~/SourceforgePlplot> git checkout -b QtIssues
> Switched to a new branch 'QtIssues'
>
> changed the file qt.cpp
>
> git commit
> On branch QtIssues
> Changes not staged for commit:
>       modified:   drivers/qt.cpp
>
> no changes added to commit
>
>
> no clue what to do next.

Hi António:

I like to use the subject line "git blog" for git questions.  So I have changed to that.

The short answer to your question is use "git status" to find out what
is possible to do with your files under git.  In this case you want to
stage your changed files for commit so use "git add" to do that before
you execute "git commit".

To give someone who is just getting started with git some good
background, I recommend reading the the first chapter of
<https://git-scm.com/book/en/v2> in its entirety.  In particular,
<https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository>
answers your question above with more background than I have given.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Qt5 support, strange driver output

[António R. T. <ar...@gm...>]

Hi
I must confess that I'm completely unable to work with git.
As git is a widely used tool it is certainly my problem.
After many hours just to be able to perform first instructions in develop
file specially because I tried to read a git instruction to do a new branch
but always get the info not a git repository. Only after many hours I
conclude that was my local folder that was not a git and not the remote
plplot site.

so I made a clone
git clone  https://git.code.sf.net/p/plplot/plplot SourceforgePlplot

~/SourceforgePlplot> git checkout -b QtIssues
Switched to a new branch 'QtIssues'

changed the file qt.cpp

 git commit
On branch QtIssues
Changes not staged for commit:
       modified:   drivers/qt.cpp

no changes added to commit


no clue what to do next.

cheers,






On Thu, Dec 20, 2018 at 11:11 PM Alan W. Irwin <Ala...@gm...>
wrote:

> On 2018-12-20 22:30-0000 António Rodrigues Tomé wrote:
>
> > Hi Alan
> > I've never used git (I'm still a svn user) but I can give it a try.
>
> Hi António:
>
> Thanks for your willingness to try git to make it easier to
> communicate your suggested changes to us. Everything you should need
> to know about git from the PLplot development perspective is
> documented in README.developers, but if you don't understand something
> there, don't hesitate to ask your further git questions here.
>
> Alan
> __________________________
> Alan W. Irwin
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
>


-- 

António Rodrigues Tomé
Universidade da Beira Interior
Instituto D. Luís (lab associado)
email address:
ar...@gm...
ar...@ub...
http://www.researcherid.com/rid/A-5681-2013

Re: [Plplot-devel] Qt5 support, strange driver output

[Alan W. I. <Ala...@gm...>]

On 2018-12-20 22:30-0000 António Rodrigues Tomé wrote:

> Hi Alan
> I've never used git (I'm still a svn user) but I can give it a try.

Hi António:

Thanks for your willingness to try git to make it easier to
communicate your suggested changes to us. Everything you should need
to know about git from the PLplot development perspective is
documented in README.developers, but if you don't understand something
there, don't hesitate to ask your further git questions here.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Qt5 support, strange driver output

[António R. T. <ar...@gm...>]

Hi Alan
I've never used git (I'm still a svn user) but I can give it a try.
cheers,


On Thu, Dec 20, 2018 at 9:21 PM Alan W. Irwin <Ala...@gm...>
wrote:

> On 2018-12-20 18:56-0000 António Rodrigues Tomé wrote:
>
> > Hi Alan
> > I do not completely understand the need of using a mutex in the qt driver
> > however
> > without any change in the actual driver approach it is easy to allow the
> > driver to work well within a qt app and also in any other c or c++
> program
> > if in the file qt.cpp function  bool initQtApp( bool isGUI )
> > we add after the ++appCounter; line (line 90)
> > the instruction
> >    if(appCounter == 1 && qApp != NULL) ++appCounter;
> > this will prevent the call
> > delete qApp;
> > when one closes the driver within a qt application, that would crash teh
> > application,  and it does  not conflict with the actual behavior of the
> qt
> > driver it onnly takes account for the fact that there is a qApp that was
> > not started by the driver.
>
> Hi António:
>
> For your information all our Qt-related code got contributed by Alban
> Rochel from the QSAS group back in 2009.  And Alban move on to other
> work soon after so no current PLplot developer completely understands
> that code.  This problem is made worse in my own case because my C++
> and Qt skills are not that great.  Also note that my recent tests of
> qt_example and pyqt5_example for the Qt5 case have not gone well with
> qt_example segfaulting on exit on one occasion and pyqt5_example
> hanging on exit on one occasion.
>
> Despite these issues, the Qt-related components generally produce
> extremely high-quality results so any help you can give us with this
> code to make it more reliable would be much appreciated subject to the
> constraint that comprehensive testing of your changes has to work as
> well as my previous comprehensive tests.
>
> So from the point of view of a non-expert for this code, I would
> suggest if you think the mutex is no longer needed because of your
> change, then go ahead an remove it to see whether that combined change
> passes all tests you care to make including ideally running the
> comprehensive test script as documented in
> doc/wiki_source/Testing_PLplot.
>
> Also, descriptions of code changes (as you attempted to do above) are
> not really the best way to present your suggested changes to us.  So
> instead, I suggest you follow the "git format-patch" cookbook in
> README.developers in order to do that.  And don't hesitate to ask here
> if you have any trouble following that specific procedure or any other
> git advice we give there.
>
> Alan
> __________________________
> Alan W. Irwin
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
>


-- 

António Rodrigues Tomé
Universidade da Beira Interior
Instituto D. Luís (lab associado)
email address:
ar...@gm...
ar...@ub...
http://www.researcherid.com/rid/A-5681-2013

Re: [Plplot-devel] Qt5 support, strange driver output

[Alan W. I. <Ala...@gm...>]

On 2018-12-20 18:56-0000 António Rodrigues Tomé wrote:

> Hi Alan
> I do not completely understand the need of using a mutex in the qt driver
> however
> without any change in the actual driver approach it is easy to allow the
> driver to work well within a qt app and also in any other c or c++ program
> if in the file qt.cpp function  bool initQtApp( bool isGUI )
> we add after the ++appCounter; line (line 90)
> the instruction
>    if(appCounter == 1 && qApp != NULL) ++appCounter;
> this will prevent the call
> delete qApp;
> when one closes the driver within a qt application, that would crash teh
> application,  and it does  not conflict with the actual behavior of the qt
> driver it onnly takes account for the fact that there is a qApp that was
> not started by the driver.

Hi António:

For your information all our Qt-related code got contributed by Alban
Rochel from the QSAS group back in 2009.  And Alban move on to other
work soon after so no current PLplot developer completely understands
that code.  This problem is made worse in my own case because my C++
and Qt skills are not that great.  Also note that my recent tests of
qt_example and pyqt5_example for the Qt5 case have not gone well with
qt_example segfaulting on exit on one occasion and pyqt5_example
hanging on exit on one occasion.

Despite these issues, the Qt-related components generally produce
extremely high-quality results so any help you can give us with this
code to make it more reliable would be much appreciated subject to the
constraint that comprehensive testing of your changes has to work as
well as my previous comprehensive tests.

So from the point of view of a non-expert for this code, I would
suggest if you think the mutex is no longer needed because of your
change, then go ahead an remove it to see whether that combined change
passes all tests you care to make including ideally running the
comprehensive test script as documented in
doc/wiki_source/Testing_PLplot.

Also, descriptions of code changes (as you attempted to do above) are
not really the best way to present your suggested changes to us.  So
instead, I suggest you follow the "git format-patch" cookbook in
README.developers in order to do that.  And don't hesitate to ask here
if you have any trouble following that specific procedure or any other
git advice we give there.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Qt5 support, strange driver output

[António R. T. <ar...@gm...>]

Hi Alan
I do not completely understand the need of using a mutex in the qt driver
however
without any change in the actual driver approach it is easy to allow the
driver to work well within a qt app and also in any other c or c++ program
if in the file qt.cpp function  bool initQtApp( bool isGUI )
we add after the ++appCounter; line (line 90)
the instruction
    if(appCounter == 1 && qApp != NULL) ++appCounter;
this will prevent the call
delete qApp;
when one closes the driver within a qt application, that would crash teh
application,  and it does  not conflict with the actual behavior of the qt
driver it onnly takes account for the fact that there is a qApp that was
not started by the driver.


cheers,



On Mon, Dec 17, 2018 at 6:59 AM António Rodrigues Tomé <ar...@gm...>
wrote:

> Hi Alan
> Glad to be of some help.
> Really that empty string in family name especially when the matchof name
> is not an exact match could have strange results and could vary from system
> to system.
> In order for me to use qt drivers, as all my applications are qt based, I
> still need different things as I want to be able to call any of the qt
> drivers from within a qt appication. For now if I redefine two functions to
> doing nothing  in my main.ccp file before int main(int argc, char *argv[])
>
>
>    bool initQtApp( bool isGUI )
>
> {
>
>
> }
>
>
> void closeQtApp()
>
> {
>
>
> }
> It seems to work but i still need to check if there is not leak memory
> with this approach.
> In the future probably it would be nice if the drivers automatically
> could work from within a qt application.
>
> cheers,
>
>
> On Mon, Dec 17, 2018 at 1:41 AM Alan W. Irwin <Ala...@gm...>
> wrote:
>
>> On 2018-12-16 10:13-0000 António Rodrigues Tomé wrote:
>>
>> > Hi all
>> > I found no evidence of fontconfig not being working properly in my
>> system.
>> > so I've made a small test instead of setting font family to null string
>> > I've set it to a bogus name.
>> > f.setFamily( "BOUGUSTRASHFAMILY" ); // no family name, forcing Qt to
>> find
>> > an appropriate font by itself
>> > and in x01c example as there are four plots i edited the source to add
>> > the    plfont(1); before plot 1, plfont(2); before plot 2,
>> > plfont(3); before plot 3, plfont(4); before plot  4,  I also get erase
>> the
>> > esc text sequence that put title always in Roman.
>> > The results are what one would expected.
>>
>> Hi António:
>>
>> I agree, that one-line change seems to have solved all qt device
>> driver issues on your platform.  So I tried the equivalent here, and
>> it solves some less obvious Qt issues here for examples 23 and 24 that
>> have been around for quite a while.  So congratulations on finding a
>> solution to a PLplot qt device driver bug that has apparently been around
>> since the
>> very first development of that device!
>>
>> I commited a small variation (I added commentary and I replaced your
>> bogus family name because it was [barely] conceivable a valid font
>> might adopt that family name) of your fix as of
>> plplot-5.14.0-8-gdb9d90d0b.  So please test that commit (by using git
>> checkout plplot-5.14.0-8-gdb9d90d0b before building PLplot from the
>> git version) to make sure it answers all your qt device needs (other
>> than character size).
>>
>> @Everybody:
>>
>> This fix is pretty crucial for our qt device driver because it appears
>> to fix all long-standing font problems (including character alignment
>> for António) for that device driver.  Therefore, I intend to release
>> 5.14.1
>> with this fix and any other critical fixes that show up in the next few
>> weeks.
>>
>> More about the git process I should use to create a bug-fix release
>> (such as the proposed 5.14.1) in my next post.
>>
>> Alan
>> __________________________
>> Alan W. Irwin
>>
>> Programming affiliations with the FreeEOS equation-of-state
>> implementation for stellar interiors (freeeos.sf.net); the Time
>> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
>> software package (plplot.sf.net); the libLASi project
>> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
>> and the Linux Brochure Project (lbproject.sf.net).
>> __________________________
>>
>> Linux-powered Science
>> __________________________
>>
>
>
> --
>
> António Rodrigues Tomé
> Universidade da Beira Interior
> Instituto D. Luís (lab associado)
> email address:
> ar...@gm...
> ar...@ub...
> http://www.researcherid.com/rid/A-5681-2013
>
>

-- 

António Rodrigues Tomé
Universidade da Beira Interior
Instituto D. Luís (lab associado)
email address:
ar...@gm...
ar...@ub...
http://www.researcherid.com/rid/A-5681-2013

Re: [Plplot-devel] Help needed for plplot runtime tests

[Alan W. I. <Ala...@gm...>]

On 2018-11-15 01:10-0800 Alan W. Irwin wrote:
[...]
> I need to implement the following two upstream
> upgrades:
>
> 1. I need to factor the exported target files, e.g., the two
> export_plplot* files mentioned above.  Such factoring had already been
> highly recommended to me by CMake gurus, and I think it should be
> entirely straightforward.
[...]
> 2. Currently the installed examples generally just check if a given
> component has been configured in the core build, by, e.g., checking
> ENABLE_cxx.  But with some of those configured components potentially
> missing because a user did not install all plplot binary packages such
> a check is not correct and needs to be replaced by a test for the
> existence of the exported target, e.g., PLPLOT::plplotcxx.  These
> sorts of changes should also be straightforward.

To Ole and Orion:

Here is the current status of these proposed upstream changes.

As of commit plplot-5.14.0-10-g66d68d93e I have implemented (and
thoroughly tested) the first upgrade above.  Because of this change, the
list of export-related files (for my normal case of a fully loaded
Debian Testing platform where I don't specify
a build configuration) has now expanded to the following:

export__Pltk_init-noconfig.cmake
export__Pltk_init.cmake
export__plplotc-noconfig.cmake
export__plplotc.cmake
export_cairo-noconfig.cmake
export_cairo.cmake
export_csirocsa-noconfig.cmake
export_csirocsa.cmake
export_csironn-noconfig.cmake
export_csironn.cmake
export_mem-noconfig.cmake
export_mem.cmake
export_ntk-noconfig.cmake
export_ntk.cmake
export_null-noconfig.cmake
export_null.cmake
export_pdf-noconfig.cmake
export_pdf.cmake
export_plfortrandemolib-noconfig.cmake
export_plfortrandemolib.cmake
export_plplot-noconfig.cmake
export_plplot.cmake
export_plplot_octave-noconfig.cmake
export_plplot_octave.cmake
export_plplot_pyqt5-noconfig.cmake
export_plplot_pyqt5.cmake
export_plplotada-noconfig.cmake
export_plplotada.cmake
export_plplotcxx-noconfig.cmake
export_plplotcxx.cmake
export_plplotdmd-noconfig.cmake
export_plplotdmd.cmake
export_plplotfortran-noconfig.cmake
export_plplotfortran.cmake
export_plplotluac-noconfig.cmake
export_plplotluac.cmake
export_plplotqt-noconfig.cmake
export_plplotqt.cmake
export_plplottcltk-noconfig.cmake
export_plplottcltk.cmake
export_plplottcltk_Main-noconfig.cmake
export_plplottcltk_Main.cmake
export_plplotwxwidgets-noconfig.cmake
export_plplotwxwidgets.cmake
export_plserver-noconfig.cmake
export_plserver.cmake
export_pltcl-noconfig.cmake
export_pltcl.cmake
export_pltek-noconfig.cmake
export_pltek.cmake
export_ps-noconfig.cmake
export_ps.cmake
export_psttf-noconfig.cmake
export_psttf.cmake
export_qsastime-noconfig.cmake
export_qsastime.cmake
export_qt-noconfig.cmake
export_qt.cmake
export_svg-noconfig.cmake
export_svg.cmake
export_tclmatrix-noconfig.cmake
export_tclmatrix.cmake
export_tk-noconfig.cmake
export_tk.cmake
export_tkwin-noconfig.cmake
export_tkwin.cmake
export_wxPLViewer-noconfig.cmake
export_wxPLViewer.cmake
export_wxwidgets-noconfig.cmake
export_wxwidgets.cmake
export_xfig-noconfig.cmake
export_xfig.cmake
export_xwin-noconfig.cmake
export_xwin.cmake
plplotConfig.cmake
plplot_exports.cmake

See the detailed commit message for plplot-5.14.0-10-g66d68d93e for the implications
of this change for packagers.

Once you have added the above export files to the correct binary packages following that advice, you
should be able to configure the installed examples project
with cmake (with no options) and run

make -j$JOBS test_noninteractive

without issues just like before (i.e., you will still be subject to the constraint
that all binary packages for PLplot have to be installed in order for this to work).

To finish off this topic, my next PLplot priority is to follow up with
the second upstream change mentioned above which should remove the
constraint that all binary packages for PLplot have to be installed in
order to test both your binary PLplot packages that are installed, and
your package containing the installed examples in the above way.

But meanwhile, I hope you are both able to test your binary packages
for PLplot and your package containing the installed examples for
plplot-5.14.0-10-g66d68d93e in the above way subject to the temporary
"all installed" constraint.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] git workflow plans for the proposed bug-fix plplot-5.14.1 release

[Alan W. I. <Ala...@gm...>]

Hi Phil:

On 2018-12-18 00:33-0000 Phil Rosenberg wrote:

> Sounds like a generally good plan to me.

Good.

> The only issues might be picking what is a bug fix commit vs a non
   bug fix commit - I'm sure we are all guilty of finding a bug while
   changing code and not submitting it as a separate commit. But
   providing we all try to be good in that sense, I think a bug fixes
   release is a good idea.

The other important issue is whether the bug is a regression or not.
Regressions mean by definition that users of prior versions of PLplot
are going to get a nasty surprise by the new version of PLplot.  So
avoidance of regressions is my motivation for asking for comprehensive
testing on all platforms prior to each release, and anytime such
a regression is turned up by such testing, I view it as release critical,
i.e., the release should be held until a proper fix for the regression
has been implemented.  However, if a regression actually gets into a
release despite our testing efforts, then that would be a large
motivation to immediately issue a bug-fix release containing the
fix for that regression.

But I would rather not learn about the git steps needed for a bug-fix
release under such time pressure, and the present bug fix has a wide
impact for all our present or future qt device users.  So I am going
to use the present impactful bug fix as a good excuse to get educated
on the git steps needed to create a bug-fix release.  However, I will
likely not be willing to do this again unless the bug fix is actually
a fix for a regression.  Instead, I would like to spend most of my
PLplot effort on development and making sure that our regular releases
(which normally include both bug fixes and new development) occur
every 6 months or less.  Due to a variety of excuses I haven't managed
to do that recently, but I am planning on having a much better
ordinary release outcome in the latter part of the first half of 2019.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] git workflow plans for the proposed bug-fix plplot-5.14.1 release

[Phil R. <p.d...@gm...>]

Sounds like a generally good plan to me. The only issues might be picking what is a bug fix commit vs a non bug fix commit - I'm sure we are all guilty of finding a bug while changing code and not submitting it as a separate commit. But providing we all try to be good in that sense, I think a bug fixes release is a good idea.

Phil

Get Outlook for Android<https://aka.ms/ghei36>

________________________________
From: Alan W. Irwin <Ala...@gm...>
Sent: Monday, December 17, 2018 5:31:31 AM
To: PLplot development list
Subject: [Plplot-devel] git workflow plans for the proposed bug-fix plplot-5.14.1 release

Can some git guru here review my proposed git workflow for the planned
5.14.1 release below?

The reason I ask for that review is because I currently have no
practical experience with some of the special git commands that will
be needed.  In fact, because of that lack of experience I previously
did not create a bug-fix release in an earlier release cycle for
PLplot (at least in its git era) when I likely should have!  So this
bug-fix release will be a long-overdue learning experience for me.

That said, I am pretty sure from reading on-line material and a hint
from one of our users what git steps I would have to take.  Also note
these proposed steps do not violate our (enforced) workflow rule that
no merge commits other than fast-forwarded ones are allowed.

Those git steps are as follows:

* Create a local branch called 5.14.0-bugfix from the existing plplot-5.14.0 tag.

* Cherry pick bug-fix commits such as plplot-5.14.0-8-gdb9d90d0b onto that branch.

* Go through the usual release procedure while staying strictly on
   that branch which will add other commits to that branch such as the
   new (short) release notes and ChangeLog for that 5.14.1 release
   without ever merging those commits back to master.  Which means none
   of this bugfix release work impacts on the ordinary development of
   the master branch.  One of the last steps in that procedure would be
   to push the local tag that points to the tip of 5.14.0-bugfix
   (called plplot-5.14.1 in this case) to our SF git repository (again
   without changing the master branch).

* From remarks in
   <https://stackoverflow.com/questions/9265278/what-happens-if-i-push-a-tag-for-a-commit-that-hasnt-been-pushed>
   it appears that pushing a tag pushes the associated commit and also
   pushes all ancestors of that commit that have not been pushed
   before.

   If that is correct, then all commits on my local branch called
   "5.14.0-bugfix" will end up accessible at SF but not organized as a
   formal branch there.  That result is fine with me since it doesn't
   clutter the SF version with extra branch names, and the result is
   enough to allow anybody (after they use the "git refresh" command)
   to access the commit corresponding to the plplot-5.14.1 tag or any
   of that commit's ancestors.  For example, if later on during the
   release cycle I decided to release another bug-fix release called
   5.14.2, I could start that process by branching from the
   plplot-5.14.1 tag.

   Furthmore after pushing the plplot-5.14.1 tag I would likely delete
   the 5.14.0-bugfix local branch to be consistent with the SF repository;
   I would have no further use for that branch; and
   that branch deletion does not get rid of the plplot-5.14.1 tag,
   the associated commit or any ancestors of that commit;

   Of course, with this model of workflow for bug-fix releases, no
   attempt would ever be made to merge bug-fix branches back to master
   since that makes no sense in any case and would violate our
   (enforced) rebase work flow rule that there can be no merge commits
   that cannot be fast-forwarded.

Again, comments on this plan from the git gurus here will be most welcome.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________


_______________________________________________
Plplot-devel mailing list
Plp...@li...
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Qt5 support, strange driver output

[António R. T. <ar...@gm...>]

Hi Alan
Glad to be of some help.
Really that empty string in family name especially when the matchof name is
not an exact match could have strange results and could vary from system to
system.
In order for me to use qt drivers, as all my applications are qt based, I
still need different things as I want to be able to call any of the qt
drivers from within a qt appication. For now if I redefine two functions to
doing nothing  in my main.ccp file before int main(int argc, char *argv[])


   bool initQtApp( bool isGUI )

{


}


void closeQtApp()

{


}
It seems to work but i still need to check if there is not leak memory with
this approach.
In the future probably it would be nice if the drivers automatically  could
work from within a qt application.

cheers,


On Mon, Dec 17, 2018 at 1:41 AM Alan W. Irwin <Ala...@gm...>
wrote:

> On 2018-12-16 10:13-0000 António Rodrigues Tomé wrote:
>
> > Hi all
> > I found no evidence of fontconfig not being working properly in my
> system.
> > so I've made a small test instead of setting font family to null string
> > I've set it to a bogus name.
> > f.setFamily( "BOUGUSTRASHFAMILY" ); // no family name, forcing Qt to find
> > an appropriate font by itself
> > and in x01c example as there are four plots i edited the source to add
> > the    plfont(1); before plot 1, plfont(2); before plot 2,
> > plfont(3); before plot 3, plfont(4); before plot  4,  I also get erase
> the
> > esc text sequence that put title always in Roman.
> > The results are what one would expected.
>
> Hi António:
>
> I agree, that one-line change seems to have solved all qt device
> driver issues on your platform.  So I tried the equivalent here, and
> it solves some less obvious Qt issues here for examples 23 and 24 that
> have been around for quite a while.  So congratulations on finding a
> solution to a PLplot qt device driver bug that has apparently been around
> since the
> very first development of that device!
>
> I commited a small variation (I added commentary and I replaced your
> bogus family name because it was [barely] conceivable a valid font
> might adopt that family name) of your fix as of
> plplot-5.14.0-8-gdb9d90d0b.  So please test that commit (by using git
> checkout plplot-5.14.0-8-gdb9d90d0b before building PLplot from the
> git version) to make sure it answers all your qt device needs (other
> than character size).
>
> @Everybody:
>
> This fix is pretty crucial for our qt device driver because it appears
> to fix all long-standing font problems (including character alignment
> for António) for that device driver.  Therefore, I intend to release 5.14.1
> with this fix and any other critical fixes that show up in the next few
> weeks.
>
> More about the git process I should use to create a bug-fix release
> (such as the proposed 5.14.1) in my next post.
>
> Alan
> __________________________
> Alan W. Irwin
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
>


-- 

António Rodrigues Tomé
Universidade da Beira Interior
Instituto D. Luís (lab associado)
email address:
ar...@gm...
ar...@ub...
http://www.researcherid.com/rid/A-5681-2013

[Plplot-devel] git workflow plans for the proposed bug-fix plplot-5.14.1 release

[Alan W. I. <Ala...@gm...>]

Can some git guru here review my proposed git workflow for the planned
5.14.1 release below?

The reason I ask for that review is because I currently have no
practical experience with some of the special git commands that will
be needed.  In fact, because of that lack of experience I previously
did not create a bug-fix release in an earlier release cycle for
PLplot (at least in its git era) when I likely should have!  So this
bug-fix release will be a long-overdue learning experience for me.

That said, I am pretty sure from reading on-line material and a hint
from one of our users what git steps I would have to take.  Also note
these proposed steps do not violate our (enforced) workflow rule that
no merge commits other than fast-forwarded ones are allowed.

Those git steps are as follows:

* Create a local branch called 5.14.0-bugfix from the existing plplot-5.14.0 tag.

* Cherry pick bug-fix commits such as plplot-5.14.0-8-gdb9d90d0b onto that branch.

* Go through the usual release procedure while staying strictly on
   that branch which will add other commits to that branch such as the
   new (short) release notes and ChangeLog for that 5.14.1 release
   without ever merging those commits back to master.  Which means none
   of this bugfix release work impacts on the ordinary development of
   the master branch.  One of the last steps in that procedure would be
   to push the local tag that points to the tip of 5.14.0-bugfix
   (called plplot-5.14.1 in this case) to our SF git repository (again
   without changing the master branch).

* From remarks in
   <https://stackoverflow.com/questions/9265278/what-happens-if-i-push-a-tag-for-a-commit-that-hasnt-been-pushed>
   it appears that pushing a tag pushes the associated commit and also
   pushes all ancestors of that commit that have not been pushed
   before.

   If that is correct, then all commits on my local branch called
   "5.14.0-bugfix" will end up accessible at SF but not organized as a
   formal branch there.  That result is fine with me since it doesn't
   clutter the SF version with extra branch names, and the result is
   enough to allow anybody (after they use the "git refresh" command)
   to access the commit corresponding to the plplot-5.14.1 tag or any
   of that commit's ancestors.  For example, if later on during the
   release cycle I decided to release another bug-fix release called
   5.14.2, I could start that process by branching from the
   plplot-5.14.1 tag.

   Furthmore after pushing the plplot-5.14.1 tag I would likely delete
   the 5.14.0-bugfix local branch to be consistent with the SF repository;
   I would have no further use for that branch; and
   that branch deletion does not get rid of the plplot-5.14.1 tag,
   the associated commit or any ancestors of that commit;

   Of course, with this model of workflow for bug-fix releases, no
   attempt would ever be made to merge bug-fix branches back to master
   since that makes no sense in any case and would violate our
   (enforced) rebase work flow rule that there can be no merge commits
   that cannot be fast-forwarded.

Again, comments on this plan from the git gurus here will be most welcome.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Qt5 support, strange driver output

[Alan W. I. <Ala...@gm...>]

On 2018-12-16 10:13-0000 António Rodrigues Tomé wrote:

> Hi all
> I found no evidence of fontconfig not being working properly in my system.
> so I've made a small test instead of setting font family to null string
> I've set it to a bogus name.
> f.setFamily( "BOUGUSTRASHFAMILY" ); // no family name, forcing Qt to find
> an appropriate font by itself
> and in x01c example as there are four plots i edited the source to add
> the    plfont(1); before plot 1, plfont(2); before plot 2,
> plfont(3); before plot 3, plfont(4); before plot  4,  I also get erase the
> esc text sequence that put title always in Roman.
> The results are what one would expected.

Hi António:

I agree, that one-line change seems to have solved all qt device
driver issues on your platform.  So I tried the equivalent here, and
it solves some less obvious Qt issues here for examples 23 and 24 that
have been around for quite a while.  So congratulations on finding a
solution to a PLplot qt device driver bug that has apparently been around since the
very first development of that device!

I commited a small variation (I added commentary and I replaced your
bogus family name because it was [barely] conceivable a valid font
might adopt that family name) of your fix as of
plplot-5.14.0-8-gdb9d90d0b.  So please test that commit (by using git
checkout plplot-5.14.0-8-gdb9d90d0b before building PLplot from the
git version) to make sure it answers all your qt device needs (other
than character size).

@Everybody:

This fix is pretty crucial for our qt device driver because it appears
to fix all long-standing font problems (including character alignment
for António) for that device driver.  Therefore, I intend to release 5.14.1
with this fix and any other critical fixes that show up in the next few weeks.

More about the git process I should use to create a bug-fix release
(such as the proposed 5.14.1) in my next post.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Qt5 support, strange driver output

[António R. T. <ar...@gm...>]

Hi all
I found no evidence of fontconfig not being working properly in my system.
so I've made a small test instead of setting font family to null string
I've set it to a bogus name.
f.setFamily( "BOUGUSTRASHFAMILY" ); // no family name, forcing Qt to find
an appropriate font by itself
and in x01c example as there are four plots i edited the source to add
the    plfont(1); before plot 1, plfont(2); before plot 2,
plfont(3); before plot 3, plfont(4); before plot  4,  I also get erase the
esc text sequence that put title always in Roman.
The results are what one would expected.
cheers


On Sun, Dec 16, 2018 at 7:40 AM António Rodrigues Tomé <ar...@gm...>
wrote:

> Hi Alan thanks for this detailed explanation. The inclusion of helvetica
> was only a test to make sure it was indeed a font load problem it was not
> intended to be a definitive solution. One of the first things I checked was
> that fontconfig  was installed. I will dig deeper into this before report
> to opensuse at very least I will have to find a more suitable, and clean
> example where fontconfig fails. A plplot example is not the most
> appropriated situation to report.
> Cheers
>
> On Sun, 16 Dec 2018, 06:11 Alan W. Irwin <Ala...@gm...
> wrote:
>
>> On 2018-12-16 00:07-0000 António Rodrigues Tomé wrote:
>>
>> > Hi all
>> > after trying a long time playing with cmake options trying to see if I
>> > could get my qt5 plplot loading suitable f fonts I came to conclude
>> that my
>> > distribution in a way acts differently from Alan's.
>> > I get very nice results if in the file plqt.cpp line 182
>> > where is
>> >    f.setFamily(""); // no family name, forcing Qt to find an appropriate
>> > font by itself
>> >
>> > I replaced by
>> >   f.setFamily("Helvetica"); // no family name, forcing Qt to find an
>> > appropriate font by itself
>> >
>> > it seems in my system qt does not find an appropriate font by itsel. I
>> > attach the very nice results obtained only by performed this small
>> change.
>>
>> Hi António:
>>
>> The problem with this workaround is Helevetica is a Sans-Serif font so
>> this approach means you have
>> excluded serif and monospace possibilities for the PLplot qt device
>> driver user.
>>
>> Furthermore, how fonts are chosen by Qt is documented in <
>> http://doc.qt.io/qt-5/qfont.html#details>.
>>
>> There is a lot of information there, but the relevant points for this
>> discussion are
>>
>> ---------------------------
>> enum QFont::StyleHint
>>
>> Style hints are used by the font matching algorithm to find an
>> appropriate default family if a selected font family is not available.
>> Constant        Value   Description
>> QFont::AnyStyle 5       leaves the font matching algorithm to choose the
>> family. This is the default.
>> QFont::SansSerif        Helvetica       the font matcher prefer sans
>> serif fonts.
>> QFont::Helvetica        0       is a synonym for SansSerif.
>> QFont::Serif    Times   the font matcher prefers serif fonts.
>> QFont::Times    1       is a synonym for Serif.
>> QFont::TypeWriter       Courier the font matcher prefers fixed pitch
>> fonts.
>> QFont::Courier  2       a synonym for TypeWriter.
>> QFont::OldEnglish       3       the font matcher prefers decorative fonts.
>> QFont::Decorative       OldEnglish      is a synonym for OldEnglish.
>> QFont::Monospace        7       the font matcher prefers fonts that map
>> to the CSS generic font-family 'monospace'.
>> QFont::Fantasy  8       the font matcher prefers fonts that map to the
>> CSS generic font-family 'fantasy'.
>> QFont::Cursive  6       the font matcher prefers fonts that map to the
>> CSS generic font-family 'cursive'.
>> QFont::System   4       the font matcher prefers system fonts.
>> ---------------------------
>>
>> ---------------------------
>> The font matching algorithm works as follows:
>>
>> 1. The specified font family is searched for.
>> 2. If not found, the styleHint() is used to select a replacement family.
>> 3. Each replacement font family is searched for.
>> 4. If none of these are found or there was no styleHint(), "helvetica"
>> will be searched for.
>> 5. If "helvetica" isn't found Qt will try the lastResortFamily().
>> 6. If the lastResortFamily() isn't found Qt will try the lastResortFont()
>> which will always return a name of some kind.
>> ---------------------------
>>
>> Here is more context for the code we are discussing from
>> bindings/qt-gui/plqt.cpp.
>>
>> switch ( fontFamily )
>>      {
>>      case 1:
>>          f.setStyleHint( QFont::Serif );
>>          break;
>>      case 2:
>>          f.setStyleHint( QFont::TypeWriter );
>>          break;
>>      case 0: case 3: case 4: default:
>>          f.setStyleHint( QFont::SansSerif );
>>          break;
>>      }
>>      f.setFamily( "" ); // no family name, forcing Qt to find an
>> appropriate font by itself
>>
>> So by this code setting the Family to an empty string we force Step 1
>> above to fail and fall back to one of the QFont::Serif,
>> QFont::TypeWriter, or QFont::SansSerif depending on what the user has
>> requested for the (generic) font family.  And this font finding all
>> works fine (as you would expect from the above documentation) for
>> Debian Buster with Qt-5.11.2, for the much older Qt5 version I used
>> for Debian Oldstable last year, and for many different versions of Qt4
>> before that.
>>
>> I strongly suspect what is going on is you don't have fontconfig
>> installed, in which
>> case the search algorithm above would drop through to step 6 consistent
>> with your
>> observation that the unmodified PLplot code has an extremely
>> limited font selection.
>>
>> But if you confirm you do have fontconfig installed, then you have a
>> strong basis for a bug report to opensuse since setStyleHint appears
>> not to be working on that platform.
>>
>> Alan
>> __________________________
>> Alan W. Irwin
>>
>> Programming affiliations with the FreeEOS equation-of-state
>> implementation for stellar interiors (freeeos.sf.net); the Time
>> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
>> software package (plplot.sf.net); the libLASi project
>> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
>> and the Linux Brochure Project (lbproject.sf.net).
>> __________________________
>>
>> Linux-powered Science
>> __________________________
>>
>

-- 

António Rodrigues Tomé
Universidade da Beira Interior
Instituto D. Luís (lab associado)
email address:
ar...@gm...
ar...@ub...
http://www.researcherid.com/rid/A-5681-2013

Re: [Plplot-devel] Qt5 support, strange driver output

[António R. T. <ar...@gm...>]

Hi Alan thanks for this detailed explanation. The inclusion of helvetica
was only a test to make sure it was indeed a font load problem it was not
intended to be a definitive solution. One of the first things I checked was
that fontconfig  was installed. I will dig deeper into this before report
to opensuse at very least I will have to find a more suitable, and clean
example where fontconfig fails. A plplot example is not the most
appropriated situation to report.
Cheers

On Sun, 16 Dec 2018, 06:11 Alan W. Irwin <Ala...@gm... wrote:

> On 2018-12-16 00:07-0000 António Rodrigues Tomé wrote:
>
> > Hi all
> > after trying a long time playing with cmake options trying to see if I
> > could get my qt5 plplot loading suitable f fonts I came to conclude that
> my
> > distribution in a way acts differently from Alan's.
> > I get very nice results if in the file plqt.cpp line 182
> > where is
> >    f.setFamily(""); // no family name, forcing Qt to find an appropriate
> > font by itself
> >
> > I replaced by
> >   f.setFamily("Helvetica"); // no family name, forcing Qt to find an
> > appropriate font by itself
> >
> > it seems in my system qt does not find an appropriate font by itsel. I
> > attach the very nice results obtained only by performed this small
> change.
>
> Hi António:
>
> The problem with this workaround is Helevetica is a Sans-Serif font so
> this approach means you have
> excluded serif and monospace possibilities for the PLplot qt device driver
> user.
>
> Furthermore, how fonts are chosen by Qt is documented in <
> http://doc.qt.io/qt-5/qfont.html#details>.
>
> There is a lot of information there, but the relevant points for this
> discussion are
>
> ---------------------------
> enum QFont::StyleHint
>
> Style hints are used by the font matching algorithm to find an appropriate
> default family if a selected font family is not available.
> Constant        Value   Description
> QFont::AnyStyle 5       leaves the font matching algorithm to choose the
> family. This is the default.
> QFont::SansSerif        Helvetica       the font matcher prefer sans serif
> fonts.
> QFont::Helvetica        0       is a synonym for SansSerif.
> QFont::Serif    Times   the font matcher prefers serif fonts.
> QFont::Times    1       is a synonym for Serif.
> QFont::TypeWriter       Courier the font matcher prefers fixed pitch fonts.
> QFont::Courier  2       a synonym for TypeWriter.
> QFont::OldEnglish       3       the font matcher prefers decorative fonts.
> QFont::Decorative       OldEnglish      is a synonym for OldEnglish.
> QFont::Monospace        7       the font matcher prefers fonts that map to
> the CSS generic font-family 'monospace'.
> QFont::Fantasy  8       the font matcher prefers fonts that map to the CSS
> generic font-family 'fantasy'.
> QFont::Cursive  6       the font matcher prefers fonts that map to the CSS
> generic font-family 'cursive'.
> QFont::System   4       the font matcher prefers system fonts.
> ---------------------------
>
> ---------------------------
> The font matching algorithm works as follows:
>
> 1. The specified font family is searched for.
> 2. If not found, the styleHint() is used to select a replacement family.
> 3. Each replacement font family is searched for.
> 4. If none of these are found or there was no styleHint(), "helvetica"
> will be searched for.
> 5. If "helvetica" isn't found Qt will try the lastResortFamily().
> 6. If the lastResortFamily() isn't found Qt will try the lastResortFont()
> which will always return a name of some kind.
> ---------------------------
>
> Here is more context for the code we are discussing from
> bindings/qt-gui/plqt.cpp.
>
> switch ( fontFamily )
>      {
>      case 1:
>          f.setStyleHint( QFont::Serif );
>          break;
>      case 2:
>          f.setStyleHint( QFont::TypeWriter );
>          break;
>      case 0: case 3: case 4: default:
>          f.setStyleHint( QFont::SansSerif );
>          break;
>      }
>      f.setFamily( "" ); // no family name, forcing Qt to find an
> appropriate font by itself
>
> So by this code setting the Family to an empty string we force Step 1
> above to fail and fall back to one of the QFont::Serif,
> QFont::TypeWriter, or QFont::SansSerif depending on what the user has
> requested for the (generic) font family.  And this font finding all
> works fine (as you would expect from the above documentation) for
> Debian Buster with Qt-5.11.2, for the much older Qt5 version I used
> for Debian Oldstable last year, and for many different versions of Qt4
> before that.
>
> I strongly suspect what is going on is you don't have fontconfig
> installed, in which
> case the search algorithm above would drop through to step 6 consistent
> with your
> observation that the unmodified PLplot code has an extremely
> limited font selection.
>
> But if you confirm you do have fontconfig installed, then you have a
> strong basis for a bug report to opensuse since setStyleHint appears
> not to be working on that platform.
>
> Alan
> __________________________
> Alan W. Irwin
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
>

Re: [Plplot-devel] Qt5 support, strange driver output

[Alan W. I. <Ala...@gm...>]

On 2018-12-16 00:07-0000 António Rodrigues Tomé wrote:

> Hi all
> after trying a long time playing with cmake options trying to see if I
> could get my qt5 plplot loading suitable f fonts I came to conclude that my
> distribution in a way acts differently from Alan's.
> I get very nice results if in the file plqt.cpp line 182
> where is
>    f.setFamily(""); // no family name, forcing Qt to find an appropriate
> font by itself
>
> I replaced by
>   f.setFamily("Helvetica"); // no family name, forcing Qt to find an
> appropriate font by itself
>
> it seems in my system qt does not find an appropriate font by itsel. I
> attach the very nice results obtained only by performed this small change.

Hi António:

The problem with this workaround is Helevetica is a Sans-Serif font so this approach means you have
excluded serif and monospace possibilities for the PLplot qt device driver user.

Furthermore, how fonts are chosen by Qt is documented in <http://doc.qt.io/qt-5/qfont.html#details>.

There is a lot of information there, but the relevant points for this discussion are

---------------------------
enum QFont::StyleHint

Style hints are used by the font matching algorithm to find an appropriate default family if a selected font family is not available.
Constant	Value	Description
QFont::AnyStyle	5	leaves the font matching algorithm to choose the family. This is the default.
QFont::SansSerif	Helvetica	the font matcher prefer sans serif fonts.
QFont::Helvetica	0	is a synonym for SansSerif.
QFont::Serif	Times	the font matcher prefers serif fonts.
QFont::Times	1	is a synonym for Serif.
QFont::TypeWriter	Courier	the font matcher prefers fixed pitch fonts.
QFont::Courier	2	a synonym for TypeWriter.
QFont::OldEnglish	3	the font matcher prefers decorative fonts.
QFont::Decorative	OldEnglish	is a synonym for OldEnglish.
QFont::Monospace	7	the font matcher prefers fonts that map to the CSS generic font-family 'monospace'.
QFont::Fantasy	8	the font matcher prefers fonts that map to the CSS generic font-family 'fantasy'.
QFont::Cursive	6	the font matcher prefers fonts that map to the CSS generic font-family 'cursive'.
QFont::System	4	the font matcher prefers system fonts.
---------------------------

---------------------------
The font matching algorithm works as follows:

1. The specified font family is searched for.
2. If not found, the styleHint() is used to select a replacement family.
3. Each replacement font family is searched for.
4. If none of these are found or there was no styleHint(), "helvetica" will be searched for.
5. If "helvetica" isn't found Qt will try the lastResortFamily().
6. If the lastResortFamily() isn't found Qt will try the lastResortFont() which will always return a name of some kind.
---------------------------

Here is more context for the code we are discussing from
bindings/qt-gui/plqt.cpp.

switch ( fontFamily )
     {
     case 1:
         f.setStyleHint( QFont::Serif );
         break;
     case 2:
         f.setStyleHint( QFont::TypeWriter );
         break;
     case 0: case 3: case 4: default:
         f.setStyleHint( QFont::SansSerif );
         break;
     }
     f.setFamily( "" ); // no family name, forcing Qt to find an appropriate font by itself

So by this code setting the Family to an empty string we force Step 1
above to fail and fall back to one of the QFont::Serif,
QFont::TypeWriter, or QFont::SansSerif depending on what the user has
requested for the (generic) font family.  And this font finding all
works fine (as you would expect from the above documentation) for
Debian Buster with Qt-5.11.2, for the much older Qt5 version I used
for Debian Oldstable last year, and for many different versions of Qt4
before that.

I strongly suspect what is going on is you don't have fontconfig installed, in which
case the search algorithm above would drop through to step 6 consistent with your
observation that the unmodified PLplot code has an extremely
limited font selection.

But if you confirm you do have fontconfig installed, then you have a
strong basis for a bug report to opensuse since setStyleHint appears
not to be working on that platform.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Qt5 support, strange driver output

[Alan W. I. <Ala...@gm...>]

On 2018-12-15 21:38-0000 António Rodrigues Tomé wrote:

> Hi all,
>
> This seems to be a truetype font issue my plots were  made without true
> type support. I noticed the difference between Alan plots and mine were not
> only in position and orientation but also in fonts used.
> I have a lot of true types fonts installed but for strange reason none is
> selected.

Hi António:

PLplot's lack of access to system fonts on your platform is indeed a
most peculiar result.

You probably know this already, but just to remind you, PLplot users
of TTF fonts can specify only generic fonts such as "sans" and
"serif", and then it is up to device driver to find for a given UCS4
glyph request, the best system glyph that belongs to the generic
family.  For example, the cairo device driver uses a subset of the
GTK+ suite of libraries to create plots, and that suite uses
fontconfig to find the appropriate system glyph.  And the qt device
driver uses a subset of the QT suite of libraries to create plots, and
that suite also uses fontconfig in the same way, but if fontconfig is
not available it falls back to an emergency way of selecting glyphs
that doesn't give very good results.

So from your bad font results my guess is you either don't have
fontconfig installed at all or it has a broken configuration.

For what it is worth, here is a list of all packages I have installed
that have anything to do with fonts.

-------------------------------------------8<-------------------------------------

irwin@merlin> dpkg --list |grep -i font
ii  aglfn                                         1.7-3                        all          Adobe Glyph List For New Fonts
ii  console-setup                                 1.187                        all          console font and keymap setup program
ii  fontconfig                                    2.13.1-2                     amd64        generic font configuration library - support binaries
ii  fontconfig-config                             2.13.1-2                     all          generic font configuration library - configuration
ii  fonts-adf-oldania                             0.20110505-3                 all          Oldania font of the Arkandis Digital Foundry
ii  fonts-dejavu                                  2.37-1                       all          metapackage to pull in fonts-dejavu-core and fonts-dejavu-extra
ii  fonts-dejavu-core                             2.37-1                       all          Vera font family derivate with additional characters
ii  fonts-dejavu-extra                            2.37-1                       all          Vera font family derivate with additional characters (extra variants)
ii  fonts-droid-fallback                          1:6.0.1r16-1.1               all          handheld device font with extensive style and language support (fallback)
ii  fonts-font-awesome                            5.0.10+really4.7.0~dfsg-1    all          iconic font designed for use with Twitter Bootstrap
ii  fonts-freefont-otf                            20120503-8                   all          Freefont Serif, Sans and Mono OpenType fonts
ii  fonts-freefont-ttf                            20120503-8                   all          Freefont Serif, Sans and Mono Truetype fonts
ii  fonts-gfs-baskerville                         1.1-5                        all          ancient Greek font revival
ii  fonts-gfs-porson                              1.1-6                        all          Greek font (Porson revival)
ii  fonts-hack                                    3.003-1                      all          Typeface designed for source code
ii  fonts-lato                                    2.0-2                        all          sans-serif typeface family font
ii  fonts-lmodern                                 2.004.5-5                    all          OpenType fonts based on Computer Modern
ii  fonts-noto                                    20171026-2                   all          metapackage to pull in all Noto fonts
ii  fonts-noto-cjk                                1:20170601+repack1-3         all          "No Tofu" font families with large Unicode coverage (CJK regular and bold)
ii  fonts-noto-hinted                             20171026-2                   all          "No Tofu" font families with large Unicode coverage (hinted)
ii  fonts-noto-mono                               20171026-2                   all          "No Tofu" monospaced font family with large Unicode coverage
ii  fonts-noto-unhinted                           20171026-2                   all          "No Tofu" font families with large Unicode coverage (unhinted)
ii  fonts-roboto-slab                             1.100263+20170512-1          all          Google's signature family of fonts (slab)
ii  fonts-texgyre                                 20180621-2                   all          OpenType fonts based on URW Fonts
ii  freetype2-doc                                 2.9.1-3                      all          FreeType 2 font engine, development documentation
ii  gsfonts                                       1:8.11+urwcyr1.0.7~pre44-4.4 all          Fonts for the Ghostscript interpreter(s)
ii  gucharmap                                     1:11.0.3-1                   amd64        Unicode character picker and font browser
ii  kbd                                           2.0.4-4                      amd64        Linux console font and keytable utilities
ii  libfont-afm-perl                              1.20-2                       all          Font::AFM - Interface to Adobe Font Metrics files
ii  libfontconfig1:amd64                          2.13.1-2                     amd64        generic font configuration library - runtime
ii  libfontconfig1-dev:amd64                      2.13.1-2                     amd64        generic font configuration library - development
ii  libfontenc1:amd64                             1:1.1.3-1+b2                 amd64        X11 font encoding library
ii  libfreetype6:amd64                            2.9.1-3                      amd64        FreeType 2 font engine, shared library files
ii  libfreetype6-dev:amd64                        2.9.1-3                      amd64        FreeType 2 font engine, development files
ii  libgraphite2-3:amd64                          1.3.12-1                     amd64        Font rendering engine for Complex Scripts -- library
ii  libkfontinst5                                 4:5.14.3-1                   amd64        Tools and widgets for the desktop library
ii  libkfontinstui5                               4:5.14.3-1                   amd64        Tools and widgets for the desktop library
ii  libotf0:amd64                                 0.9.13-4                     amd64        Library for handling OpenType Font - runtime
ii  libsdl-ttf2.0-0:amd64                         2.0.11-5                     amd64        TrueType Font library for Simple DirectMedia Layer 1.2, libraries
ii  libsdl2-ttf-2.0-0:amd64                       2.0.14+dfsg1-3               amd64        TrueType Font library for Simple DirectMedia Layer 2, libraries
ii  libwoff1:amd64                                1.0.2-1                      amd64        library for converting fonts to WOFF 2.0
ii  libxfont2:amd64                               1:2.0.3-1                    amd64        X11 font rasterisation library
ii  libxft-dev:amd64                              2.3.2-2                      amd64        FreeType-based font drawing library for X (development files)
ii  libxft2:amd64                                 2.3.2-2                      amd64        FreeType-based font drawing library for X
ii  lmodern                                       2.004.5-5                    all          scalable PostScript and OpenType fonts based on Computer Modern
ii  t1utils                                       1.41-2                       amd64        Collection of simple Type 1 font manipulation programs
ii  tex-gyre                                      20180621-2                   all          scalable PostScript and OpenType fonts based on URW Fonts
ii  texlive-fonts-recommended                     2018.20181116-1              all          TeX Live: Recommended fonts
ii  timgm6mb-soundfont                            1.3-2                        all          TimGM6mb SoundFont from MuseScore 1.3
ii  xfonts-100dpi                                 1:1.0.4+nmu1                 all          100 dpi fonts for X
ii  xfonts-75dpi                                  1:1.0.4+nmu1                 all          75 dpi fonts for X
ii  xfonts-base                                   1:1.0.4+nmu1                 all          standard fonts for X
ii  xfonts-encodings                              1:1.0.4-2                    all          Encodings for X.Org fonts
ii  xfonts-scalable                               1:1.0.3-1.1                  all          scalable fonts for X
ii  xfonts-utils                                  1:7.7+6                      amd64        X Window System font utility programs

-------------------------------------------8<-------------------------------------

I find gucharmap (a GTK+ application) extraordinarily helpful in
figuring out which of the system fonts that fontconfig will select for
*any* unicode glyph.  I highly recommend that you install that package
and use it since it should be able to quickly find out independent of
PLplot if fontconfig is working properly on your system.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Qt5 support, strange driver output

[António R. T. <ar...@gm...>]

Hi all
after trying a long time playing with cmake options trying to see if I
could get my qt5 plplot loading suitable f fonts I came to conclude that my
distribution in a way acts differently from Alan's.
I get very nice results if in the file plqt.cpp line 182
where is
    f.setFamily(""); // no family name, forcing Qt to find an appropriate
font by itself

I replaced by
   f.setFamily("Helvetica"); // no family name, forcing Qt to find an
appropriate font by itself

it seems in my system qt does not find an appropriate font by itsel. I
attach the very nice results obtained only by performed this small change.

cheers,




On Sat, Dec 15, 2018 at 9:38 PM António Rodrigues Tomé <ar...@gm...>
wrote:

> Hi all,
>
> This seems to be a truetype font issue my plots were  made without true
> type support. I noticed the difference between Alan plots and mine were not
> only in position and orientation but also in fonts used.
> I have a lot of true types fonts installed but for strange reason none is
> selected.
> only with a package free-ttf-fonts they are selected. result in attach.
> the text orientation is corrected but not the vertical displacement.
>
>
>
> On Sat, Dec 15, 2018 at 4:29 PM António Rodrigues Tomé <ar...@gm...>
> wrote:
>
>> Hi Alan
>> this is indeed very strange.
>> here the result of uname -a
>> 4.12.14-lp150.12.28-default #1 SMP Mon Dec 3 16:46:15 UTC 2018 (b91289f)
>> x86_64 x86_64 x86_64 GNU/Linux
>>
>> My distribution is opensuse leap 15.0
>> and my qt is 5.12.0
>>
>> (although i had exactly the same result with 5.11 as i've tested it a few
>> weeks ago)
>>
>> just built again with your cmake suggestion and the results are exactly
>> the same as before.
>> I'l try to get an hand during next week on a computer with a different
>> linux distribution just for testing.
>>
>> cheers,
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Dec 14, 2018 at 11:41 PM Alan W. Irwin <
>> Ala...@gm...> wrote:
>>
>>> On 2018-12-12 15:24-0000 António Rodrigues Tomé wrote:
>>>
>>> > Hi Alan,
>>> > now that 5.14 is out I would like to be more useful in solving the qt5
>>> > driver problem. However I do not complete understand the driver system
>>> to
>>> > be of big help.However for me I found a work arround that seems to work
>>> > quite well. I send you 4 files, output of x01 example using qt driver,
>>> png
>>> > and pdf)  the ones with Realease in name were created by the actual qt
>>> > driver version 5.14 that I constructed with the command
>>> > cmake -DCMAKE_INSTALL_PREFIX=/home/artome/plplot/PLPLOTNEW/
>>> > -DDEFAULT_NO_CAIRO_DEVICES=ON  -DDEFAULT_NO_QT_DEVICES=OFF
>>> DENABLE_cxx=ON
>>> > -DPL_DOUBLE=ON -DPLPLOT_USE_QT5=ON DEFAULT_NO_BINDINGS=ON    ../ >&
>>> > cmake.out
>>>
>>> Hi António:
>>>
>>> Please keep this discussion thread on list.
>>>
>>> I think it would be better style (and also I think -DBUILD_TEST=ON is
>>> essential)
>>> to use instead
>>> cmake -DCMAKE_INSTALL_PREFIX=/home/artome/plplot/PLPLOTNEW/
>>> -DBUILD_TEST=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_cxx=ON -DENABLE_qt=ON
>>> -DPLPLOT_USE_QT5=ON -DDEFAULT_NO_CAIRO_DEVICES:BOOL=ON ../ >& cmake.out
>>>
>>> I just tried all those options here (except for your
>>> -DCMAKE_INSTALL_PREFIX), and they worked fine,
>>> i.e., eliminated all bindings other than cxx and qt, dropped the cairo
>>> devices, and included
>>> all qt devices (which happens by default if -DENABLE_qt=ON).
>>>
>>> What is your exact platform (I think it might still be opensuse, but
>>> what version?) and what are the results of the "uname -a" command on that
>>> platform?  Also, what is the version of Qt5 that you are using?
>>>
>>> The reason these details are important is I cannot replicate the text
>>> alignment issues you demonstrated with pdfqt and pngqt results for
>>> example one on your platform.  My platform is Debian Buster (with the
>>> Qt5 5.11.2 suite of libraries) installed on AMD64 hardware (Ryzen 7
>>> 1700).  I demonstrated that I cannot replicate your badly aligned
>>> results by configuring cmake in the way I described above and then
>>> executing the following commands:
>>>
>>> # Build the prerequisites for the specific examples below
>>> make -j16 test_c_pngqt
>>> make -j16 test_c_pdfqt
>>>
>>> # Build two specific examples
>>> examples/c/x01c -dev pngqt -o test.pngqt
>>> examples/c/x01c -dev pdfqt -o test.pdfqt
>>>
>>> I have attached those two result files so you can see for yourself that
>>> there are no text
>>> alignment issues.
>>>
>>> Also your suggested changes to plqt.cpp likely conflate two issues.  (i)
>>> alignment issues caused
>>> by your platform and not PLplot, and (ii) the size of the resulting
>>> characters (which I
>>> would prefer to put off discussing until later).  So to check those are
>>> two separate issues,
>>> what happens if you restore plqt.cpp to its original form except for
>>> this one line change:
>>>
>>> PLDLLIMPEXP_QT_DATA( int ) vectorize = 0;
>>> ==>
>>> PLDLLIMPEXP_QT_DATA( int ) vectorize = 1;
>>>
>>> ?  I am pretty sure that is the equivalent of the first part of your
>>> change where you
>>> are forcing the vectorize part of the code to be executed.
>>>
>>> If that one-line change is all you need to bypass your Qt5 platform
>>> issues, then I would be willing to test that simple change here to see
>>> if it also works on my platform.  But the vectorize = 1 code path has
>>> not been tested by anybody but you over the years and is just likely a
>>> workaround for your Qt5 platform issue so I likely won't push that
>>> one-line change in general.
>>>
>>> Also you do appear to be having text alignment troubles consistently
>>> over the years with your (opensuse?) Qt5 platforms so perhaps it is
>>> time to try other Qt5 platforms?  For example, you could build the
>>> upstream version of Qt5 yourself.  The very early versions of Qt5 did
>>> have character alignment difficulties in that upstream version, but my
>>> experiments showed they solved the alignment issues important to
>>> PLplot by 5.3.x so you will likely find the latest upstream Qt5 also
>>> does not have text alignment issues.  And if that is the case, then
>>> that experiment should be the basis of a bug report to your
>>> distribution.  Of course, if that bug report gets no response another
>>> possibility is to try Debian (which I know works well now with Qt5)
>>> some Debian derivative such as Ubuntu or Mint or some other rpm-based
>>> distribution such as Fedora.
>>>
>>> Good luck, and let me know how it goes.
>>>
>>> Alan
>>> __________________________
>>> Alan W. Irwin
>>>
>>> Programming affiliations with the FreeEOS equation-of-state
>>> implementation for stellar interiors (freeeos.sf.net); the Time
>>> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
>>> software package (plplot.sf.net); the libLASi project
>>> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
>>> and the Linux Brochure Project (lbproject.sf.net).
>>> __________________________
>>>
>>> Linux-powered Science
>>> __________________________
>>
>>
>>
>> --
>>
>> António Rodrigues Tomé
>> Universidade da Beira Interior
>> Instituto D. Luís (lab associado)
>> email address:
>> ar...@gm...
>> ar...@ub...
>> http://www.researcherid.com/rid/A-5681-2013
>>
>>
>
> --
>
> António Rodrigues Tomé
> Universidade da Beira Interior
> Instituto D. Luís (lab associado)
> email address:
> ar...@gm...
> ar...@ub...
> http://www.researcherid.com/rid/A-5681-2013
>
>

-- 

António Rodrigues Tomé
Universidade da Beira Interior
Instituto D. Luís (lab associado)
email address:
ar...@gm...
ar...@ub...
http://www.researcherid.com/rid/A-5681-2013

Re: [Plplot-devel] Qt5 support, strange driver output

[António R. T. <ar...@gm...>]

Hi all,

This seems to be a truetype font issue my plots were  made without true
type support. I noticed the difference between Alan plots and mine were not
only in position and orientation but also in fonts used.
I have a lot of true types fonts installed but for strange reason none is
selected.
only with a package free-ttf-fonts they are selected. result in attach. the
text orientation is corrected but not the vertical displacement.



On Sat, Dec 15, 2018 at 4:29 PM António Rodrigues Tomé <ar...@gm...>
wrote:

> Hi Alan
> this is indeed very strange.
> here the result of uname -a
> 4.12.14-lp150.12.28-default #1 SMP Mon Dec 3 16:46:15 UTC 2018 (b91289f)
> x86_64 x86_64 x86_64 GNU/Linux
>
> My distribution is opensuse leap 15.0
> and my qt is 5.12.0
>
> (although i had exactly the same result with 5.11 as i've tested it a few
> weeks ago)
>
> just built again with your cmake suggestion and the results are exactly
> the same as before.
> I'l try to get an hand during next week on a computer with a different
> linux distribution just for testing.
>
> cheers,
>
>
>
>
>
>
>
>
>
> On Fri, Dec 14, 2018 at 11:41 PM Alan W. Irwin <Ala...@gm...>
> wrote:
>
>> On 2018-12-12 15:24-0000 António Rodrigues Tomé wrote:
>>
>> > Hi Alan,
>> > now that 5.14 is out I would like to be more useful in solving the qt5
>> > driver problem. However I do not complete understand the driver system
>> to
>> > be of big help.However for me I found a work arround that seems to work
>> > quite well. I send you 4 files, output of x01 example using qt driver,
>> png
>> > and pdf)  the ones with Realease in name were created by the actual qt
>> > driver version 5.14 that I constructed with the command
>> > cmake -DCMAKE_INSTALL_PREFIX=/home/artome/plplot/PLPLOTNEW/
>> > -DDEFAULT_NO_CAIRO_DEVICES=ON  -DDEFAULT_NO_QT_DEVICES=OFF
>> DENABLE_cxx=ON
>> > -DPL_DOUBLE=ON -DPLPLOT_USE_QT5=ON DEFAULT_NO_BINDINGS=ON    ../ >&
>> > cmake.out
>>
>> Hi António:
>>
>> Please keep this discussion thread on list.
>>
>> I think it would be better style (and also I think -DBUILD_TEST=ON is
>> essential)
>> to use instead
>> cmake -DCMAKE_INSTALL_PREFIX=/home/artome/plplot/PLPLOTNEW/
>> -DBUILD_TEST=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_cxx=ON -DENABLE_qt=ON
>> -DPLPLOT_USE_QT5=ON -DDEFAULT_NO_CAIRO_DEVICES:BOOL=ON ../ >& cmake.out
>>
>> I just tried all those options here (except for your
>> -DCMAKE_INSTALL_PREFIX), and they worked fine,
>> i.e., eliminated all bindings other than cxx and qt, dropped the cairo
>> devices, and included
>> all qt devices (which happens by default if -DENABLE_qt=ON).
>>
>> What is your exact platform (I think it might still be opensuse, but what
>> version?) and what are the results of the "uname -a" command on that
>> platform?  Also, what is the version of Qt5 that you are using?
>>
>> The reason these details are important is I cannot replicate the text
>> alignment issues you demonstrated with pdfqt and pngqt results for
>> example one on your platform.  My platform is Debian Buster (with the
>> Qt5 5.11.2 suite of libraries) installed on AMD64 hardware (Ryzen 7
>> 1700).  I demonstrated that I cannot replicate your badly aligned
>> results by configuring cmake in the way I described above and then
>> executing the following commands:
>>
>> # Build the prerequisites for the specific examples below
>> make -j16 test_c_pngqt
>> make -j16 test_c_pdfqt
>>
>> # Build two specific examples
>> examples/c/x01c -dev pngqt -o test.pngqt
>> examples/c/x01c -dev pdfqt -o test.pdfqt
>>
>> I have attached those two result files so you can see for yourself that
>> there are no text
>> alignment issues.
>>
>> Also your suggested changes to plqt.cpp likely conflate two issues.  (i)
>> alignment issues caused
>> by your platform and not PLplot, and (ii) the size of the resulting
>> characters (which I
>> would prefer to put off discussing until later).  So to check those are
>> two separate issues,
>> what happens if you restore plqt.cpp to its original form except for this
>> one line change:
>>
>> PLDLLIMPEXP_QT_DATA( int ) vectorize = 0;
>> ==>
>> PLDLLIMPEXP_QT_DATA( int ) vectorize = 1;
>>
>> ?  I am pretty sure that is the equivalent of the first part of your
>> change where you
>> are forcing the vectorize part of the code to be executed.
>>
>> If that one-line change is all you need to bypass your Qt5 platform
>> issues, then I would be willing to test that simple change here to see
>> if it also works on my platform.  But the vectorize = 1 code path has
>> not been tested by anybody but you over the years and is just likely a
>> workaround for your Qt5 platform issue so I likely won't push that
>> one-line change in general.
>>
>> Also you do appear to be having text alignment troubles consistently
>> over the years with your (opensuse?) Qt5 platforms so perhaps it is
>> time to try other Qt5 platforms?  For example, you could build the
>> upstream version of Qt5 yourself.  The very early versions of Qt5 did
>> have character alignment difficulties in that upstream version, but my
>> experiments showed they solved the alignment issues important to
>> PLplot by 5.3.x so you will likely find the latest upstream Qt5 also
>> does not have text alignment issues.  And if that is the case, then
>> that experiment should be the basis of a bug report to your
>> distribution.  Of course, if that bug report gets no response another
>> possibility is to try Debian (which I know works well now with Qt5)
>> some Debian derivative such as Ubuntu or Mint or some other rpm-based
>> distribution such as Fedora.
>>
>> Good luck, and let me know how it goes.
>>
>> Alan
>> __________________________
>> Alan W. Irwin
>>
>> Programming affiliations with the FreeEOS equation-of-state
>> implementation for stellar interiors (freeeos.sf.net); the Time
>> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
>> software package (plplot.sf.net); the libLASi project
>> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
>> and the Linux Brochure Project (lbproject.sf.net).
>> __________________________
>>
>> Linux-powered Science
>> __________________________
>
>
>
> --
>
> António Rodrigues Tomé
> Universidade da Beira Interior
> Instituto D. Luís (lab associado)
> email address:
> ar...@gm...
> ar...@ub...
> http://www.researcherid.com/rid/A-5681-2013
>
>

-- 

António Rodrigues Tomé
Universidade da Beira Interior
Instituto D. Luís (lab associado)
email address:
ar...@gm...
ar...@ub...
http://www.researcherid.com/rid/A-5681-2013