plplot-general — PLplot user discussion group

Re: [Plplot-general] Function for format data with 2 or more digital numbers after point

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

On 2018-10-14 14:43-0000 Sergej Scherbina wrote:

> Hi!
>
> If we should use several numbers after point for Y axis what to use for solving this task?
> Thanks  for the help.

Hi Sergey:

Take a look at
<http://plplot.org/docbook-manual/plplot-html-5.13.0/viewport_window.html#annotation>.
The references there to how to set digmax individually for each axis
should help to answer your question.

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-general] Function for format data with 2 or more digital numbers after point

[Sergej S. <no...@ro...>]

Hi!

If we should use several numbers after point for Y axis what to use for solving this task? 
Thanks  for the help. 

  plbox( "bcnstd", 0.0 , 0.0, "bcnstv", 0.0, 0.0 );
  plcol0( 1 );
  pllab( titleX, titleY, title );
  plcol0( 4 ); //- color 03
  //plprec( 0, 0 );
  //plfmt( "%6.2f" );
  plline( NumInpData, FloatDate, FloatData );


Reagrds,
Sergey.

Re: [Plplot-general] Problem building on Linux

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

On 2018-09-12 19:46+0100 Phil Rosenberg wrote:

> Hi Alan
> I think I have fixed it. In fact it turned out that test-drv-info was
> doing exactly what it should.
>
> running ldd on the wxwidgets.so file revealed 3 dependencies that
> could not be found.

> The flavour of Linux I am building on is Arch,
> which maintains rolling upgrades of all packages rather than fixed
> update releases. Since the last wxWidgets release on Arch, the three
> dependencies had all upgraded with new ABIs. I built wxWidgets from
> source and now everything is working as it should.

Hi Phil:

I am glad to hear you have apparently solved this library inconsistency
problem.

Debian Testing = Buster and MinGW-w64/MSYS2 are also examples of
rolling releases.  For all of those and assuming there was no
packaging error (e.g.,, a mistatement of dependencies), a distribution
update should only update dependencies if system libraries and
executables (e.g., from wxwidgets) were updated in a consistent way
with those dependencies.  I have been using Debian for almost two
decades now, and in that time I have never noticed any such
inconsistency issue, and I suspect such issues are rare for the
ArchLinux as well since it has such a good reputation.  So perhaps the
ArchLinux system version of wxwidgets was fine with the updated
dependencies, and the trouble was only with your own built version of
wxwidgets?

>From Arjen's experience with MinGW-w64/MSYS2, that is one distribution
where you should expect some inconsistency issues.  The problem is the
developers of that distribution have a very small team with limited
resources, and they appear not to realize how smooth the user
experience should be with rolling releases.  I assume that is because
they don't realize Debian and other Linux distributions have set such
a high standard for rolling releases.  My hope is the MinGW-w64/MSYS2
development team will soon figure it out so that distribution becomes
as smooth as the other high-quality rolling releases.

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-general] Problem building on Linux

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

Hi Alan
I think I have fixed it. In fact it turned out that test-drv-info was
doing exactly what it should.

running ldd on the wxwidgets.so file revealed 3 dependencies that
could not be found. The flavour of Linux I am building on is Arch,
which maintains rolling upgrades of all packages rather than fixed
update releases. Since the last wxWidgets release on Arch, the three
dependencies had all upgraded with new ABIs. I built wxWidgets from
source and now everything is working as it should.

The lightbulb moment was realising that the function called in
test-drv-info opens the requested library plus all its dependencies.
On Tue, 11 Sep 2018 at 23:19, Alan W. Irwin <Ala...@gm...> wrote:
>
> On 2018-09-11 20:07+0100 Phil Rosenberg wrote:
>
> > Hi Alan
> > I just wanted to let you know that your recent commit seems to have fixed all
> > the strange output I was getting at the end of my cmake command.
>
> Hi Phil:
>
> I was very happy to receive that encouraging news concerning all the build-system
> improvements I have been doing.
>
> >
> > I am still getting a build arror though
> > Generating test_dyndrivers_dir/wxwidgets.driver_info
> > Could not open driver module
> > /home/users/prosenberg01/junest/src/plplot-plplot/build/drivers/wxwidgets
> > libltdl error: file not found
> >
> >
> > This comes down to the execution of an execuatable
> > <build_dir>/drivers/test-drv-info. It is run as follows
> > ./test-drv-info "" wxwidgets
> > and it retuns an error, saying could not open driver module
> > <build_dir>/drivers/wxwidgets
> >
> > I've found that test-drv-info is an executable built by plplot. It
> > uses the function lt_dlopenext to open the drivers and then extract
> > some symbols. From what I can tell from the source the lt_dlopenext
> > function returns null indicating the file did not exist or could not
> > be opened. The relevant file (wxwidgets.so) is definitely there, so I
> > guess there must be some reason why it cannot be opened.
> >
> > I'm at a complete loss now as this is beyond my linux knowledge - any
> > suggestions?
>
> The test-drv-info application was implemented long ago to test at
> build time whether our dynamic devices would load properly.  But
> sometimes on Windows (but never on Linux) test-drv-info would say the
> device could not be loaded properly, but the equivalent code to
> dynamically load a device in the PLplot core library would work fine!
> But our Windows developers could never figure out that discrepancy
> between the two results.
>
> Anyhow, you *might* have run into this case yet again.  So to check
> that specify -DTEST_DYNDRIVERS=OFF (which will drop the build-time
> test).  That should let you build everything without problems, but, of
> course, you should test that result at run-time to make sure the
> equivalent code in the core library works, i.e., by specifying -dev
> wxwidgets for some run-time test.
>
> If that turns out to be the case, (i.e.,test-drv-info application does
> not work while equivalent core code does work), that is a useful
> workaround for you, but it would also be great in this case if you
> could figure out the fix required to make sure test-drv-info works
> *exactly* like the core code on your Windows platform so you don't
> have to use the workaround.
>
> 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-general] Problem building on Linux

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

On 2018-09-11 20:07+0100 Phil Rosenberg wrote:

> Hi Alan
> I just wanted to let you know that your recent commit seems to have fixed all
> the strange output I was getting at the end of my cmake command.

Hi Phil:

I was very happy to receive that encouraging news concerning all the build-system
improvements I have been doing.

>
> I am still getting a build arror though
> Generating test_dyndrivers_dir/wxwidgets.driver_info
> Could not open driver module
> /home/users/prosenberg01/junest/src/plplot-plplot/build/drivers/wxwidgets
> libltdl error: file not found
>
>
> This comes down to the execution of an execuatable
> <build_dir>/drivers/test-drv-info. It is run as follows
> ./test-drv-info "" wxwidgets
> and it retuns an error, saying could not open driver module
> <build_dir>/drivers/wxwidgets
>
> I've found that test-drv-info is an executable built by plplot. It
> uses the function lt_dlopenext to open the drivers and then extract
> some symbols. From what I can tell from the source the lt_dlopenext
> function returns null indicating the file did not exist or could not
> be opened. The relevant file (wxwidgets.so) is definitely there, so I
> guess there must be some reason why it cannot be opened.
>
> I'm at a complete loss now as this is beyond my linux knowledge - any
> suggestions?

The test-drv-info application was implemented long ago to test at
build time whether our dynamic devices would load properly.  But
sometimes on Windows (but never on Linux) test-drv-info would say the
device could not be loaded properly, but the equivalent code to
dynamically load a device in the PLplot core library would work fine!
But our Windows developers could never figure out that discrepancy
between the two results.

Anyhow, you *might* have run into this case yet again.  So to check
that specify -DTEST_DYNDRIVERS=OFF (which will drop the build-time
test).  That should let you build everything without problems, but, of
course, you should test that result at run-time to make sure the
equivalent code in the core library works, i.e., by specifying -dev
wxwidgets for some run-time test.

If that turns out to be the case, (i.e.,test-drv-info application does
not work while equivalent core code does work), that is a useful
workaround for you, but it would also be great in this case if you
could figure out the fix required to make sure test-drv-info works
*exactly* like the core code on your Windows platform so you don't
have to use the workaround.

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-general] Problem building on Linux

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

Hi Alan
I just wanted to let you know that your recent commit seems to have fixed all
the strange output I was getting at the end of my cmake command.

I am still getting a build arror though
Generating test_dyndrivers_dir/wxwidgets.driver_info
Could not open driver module
/home/users/prosenberg01/junest/src/plplot-plplot/build/drivers/wxwidgets
libltdl error: file not found


This comes down to the execution of an execuatable
<build_dir>/drivers/test-drv-info. It is run as follows
./test-drv-info "" wxwidgets
and it retuns an error, saying could not open driver module
<build_dir>/drivers/wxwidgets

I've found that test-drv-info is an executable built by plplot. It
uses the function lt_dlopenext to open the drivers and then extract
some symbols. From what I can tell from the source the lt_dlopenext
function returns null indicating the file did not exist or could not
be opened. The relevant file (wxwidgets.so) is definitely there, so I
guess there must be some reason why it cannot be opened.

I'm at a complete loss now as this is beyond my linux knowledge - any
suggestions?

[Plplot-general] Problem building on Linux

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

Hi all
I'm trying to build on linux for the first time in a long time. The
linux flavour I'm using is a stripped down version of Arch Linux. It
didn't even come with grep to start with so lots of packages have had
to be installed that you might expect to just be there, so maybe I am
missing some required package.
After the -- Configuring done output of cmake I got the following
scary looking output


CMake Error at cmake/modules/plplot_functions.cmake:234 (file):
  Error evaluating generator expression:

    $<TARGET_FILE:PLPLOT::plserver>

  No target "PLPLOT::plserver"
Call Stack (most recent call first):
  plplot_test/CMakeLists.txt:120 (configure_file_generate)


CMake Error at cmake/modules/plplot_functions.cmake:234 (file):
  Error evaluating generator expression:

    $<TARGET_FILE:PLPLOT::plserver>

  No target "PLPLOT::plserver"
Call Stack (most recent call first):
  plplot_test/CMakeLists.txt:120 (configure_file_generate)


CMake Error at cmake/modules/plplot_functions.cmake:234 (file):
  Error evaluating generator expression:

    $<TARGET_FILE:PLPLOT::plserver>

  No target "PLPLOT::plserver"
Call Stack (most recent call first):
  plplot_test/CMakeLists.txt:120 (configure_file_generate)


-- Generating done
-- Build files have been written to:
/home/users/prosenberg01/junest/src/plplot-plplot/build



I tried building anyway, but got this error from make all
[ 36%] Generating test_dyndrivers_dir/wxwidgets.driver_info
Could not open driver module
/home/users/prosenberg01/junest/src/plplot-plplot/build/drivers/wxwidgets
libltdl error: file not found
make[2]: *** [drivers/CMakeFiles/test_wxwidgets_dyndriver.dir/build.make:62:
drivers/test_dyndrivers_dir/wxwidgets.driver_info] Error 1
make[2]: *** Deleting file
'drivers/test_dyndrivers_dir/wxwidgets.driver_info'
make[1]: *** [CMakeFiles/Makefile2:2230:
drivers/CMakeFiles/test_wxwidgets_dyndriver.dir/all] Error 2
make: *** [Makefile:163: all] Error 2


I've attached my cmakecache too.


I'll try to hunt down the problem, but any hints would be appreciated.

Phil

Re: [Plplot-general] rgb colourscale interpolation

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

On 2018-07-26 14:15+0100 Phil Rosenberg wrote:

> I have just made the commits with the RGB interpolation. As far as I
> can tell the code all works fine, however I have had some problems
> with the documentation.
>
> It seems that prior to this commit the documentation build has become
> broken - at least for Cygwin. Would somebody be able to check it out
> on a Linux computer as I no longer have access to one.

The cause of this issie is likely some Cygwin package which you forgot
to install.  On my new Debian Buster system, I am also starting from
scratch with installation of documentation-related packages so I will
take you through what I had to install to get the the documentation
build to work.

For -DBUILD_DOC=ON the first set of documentation-related warnings
(from the cmake command output) were as follows:

-- WARNING: db2x_texixml not found
-- WARNING: db2x_xsltproc not found
-- WARNING: Not building info documentation - required programs are missing
-- WARNING: dblatex not found so not building print documentation

In your case, you should find the relevant packages containing those files
using <https://cygwin.com/cgi-bin2/package-grep.cgi>, but in my case I
used apt-file to do the same job.  I then iterated the configuration (starting
from an empty build directory), and all the above warnings were gone, but
for that second iteration I got this new warning from the cmake output:

-- WARNING: xelatex not found so not building print documentation

After installing the relevant package, the third iteration had no further
warnings concerning building the documentation.

I then validated the documentation (without your commmit being applied, yet) using

make validate

and all was well.

I then built all forms of the docbook-generated documentation using

make build_docbook_documentation

and that completed without any obvious errors.

I then tried the same thing with the latest master branch (including
your commmits), and got the same good validate and build results.
However, I haven't looked at your documentation rewordings, yet in the
final info, man, html, and print results because I am busy with
something else.  But I strongly urge you to do that following the same
generic steps as above so you can review the effect of your changes on
the resulting documentation and to demonstrate that the
documentation build works on Cygwin (if all relevant packages are
installed).

Of course, if you run into any trouble with the above steps, please give
me at least the CMakeCache.txt file and cmake and make output files, and
we can figure out together why the documentation build works on Linux, but
no longer works on Cygwin.

> Also Alan, would you like this change listed in the README.release? If
> so where exactly?

Yes, please.  I assume you will want to insert a paragraph concerning
your change in a new section 2.8 of "Improvements relative to the
previous release".  Also, since you changed the semantics of the two
functions (although not their API) for the RGB case you should
probably specifically warn the users of this forthcoming release about
that semantics change by adding a one-sentence new section 1.10 in
"OFFICIAL NOTICES FOR USERS" that refers to your new section 2.8 for
the details.

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-general] rgb colourscale interpolation

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

I have just made the commits with the RGB interpolation. As far as I
can tell the code all works fine, however I have had some problems
with the documentation.

It seems that prior to this commit the documentation build has become
broken - at least for Cygwin. Would somebody be able to check it out
on a Linux computer as I no longer have access to one.

Also Alan, would you like this change listed in the README.release? If
so where exactly?

Phil

On 25 July 2018 at 18:22, Alan W. Irwin <Ala...@gm...> wrote:
> On 2018-07-25 10:13+0100 Phil Rosenberg wrote:
>
>> On 24 July 2018 at 20:19, Alan W. Irwin <Ala...@gm...>
>> wrote:
>>>
>>> [.... O]one concern I have about the current documentation, is
>>> the documentation of the plscmap1la and plscmap1l alt_hue_path
>>> argument.  That argument makes a lot of sense in HLS space, but does
>>> it make any sense at all if you are doing all interpolation in RGB
>>> space?  That is, should that argument be completely ignored if you are
>>> using RGB space interpolation?
>>
>>
>> If I remember correctly, the point of alt_hue_path is specifically to
>> determine the direction around the colour wheel for interpolation once
>> the rgb values have been converted to hls. When supplying colours in
>> hls space, you can specify the direction by using hue values outside
>> the range of 0-360, for example specifying the two hues 0 and 240
>> would go from red to blue via yellow, green and cyan, whereas
>> specifying the two hues 0 and -120 would go from red to blue via
>> magenta. However if you specify rgb colours [1,0,0] and [0,0,1] then
>> you can use the alt_hue_path to tell plplot to interpolat backwards
>> round the colour wheel.
>
>
> Hi Phil:
>
> I believe your interpretation of what goes on with this argument for
> the HLS case is correct.
>
>> So moving to rgb interpolation for rgb values makes this variable
>> defunct really.
>
>
> I am pretty sure that is the case, but, of course, you should check for the
> RGB case in your update to the code that this argument is completely
> ignored.
>
>> I guess the best thing is to simply state this in the
>> documentation?
>
>
> Yes.
>
>> Can we deprecate it somehow and in a future release
>> remove it altogether?
>
>
> This would require splitting each of the current plscmap1l and
> plscmap1la functions into two in a backwards-incompatible way with one
> for the HLS case (where alt_hue_path would be in the argument list)
> and one for the RGB case (with no alt_hue_path in the argument list).
> Thus, I think our current C API is the best choice so long as you
> document that alt_hue_path is ignored for the RGB case.
>
>> I have made the code changes and am about to test them. I will then
>> make the documentation changes and commit the results today.
>
>
> I look forward to seeing that commit.
>
>
> 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-general] rgb colourscale interpolation

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

On 2018-07-25 10:13+0100 Phil Rosenberg wrote:

> On 24 July 2018 at 20:19, Alan W. Irwin <Ala...@gm...> wrote:
>> [.... O]one concern I have about the current documentation, is
>> the documentation of the plscmap1la and plscmap1l alt_hue_path
>> argument.  That argument makes a lot of sense in HLS space, but does
>> it make any sense at all if you are doing all interpolation in RGB
>> space?  That is, should that argument be completely ignored if you are
>> using RGB space interpolation?
>
> If I remember correctly, the point of alt_hue_path is specifically to
> determine the direction around the colour wheel for interpolation once
> the rgb values have been converted to hls. When supplying colours in
> hls space, you can specify the direction by using hue values outside
> the range of 0-360, for example specifying the two hues 0 and 240
> would go from red to blue via yellow, green and cyan, whereas
> specifying the two hues 0 and -120 would go from red to blue via
> magenta. However if you specify rgb colours [1,0,0] and [0,0,1] then
> you can use the alt_hue_path to tell plplot to interpolat backwards
> round the colour wheel.

Hi Phil:

I believe your interpretation of what goes on with this argument for
the HLS case is correct.

> So moving to rgb interpolation for rgb values makes this variable
> defunct really.

I am pretty sure that is the case, but, of course, you should check for the
RGB case in your update to the code that this argument is completely ignored.

> I guess the best thing is to simply state this in the
> documentation?

Yes.

> Can we deprecate it somehow and in a future release
> remove it altogether?

This would require splitting each of the current plscmap1l and
plscmap1la functions into two in a backwards-incompatible way with one
for the HLS case (where alt_hue_path would be in the argument list)
and one for the RGB case (with no alt_hue_path in the argument list).
Thus, I think our current C API is the best choice so long as you
document that alt_hue_path is ignored for the RGB case.

> I have made the code changes and am about to test them. I will then
> make the documentation changes and commit the results today.

I look forward to seeing that commit.

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-general] rgb colourscale interpolation

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

On 24 July 2018 at 20:19, Alan W. Irwin <Ala...@gm...> wrote:
> On 2018-07-24 13:35-0000 Arjen Markus wrote:
>
>> Hi Phil,
>>
>>> -----Original Message-----
>>> From: Phil Rosenberg [mailto:p.d...@gm...]
>>>
>>> I feel that if someone provides colours in rgb values we really should
>>> interpolate in
>>> rgb values. Or at the very least we need to make it very clear in the
>>> documentation
>>> that we always interpolate in hls space even if colours are provided as
>>> rgb.
>>>
>>> Any thoughts?
>>>
>> I agree: if you specify the colours in RGB, then you are not interested in
>> the HLS colour space. Indeed it would be very awkward to select the RGB
>> coordinates in such a way that you get intermediate RGB colours, when the
>> interpolation is actually done in HLS.
>>
>> Maybe there are good reasons to do it like this, but then I sure would
>> like to hear them. I tend to think that it is simply an oversight.
>
>
> To Phil and Arjen:
>
> I agree as well.  The documentation at
> <http://plplot.org/docbook-manual/plplot-html-5.13.0/color.html#color-map-1>
> clearly implies that if you choose RGB, the interpolation is in that
> space, and the documentation of plscmap1la and plscmap1l implies the
> same.  However, one concern I have about the current documentation, is
> the documentation of the plscmap1la and plscmap1l alt_hue_path
> argument.  That argument makes a lot of sense in HLS space, but does
> it make any sense at all if you are doing all interpolation in RGB
> space?  That is, should that argument be completely ignored if you are
> using RGB space interpolation?

If I remember correctly, the point of alt_hue_path is specifically to
determine the direction around the colour wheel for interpolation once
the rgb values have been converted to hls. When supplying colours in
hls space, you can specify the direction by using hue values outside
the range of 0-360, for example specifying the two hues 0 and 240
would go from red to blue via yellow, green and cyan, whereas
specifying the two hues 0 and -120 would go from red to blue via
magenta. However if you specify rgb colours [1,0,0] and [0,0,1] then
you can use the alt_hue_path to tell plplot to interpolat backwards
round the colour wheel.

I think it is actually a side effect that it also reverses the
direction when using hls space.

So moving to rgb interpolation for rgb values makes this variable
defunct really. I guess the best thing is to simply state this in the
documentation? Can we deprecate it somehow and in a future release
remove it altogether?

I have made the code changes and am about to test them. I will then
make the documentation changes and commit the results today.


>
> Anyhow, if the code currently does not follow the documentation
> (subject to any small documentation changes relevant to the above
> concern), then I think it is an oversight, and my thanks to Phil for
> being willing to sort this all out.
>
> 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-general] rgb colourscale interpolation

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

On 2018-07-24 13:35-0000 Arjen Markus wrote:

> Hi Phil,
>
>> -----Original Message-----
>> From: Phil Rosenberg [mailto:p.d...@gm...]
>>
>> I feel that if someone provides colours in rgb values we really should interpolate in
>> rgb values. Or at the very least we need to make it very clear in the documentation
>> that we always interpolate in hls space even if colours are provided as rgb.
>>
>> Any thoughts?
>>
> I agree: if you specify the colours in RGB, then you are not interested in the HLS colour space. Indeed it would be very awkward to select the RGB coordinates in such a way that you get intermediate RGB colours, when the interpolation is actually done in HLS.
>
> Maybe there are good reasons to do it like this, but then I sure would like to hear them. I tend to think that it is simply an oversight.

To Phil and Arjen:

I agree as well.  The documentation at
<http://plplot.org/docbook-manual/plplot-html-5.13.0/color.html#color-map-1>
clearly implies that if you choose RGB, the interpolation is in that
space, and the documentation of plscmap1la and plscmap1l implies the
same.  However, one concern I have about the current documentation, is
the documentation of the plscmap1la and plscmap1l alt_hue_path
argument.  That argument makes a lot of sense in HLS space, but does
it make any sense at all if you are doing all interpolation in RGB
space?  That is, should that argument be completely ignored if you are
using RGB space interpolation?

Anyhow, if the code currently does not follow the documentation
(subject to any small documentation changes relevant to the above
concern), then I think it is an oversight, and my thanks to Phil for
being willing to sort this all out.

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-general] rgb colourscale interpolation

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

I can confirm that it is definitely awkward to interpolate in RGB space and then correctly set the direction parameter to avoid wierd interpolation effects by going the wrong way round the colour wheel. I've just spent the time since I sent the first email trying to do it and now my head hurts, I've given up and in true British style I've gone and made myself a cup of tea :-D

If the consensus is as Arjen and I see it then I'll make the required changes asap.

Phil

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



From: Arjen Markus
Sent: Tuesday, 24 July, 14:35
Subject: RE: [Plplot-general] rgb colourscale interpolation
To: Phil Rosenberg, plplot_general


Hi Phil, > -----Original Message----- > From: Phil Rosenberg [mailto:p.d...@gm...] > > I feel that if someone provides colours in rgb values we really should interpolate in > rgb values. Or at the very least we need to make it very clear in the documentation > that we always interpolate in hls space even if colours are provided as rgb. > > Any thoughts? > I agree: if you specify the colours in RGB, then you are not interested in the HLS colour space. Indeed it would be very awkward to select the RGB coordinates in such a way that you get intermediate RGB colours, when the interpolation is actually done in HLS. Maybe there are good reasons to do it like this, but then I sure would like to hear them. I tend to think that it is simply an oversight. Regards, Arjen DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

Re: [Plplot-general] rgb colourscale interpolation

[Arjen M. <Arj...@de...>]

Hi Phil,

> -----Original Message-----
> From: Phil Rosenberg [mailto:p.d...@gm...]
>
> I feel that if someone provides colours in rgb values we really should interpolate in
> rgb values. Or at the very least we need to make it very clear in the documentation
> that we always interpolate in hls space even if colours are provided as rgb.
>
> Any thoughts?
>
I agree: if you specify the colours in RGB, then you are not interested in the HLS colour space. Indeed it would be very awkward to select the RGB coordinates in such a way that you get intermediate RGB colours, when the interpolation is actually done in HLS.

Maybe there are good reasons to do it like this, but then I sure would like to hear them. I tend to think that it is simply an oversight.

Regards,

Arjen
DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

[Plplot-general] rgb colourscale interpolation

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

Hi All
Somehow I feel like we may have had this discussion before, but I'm not sure.

If I call plscmap1l or plscmap1la using rgb colours, then these
colours are converted to hls colours and interpolated in hls space,
this is counter to what I might expect and not documented.

So for example I just tried to do a plot with a colourscale going from
red to blue specifying rgb colours. So I expected it to give me a
colourscale going from red, through shades of purple to blue. But
instead I got a rainbow colour scheme as the interpolation in hls
space goes round the colour wheel.

I feel that if someone provides colours in rgb values we really should
interpolate in rgb values. Or at the very least we need to make it
very clear in the documentation that we always interpolate in hls
space even if colours are provided as rgb.

Any thoughts?

Phil

Re: [Plplot-general] Your web-pages helped me with plbox3.

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

On 2018-06-30 10:26-0000 Sergej Scherbina wrote:

> Dear Alan,
>
> Your last letter helped me to understand what was incorrect in my C code.
>
> I used these your web-pages
>
> 1) http://plplot.org/docbook-manual/plplot-html-5.13.0/tri-d-plots.html
>
> 2) http://plplot.org/docbook-manual/plplot-html-5.13.0/plbox3.html
>
> and the problem is solved! See it in attached PDF file.
>
> What I used incorrectly in function plbox3 :
>
> plbox3( "b <!d!> nstu", "Time", 0.0, 0,"bnstu", "Freq", 0.0, 0,"bcdmnstuv", Yaxis, 0.0, 0 );
>
> I hope you won't worry about your excellent function plbox3 again!

Hi Sergey:

Glad our documentation was able to help you figure out the problem.

> PS.
>
> 1) How to draw all them in Black&White regime?
>
> 2) Where is an example how to draw 3D plot in 2D projection with B&W isolines?
>
> I use it here - http://194.44.29.164/WebPageForForecast00.html

It appears what you want is black lines (and text) on a white
background.  These are discrete colours (as opposed to continuous) so
it is simply a matter of setting up the PLplot discrete colour mapping
(cmap0) correctly.  Likely the simplest way of doing that is what was
used for page 1 of example 16, namely a call to

plspal0( "cmap0_black_on_white.pal" );

"cmap0_black_on_white.pal" is one of our useful internal cmap0 colour style
files, but you can also make and use your own such file.

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-general] Your web-pages helped me with plbox3.

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

P.S. For more information about how to control the colour of your
plots with PLplot, see
<http://plplot.org/docbook-manual/plplot-html-5.13.0/color.html>.

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-general] 3D PLplot with time 2018-06-28 12:47:02

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

On 2018-06-28 13:45-0000 Sergej Scherbina wrote:

> Hi!
>
> What should be changed for normal form of time in function plbox3 for 3D plot:
>
> 	1) plbox3( "bnstu", "Time", 0.0, 0,"bnstu", "Freq", 0.0, 0,"bcdmnstuv", Yaxis, 0.0, 0 );
>        or
> 	2) plbox3( "bcnstd", "Time", 0.0, 0,"bnstu", "Freq", 0.0, 0,"bcdmnstdv", Yaxis, 0.0, 0 );
>
> Both my attempts gave  bad form of time - integer numbers.

Hi Sergey:

The combined used of time options and plbox is well tested by examples
in our test suite, but the combination of time options and *plbox3* is
currently not tested by any example in our test suite.  So it is
possible there is some PLplot bug to fix here.  However, your first
call above of plbox3 has nothing to do with the time option since that
option is "d" for xopt and yopt, but "e" for zopt (for the reason
mentioned at
<http://plplot.org/docbook-manual/plplot-html-5.13.0/plbox3.html>.

Your second call of plbox3 above does specify a time option for xopt
(but not yopt or zopt).  But for that case, the trouble may be caused
by how you set up your time environment rather than a PLplot bug.  So
could you please follow up by sending us the simplest self-contained
example of the time option being used for one of (or all of) xopt,
yopt, and zopt for plbox3 that we can build and run for ourselves to
help us figure out whether it is a PLplot bug or something else
that is going wrong for you?

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-general] 3D PLplot with time 2018-06-28 12:47:02

[Sergej S. <no...@ro...>]

Hi!

What should be changed for normal form of time in function plbox3 for 3D plot: 

	1) plbox3( "bnstu", "Time", 0.0, 0,"bnstu", "Freq", 0.0, 0,"bcdmnstuv", Yaxis, 0.0, 0 );
        or 
	2) plbox3( "bcnstd", "Time", 0.0, 0,"bnstu", "Freq", 0.0, 0,"bcdmnstdv", Yaxis, 0.0, 0 );

Both my attempts gave  bad form of time - integer numbers.

Regards,
Sergey.

Re: [Plplot-general] Building PLplot with pngcairo driver

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

On 2018-06-27 16:21+0100 W. Miah wrote:

> Hi,
>
> I am trying to build PLplot with pngcairo driver and I have the following
> RPMs installed:
>
> # rpm -qa | grep png
> texlive-dvipng-20170520-37.fc28.x86_64
> libpng-1.6.34-3.fc28.x86_64
> libpng-devel-1.6.34-3.fc28.x86_64
> libpng12-1.2.57-5.fc28.x86_64
>
> # rpm -qa | grep cairo
> python3-cairo-1.16.3-1.fc28.x86_64
> cairo-devel-1.15.12-2.fc28.x86_64
> cairomm-1.12.0-7.fc28.x86_64
> cairo-1.15.12-2.fc28.x86_64
> python2-cairo-1.16.3-1.fc28.x86_64
> cairomm-devel-1.12.0-7.fc28.x86_64
> cairo-gobject-1.15.12-2.fc28.x86_64
>
> However, when I type cmake, it does not list cairo/png:
>
> $ cmake ..
> ENABLE_DYNDRIVERS:    OFF
> DRIVERS_LIST: mem;null;ps;svg;xfig;xwin
> DEVICES_LIST: mem;null;ps;svg;xfig;xwin
>
> Any help will be greatly appreciated.

Hi Wadud:

The "cairo" PLplot device driver (which implements the pngcairo PLplot
device and others) is a bit of a misnomer since it depends on both
the pango AND cairo subset of the GTK+ suite of libraries.  So my guess is
your issue will be solved if you install the development version of
the pango library package.

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-general] Building PLplot with pngcairo driver

[W. M. <wad...@gm...>]

Hi,

I am trying to build PLplot with pngcairo driver and I have the following
RPMs installed:

# rpm -qa | grep png
texlive-dvipng-20170520-37.fc28.x86_64
libpng-1.6.34-3.fc28.x86_64
libpng-devel-1.6.34-3.fc28.x86_64
libpng12-1.2.57-5.fc28.x86_64

# rpm -qa | grep cairo
python3-cairo-1.16.3-1.fc28.x86_64
cairo-devel-1.15.12-2.fc28.x86_64
cairomm-1.12.0-7.fc28.x86_64
cairo-1.15.12-2.fc28.x86_64
python2-cairo-1.16.3-1.fc28.x86_64
cairomm-devel-1.12.0-7.fc28.x86_64
cairo-gobject-1.15.12-2.fc28.x86_64

However, when I type cmake, it does not list cairo/png:

$ cmake ..
ENABLE_DYNDRIVERS:    OFF
DRIVERS_LIST: mem;null;ps;svg;xfig;xwin
DEVICES_LIST: mem;null;ps;svg;xfig;xwin

Any help will be greatly appreciated.

Cheers,
Wadud.

-- 
web: http://miahw.wordpress.com
mobile: +447905 755604
gpg: BDFB 2E29 B22F

Re: [Plplot-general] plplot-wxwidgets-plotting

[David B. <stu...@gm...>]

Phil,

Thanks for your help.  I just tried both suggestions and the use of 
wxSize(800, 800) forked but the suggestion below did not.

I will try and forge ahead but I had ran into an issue with nested 
splitter windows not resizing correctly and the wxWidgets community 
suggested fix was to never use wxSize, always use default, i.e. no 
manual setting of arguments.

Admittedly I am new to PLplot and while I've been using wxWdgets for a 
while now this new project has me expanding my repertoire. I have been 
using the examples provided but simple changes lead to strange results.

It is not my intent to waste your time and I appreciate your help.  I 
ask only when I've tried several times and read the PLplot manual.  I 
think that will be my weekend reading.

David


On 6/7/2018 10:46 AM, Phil Rosenberg wrote:
> Hi David again
>
> Just to let you know that a way to get the automatic text sizing to
> work correctly without specifying an initial size for your window
> would be to wait until the window is displayed to call your Plot
> routine. You could do this by catching the first resize event or first
> paint event and calling Plot at that point.
>
> Or if you wish to manually set text size you should note that
> pls->adv() and pls->env() (which calls plsadv()) reset the size to
> what plplot thinks is the best. Hence you must do the work of
> pls->env() manually. In your case, replace pls->env() with
>
>   pls->clear();
>   pls->vsta();
>   pls->wind(xmin, xmax, ymin, ymax);
>   pls->schr(5.0, 1.0);
>   plbox("bcnst", (PLFLT) 0.0, 0, "bcnstv", (PLFLT) 0.0, 0);
>   pls->schr(8.0, 1.0);
>   pls->lab("x", "y", "sin(x)/x");
>
> replacing the values 5.0 and 8.0 witht he size you want your numbers
> and labels (in mm).
>
> On 7 June 2018 at 14:55, Phil Rosenberg <p.d...@gm...> wrote:
>> Hi David
>> Sorry, I haven't replied - I've been away and off email for close to a month.
>>
>> Anyway - the problem is that when you create your wxPLplotwindow using
>> the default constructor it gets a size of wxDefaultSize at
>> initialisation. This is 20x20 pixels on my Windows system. PLPlot then
>> uses this size along with the DPI to calculate the most appropriate
>> text size, which comes out at I think about 0.3 mm. This is converted
>> to a pt size and used to create a wxFont. One of either of the
>> following is happening wxFont only accepts integers for pt size and
>> the pt size is less than 1 so gets rounded down to 0 and no text is
>> drawn, or the text is sortof there, but it is so small it doesn't
>> actually show up.
>>
>> The easiest workaround is to specify a size at construction time -
>> this will change when your frame actually sorts out the sizing of its
>> child windows, but that's fine. So something like
>>
>> m_right = new wxPLplotwindow<wxPanel>(true, wxSize(800, 800));
>>
>> works and the text displays.
>>
>> You should also be able to manually set the size using pls->schr() in
>> your Plot function, but I've just quickly tried that and it didn't
>> work. I'll try to investigate why.
>>
>> Hope that gets you going for now.
>>
>> Phil
>>
>>
>>
>> On 6 June 2018 at 13:01, David Bergman <stu...@gm...> wrote:
>>> Alan,
>>>
>>> Thanks.  It seems that we're making some progress.  I am working on Windows
>>> and I do not get the warning
>>> "Somehow we attempted to plot before the wxPLplotwindow was ready. The plot
>>> will not be drawn".
>>> I get a plot with some missing elements.  I've not tried to build or run in
>>> Linux.
>>>
>>> Thanks for your help,
>>> David
>>>
>>>
>>> On 6/6/2018 1:48 AM, Alan W. Irwin wrote:
>>>> On 2018-05-25 15:37-0400 David Bergman wrote:
>>>>
>>>>> Alan,
>>>>>
>>>>> I regret waiting this long to reply but have had a lot of work.
>>>>> To tell you the truth I am not sure what exactly caused the issue but
>>>>> I've deleted the "wxOVERRIDE" from the code, which was clearly a copy-paste
>>>>> from a wxWidgets example.
>>>>>
>>>>> I copied the simple.cpp code into the PLplot-Widgets example.
>>>>>
>>>>> cmake and nmake both ran find but cmake install generated the following
>>>>> fatal error.  Recall that I had quite a bit of trouble getting it to install
>>>>> the first time and I may have missed an option that is required.  Not sure
>>>>> if my error is due to the same issue that caused your error.
>>>>>
>>>>>
>>>>> Install the project...
>>>>> -- Install configuration: "Debug"
>>>>> -- Installing: C:/Program Files (x86)/plplot/share/doc/plplot/ABOUT
>>>>> CMake Error at cmake_install.cmake:39 (file):
>>>>>   file INSTALL cannot copy file "C:/plplot-5.13.0/ABOUT" to "C:/Program
>>>>> Files
>>>>>   (x86)/plplot/share/doc/plplot/ABOUT".
>>>>>
>>>>>
>>>>> NMAKE : fatal error U1077: 'echo' : return code '0x1'
>>>>> Stop.
>>>>
>>>> Hi David:
>>>>
>>>> In my case, it was configuration of a new computer which kept me from
>>>> replying to what you said above in a timely way.  My apologies for that
>>>> delay.  But that new computer configuration has now been a success (I
>>>> am writing this from the new computer and PLplot also builds
>>>> on that new computer) so I now have a chance to answer you.
>>>>
>>>> I think the nmake trouble you are having is due to the (default) install
>>>> prefix
>>>> "C:/Program Files (x86)" having a blank in the path.  I think all those
>>>> "blank in
>>>> path" issues are now gone in the git version of PLplot so please try that
>>>> not
>>>> only for that reason but also because that is the version of PLplot I test
>>>> with
>>>> in any case.
>>>>
>>>> I tried a similar test (copying simple.cpp on top of
>>>> examples/c++/wxPLplotDemo.cpp) here,
>>>> but in my case I configured PLplot with the cmake option -DBUILD_TEST=ON
>>>> which
>>>> allows users to test in the build tree without having to install. The
>>>> result on
>>>> my new Debian Buster platform was I could build and run simple.cpp using
>>>> "make test_wxPLplotDemo".  That test had two key warnings which were
>>>>
>>>> Gtk-Message: 22:23:32.181: GtkDialog mapped without a transient parent.
>>>> This is discouraged.
>>>>
>>>> on the command line + a dialog box with the following contents:
>>>>
>>>> "Somehow we attempted to plot before the wxPLplotwindow was ready.  The
>>>> plot will not be drawn".
>>>>
>>>> And indeed that was followed by a blank plot.  So it appears your
>>>> simple.cpp is still
>>>> not set up correctly for the Linux case.
>>>>
>>>> I have put this thread back on the plplot-general list because Phil
>>>> Rosenberg, the author of the PLplot wxwidgets binding and device may
>>>> wish to comment since he had similar "waiting for events" trouble in
>>>> the past on Linux which might be related to what I am seeing on Linux with
>>>> the current simple.cpp.
>>>>
>>>> Alan
>>>> __________________________
>>>> Alan W. Irwin
>>>>
>>>> Astronomical research affiliation with Department of Physics and
>>>> Astronomy,
>>>> University of Victoria (astrowww.phys.uvic.ca).
>>>>
>>>> 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
>>>> __________________________
>>>
>>>
>>> ---
>>> This email has been checked for viruses by Avast antivirus software.
>>> https://www.avast.com/antivirus
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Plplot-general mailing list
>>> Plp...@li...
>>> https://lists.sourceforge.net/lists/listinfo/plplot-general

Re: [Plplot-general] Two subplots on one common page without space between them

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

On 2018-06-07 16:34+0300 Sergey Shcherbina wrote:

>
> Hi!
>
> I found the example where is the method how to draw two subplots on different pages.
> But I don't know how to remove the space between subplots on one page. Where is the
> example with this template? In attached files my attempts to do it as it is need.

Hi Sergey:

I suggest you adapt the approach at
<http://plplot.org/examples.php?demo=01> which appears to do what you
have described.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

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-general] plplot-wxwidgets-plotting

[David B. <dav...@ya...>]

 Phil, 
Thank you very much for the help.  I will try these edits and see how it goes.As for specifying the size of the window (as per your last email).  I've shied away from that as it screwed up the splitter windows construction I had.This suggestion looks like the best route, will let you know how it works.David

    On Thursday, June 7, 2018, 10:46:44 AM EDT, Phil Rosenberg <p.d...@gm...> wrote:  
 
 Hi David again

Just to let you know that a way to get the automatic text sizing to
work correctly without specifying an initial size for your window
would be to wait until the window is displayed to call your Plot
routine. You could do this by catching the first resize event or first
paint event and calling Plot at that point.

Or if you wish to manually set text size you should note that
pls->adv() and pls->env() (which calls plsadv()) reset the size to
what plplot thinks is the best. Hence you must do the work of
pls->env() manually. In your case, replace pls->env() with

 pls->clear();
 pls->vsta();
 pls->wind(xmin, xmax, ymin, ymax);
 pls->schr(5.0, 1.0);
 plbox("bcnst", (PLFLT) 0.0, 0, "bcnstv", (PLFLT) 0.0, 0);
 pls->schr(8.0, 1.0);
 pls->lab("x", "y", "sin(x)/x");

replacing the values 5.0 and 8.0 witht he size you want your numbers
and labels (in mm).

On 7 June 2018 at 14:55, Phil Rosenberg <p.d...@gm...> wrote:
> Hi David
> Sorry, I haven't replied - I've been away and off email for close to a month.
>
> Anyway - the problem is that when you create your wxPLplotwindow using
> the default constructor it gets a size of wxDefaultSize at
> initialisation. This is 20x20 pixels on my Windows system. PLPlot then
> uses this size along with the DPI to calculate the most appropriate
> text size, which comes out at I think about 0.3 mm. This is converted
> to a pt size and used to create a wxFont. One of either of the
> following is happening wxFont only accepts integers for pt size and
> the pt size is less than 1 so gets rounded down to 0 and no text is
> drawn, or the text is sortof there, but it is so small it doesn't
> actually show up.
>
> The easiest workaround is to specify a size at construction time -
> this will change when your frame actually sorts out the sizing of its
> child windows, but that's fine. So something like
>
> m_right = new wxPLplotwindow<wxPanel>(true, wxSize(800, 800));
>
> works and the text displays.
>
> You should also be able to manually set the size using pls->schr() in
> your Plot function, but I've just quickly tried that and it didn't
> work. I'll try to investigate why.
>
> Hope that gets you going for now.
>
> Phil
>
>
>
> On 6 June 2018 at 13:01, David Bergman <stu...@gm...> wrote:
>> Alan,
>>
>> Thanks.  It seems that we're making some progress.  I am working on Windows
>> and I do not get the warning
>> "Somehow we attempted to plot before the wxPLplotwindow was ready. The plot
>> will not be drawn".
>> I get a plot with some missing elements.  I've not tried to build or run in
>> Linux.
>>
>> Thanks for your help,
>> David
>>
>>
>> On 6/6/2018 1:48 AM, Alan W. Irwin wrote:
>>>
>>> On 2018-05-25 15:37-0400 David Bergman wrote:
>>>
>>>> Alan,
>>>>
>>>> I regret waiting this long to reply but have had a lot of work.
>>>> To tell you the truth I am not sure what exactly caused the issue but
>>>> I've deleted the "wxOVERRIDE" from the code, which was clearly a copy-paste
>>>> from a wxWidgets example.
>>>>
>>>> I copied the simple.cpp code into the PLplot-Widgets example.
>>>>
>>>> cmake and nmake both ran find but cmake install generated the following
>>>> fatal error.  Recall that I had quite a bit of trouble getting it to install
>>>> the first time and I may have missed an option that is required.  Not sure
>>>> if my error is due to the same issue that caused your error.
>>>>
>>>>
>>>> Install the project...
>>>> -- Install configuration: "Debug"
>>>> -- Installing: C:/Program Files (x86)/plplot/share/doc/plplot/ABOUT
>>>> CMake Error at cmake_install.cmake:39 (file):
>>>>  file INSTALL cannot copy file "C:/plplot-5.13.0/ABOUT" to "C:/Program
>>>> Files
>>>>  (x86)/plplot/share/doc/plplot/ABOUT".
>>>>
>>>>
>>>> NMAKE : fatal error U1077: 'echo' : return code '0x1'
>>>> Stop.
>>>
>>>
>>> Hi David:
>>>
>>> In my case, it was configuration of a new computer which kept me from
>>> replying to what you said above in a timely way.  My apologies for that
>>> delay.  But that new computer configuration has now been a success (I
>>> am writing this from the new computer and PLplot also builds
>>> on that new computer) so I now have a chance to answer you.
>>>
>>> I think the nmake trouble you are having is due to the (default) install
>>> prefix
>>> "C:/Program Files (x86)" having a blank in the path.  I think all those
>>> "blank in
>>> path" issues are now gone in the git version of PLplot so please try that
>>> not
>>> only for that reason but also because that is the version of PLplot I test
>>> with
>>> in any case.
>>>
>>> I tried a similar test (copying simple.cpp on top of
>>> examples/c++/wxPLplotDemo.cpp) here,
>>> but in my case I configured PLplot with the cmake option -DBUILD_TEST=ON
>>> which
>>> allows users to test in the build tree without having to install. The
>>> result on
>>> my new Debian Buster platform was I could build and run simple.cpp using
>>> "make test_wxPLplotDemo".  That test had two key warnings which were
>>>
>>> Gtk-Message: 22:23:32.181: GtkDialog mapped without a transient parent.
>>> This is discouraged.
>>>
>>> on the command line + a dialog box with the following contents:
>>>
>>> "Somehow we attempted to plot before the wxPLplotwindow was ready.  The
>>> plot will not be drawn".
>>>
>>> And indeed that was followed by a blank plot.  So it appears your
>>> simple.cpp is still
>>> not set up correctly for the Linux case.
>>>
>>> I have put this thread back on the plplot-general list because Phil
>>> Rosenberg, the author of the PLplot wxwidgets binding and device may
>>> wish to comment since he had similar "waiting for events" trouble in
>>> the past on Linux which might be related to what I am seeing on Linux with
>>> the current simple.cpp.
>>>
>>> Alan
>>> __________________________
>>> Alan W. Irwin
>>>
>>> Astronomical research affiliation with Department of Physics and
>>> Astronomy,
>>> University of Victoria (astrowww.phys.uvic.ca).
>>>
>>> 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
>>> __________________________
>>
>>
>>
>> ---
>> This email has been checked for viruses by Avast antivirus software.
>> https://www.avast.com/antivirus
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Plplot-general mailing list
>> Plp...@li...
>> https://lists.sourceforge.net/lists/listinfo/plplot-general

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Plplot-general mailing list
Plp...@li...
https://lists.sourceforge.net/lists/listinfo/plplot-general
  

Re: [Plplot-general] plplot-wxwidgets-plotting

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

Hi David again

Just to let you know that a way to get the automatic text sizing to
work correctly without specifying an initial size for your window
would be to wait until the window is displayed to call your Plot
routine. You could do this by catching the first resize event or first
paint event and calling Plot at that point.

Or if you wish to manually set text size you should note that
pls->adv() and pls->env() (which calls plsadv()) reset the size to
what plplot thinks is the best. Hence you must do the work of
pls->env() manually. In your case, replace pls->env() with

 pls->clear();
 pls->vsta();
 pls->wind(xmin, xmax, ymin, ymax);
 pls->schr(5.0, 1.0);
 plbox("bcnst", (PLFLT) 0.0, 0, "bcnstv", (PLFLT) 0.0, 0);
 pls->schr(8.0, 1.0);
 pls->lab("x", "y", "sin(x)/x");

replacing the values 5.0 and 8.0 witht he size you want your numbers
and labels (in mm).

On 7 June 2018 at 14:55, Phil Rosenberg <p.d...@gm...> wrote:
> Hi David
> Sorry, I haven't replied - I've been away and off email for close to a month.
>
> Anyway - the problem is that when you create your wxPLplotwindow using
> the default constructor it gets a size of wxDefaultSize at
> initialisation. This is 20x20 pixels on my Windows system. PLPlot then
> uses this size along with the DPI to calculate the most appropriate
> text size, which comes out at I think about 0.3 mm. This is converted
> to a pt size and used to create a wxFont. One of either of the
> following is happening wxFont only accepts integers for pt size and
> the pt size is less than 1 so gets rounded down to 0 and no text is
> drawn, or the text is sortof there, but it is so small it doesn't
> actually show up.
>
> The easiest workaround is to specify a size at construction time -
> this will change when your frame actually sorts out the sizing of its
> child windows, but that's fine. So something like
>
> m_right = new wxPLplotwindow<wxPanel>(true, wxSize(800, 800));
>
> works and the text displays.
>
> You should also be able to manually set the size using pls->schr() in
> your Plot function, but I've just quickly tried that and it didn't
> work. I'll try to investigate why.
>
> Hope that gets you going for now.
>
> Phil
>
>
>
> On 6 June 2018 at 13:01, David Bergman <stu...@gm...> wrote:
>> Alan,
>>
>> Thanks.  It seems that we're making some progress.  I am working on Windows
>> and I do not get the warning
>> "Somehow we attempted to plot before the wxPLplotwindow was ready. The plot
>> will not be drawn".
>> I get a plot with some missing elements.  I've not tried to build or run in
>> Linux.
>>
>> Thanks for your help,
>> David
>>
>>
>> On 6/6/2018 1:48 AM, Alan W. Irwin wrote:
>>>
>>> On 2018-05-25 15:37-0400 David Bergman wrote:
>>>
>>>> Alan,
>>>>
>>>> I regret waiting this long to reply but have had a lot of work.
>>>> To tell you the truth I am not sure what exactly caused the issue but
>>>> I've deleted the "wxOVERRIDE" from the code, which was clearly a copy-paste
>>>> from a wxWidgets example.
>>>>
>>>> I copied the simple.cpp code into the PLplot-Widgets example.
>>>>
>>>> cmake and nmake both ran find but cmake install generated the following
>>>> fatal error.  Recall that I had quite a bit of trouble getting it to install
>>>> the first time and I may have missed an option that is required.  Not sure
>>>> if my error is due to the same issue that caused your error.
>>>>
>>>>
>>>> Install the project...
>>>> -- Install configuration: "Debug"
>>>> -- Installing: C:/Program Files (x86)/plplot/share/doc/plplot/ABOUT
>>>> CMake Error at cmake_install.cmake:39 (file):
>>>>  file INSTALL cannot copy file "C:/plplot-5.13.0/ABOUT" to "C:/Program
>>>> Files
>>>>  (x86)/plplot/share/doc/plplot/ABOUT".
>>>>
>>>>
>>>> NMAKE : fatal error U1077: 'echo' : return code '0x1'
>>>> Stop.
>>>
>>>
>>> Hi David:
>>>
>>> In my case, it was configuration of a new computer which kept me from
>>> replying to what you said above in a timely way.  My apologies for that
>>> delay.  But that new computer configuration has now been a success (I
>>> am writing this from the new computer and PLplot also builds
>>> on that new computer) so I now have a chance to answer you.
>>>
>>> I think the nmake trouble you are having is due to the (default) install
>>> prefix
>>> "C:/Program Files (x86)" having a blank in the path.  I think all those
>>> "blank in
>>> path" issues are now gone in the git version of PLplot so please try that
>>> not
>>> only for that reason but also because that is the version of PLplot I test
>>> with
>>> in any case.
>>>
>>> I tried a similar test (copying simple.cpp on top of
>>> examples/c++/wxPLplotDemo.cpp) here,
>>> but in my case I configured PLplot with the cmake option -DBUILD_TEST=ON
>>> which
>>> allows users to test in the build tree without having to install. The
>>> result on
>>> my new Debian Buster platform was I could build and run simple.cpp using
>>> "make test_wxPLplotDemo".  That test had two key warnings which were
>>>
>>> Gtk-Message: 22:23:32.181: GtkDialog mapped without a transient parent.
>>> This is discouraged.
>>>
>>> on the command line + a dialog box with the following contents:
>>>
>>> "Somehow we attempted to plot before the wxPLplotwindow was ready.  The
>>> plot will not be drawn".
>>>
>>> And indeed that was followed by a blank plot.  So it appears your
>>> simple.cpp is still
>>> not set up correctly for the Linux case.
>>>
>>> I have put this thread back on the plplot-general list because Phil
>>> Rosenberg, the author of the PLplot wxwidgets binding and device may
>>> wish to comment since he had similar "waiting for events" trouble in
>>> the past on Linux which might be related to what I am seeing on Linux with
>>> the current simple.cpp.
>>>
>>> Alan
>>> __________________________
>>> Alan W. Irwin
>>>
>>> Astronomical research affiliation with Department of Physics and
>>> Astronomy,
>>> University of Victoria (astrowww.phys.uvic.ca).
>>>
>>> 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
>>> __________________________
>>
>>
>>
>> ---
>> This email has been checked for viruses by Avast antivirus software.
>> https://www.avast.com/antivirus
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Plplot-general mailing list
>> Plp...@li...
>> https://lists.sourceforge.net/lists/listinfo/plplot-general