plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] Would you be willing to test PLplot against Octave-3.8.2 or later in the 3.8 series?

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

Hi Alan, Greg,



Some more information - no solution though:

-        Commenting out all calls to pplimage and plimagefr to avoid the "calls" to f2c (that is a macro, not a function) so that only plimagefr2 was left made no difference to the segmentation fault.

-        Printing the allocated pointers in f2c revealed that the failure occurs at i = 122 for ygg, so in the middle of the procedure with no clue as to the cause.



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-devel] Would you be willing to test PLplot against Octave-3.8.2 or later in the 3.8 series?

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

Hi Alan,



>
> @Arjen and Greg: since it appears to be impossible for Linux users to replicate the
> segfault issue you guys are encountering, I think the only way forward for you is to
> debug this issue on Cygwin.
>
following your receipe I was able to determine that the crash happens in plimagefr2 - when it copies the yg array into the grid ygg. The values of nx and ny are 399 and 486 respectively, so that is quite correct. Why it should fail exactly at this point is something I cannot fathom. When I comment out the statement f2c( yg, ygg, ... ) in the SWIG source for plimagefr2, the failure simply occurs at f2c( a, aa, ... ).

It is quite possible that the failure occurs much earlier. That ought to be checked.

By the way, I noticed that the copies of these arrays are not freed, so that constitutes a memory leak, unless something is taking care of that that I have overlooked in the code.

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-devel] wxwidgets dpi, length, and width issue fixed

[Alan W. I. <ir...@be...>]

Hi Phil:

According to what you have stated and documented and our recent
wxwidgets changes, I was expecting that the -dpi command-line parameter
would work with -dev wxwidgets to change the text size.

That did not work at all until I fixed a wxwidgets dpi, length, and width
bug (commit id 4b4ebda).  After that fix, I finally got the expected
result from the -dpi command-line option (for more details see the
commit message).

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-devel] The 5-week window of opportunity for the current (post-5.11.1) release cycle

[Alan W. I. <ir...@be...>]

On 2015-08-22 21:57+0100 Phil Rosenberg wrote:

> Hi All
>
> I have just pushed a commit with a change to the documentation which I
> believe reflects the things we have said. The changes are to the
> plspage and plsetchr functions in the API section.
>
> If anyone thinks further changes are needed then that's fine, but I
> thought it would be good if any changes we were making based on this
> discussion could be based on the actual documentation, rather than on
> emails that may or may not get properly documented.

Thanks for making these changes.

I have only looked at diffs so far, but so far I have no issues with
how you have restated things.

Also, "make validate" shows there are no issues from the DocBook
perspective.  Nevertheless, the

git diff d5ee62bb^..d5ee62b

command did show one strange issue right at the top:

diff --git a/doc/docbook/src/api.xml b/doc/docbook/src/api.xml
index 956fc15..706aece 100644
--- a/doc/docbook/src/api.xml
+++ b/doc/docbook/src/api.xml
@@ -1,4 +1,4 @@
-<!-- -*-  mode: nxml -*- -->
+<U+FEFF><!-- -*-  mode: nxml -*- -->

I don't think it should be necessary to insert that weird Unicode
character into api.xml.  If you agree, could you please remove it?

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-devel] Would you be willing to test PLplot against Octave-3.8.2 or later in the 3.8 series?

[Alan W. I. <ir...@be...>]

On 2015-07-10 17:12-0700 Alan W. Irwin wrote:

> On 2015-07-10 23:27+0100 Andrew Ross wrote:
>
>>
>> I've built and run the non-interactive octave tests and they complete with
>> no errors using octave-3.8.2 on Ubuntu 15.04 (vivid). I did have some
>> build errors, but that was just related to the hdf5.h header being in a
>> new location.
>
> Hi Andrew:
>
> The current status of the Cygwin octave-3.8.2 issue is
> Arjen discovered the problem was an assumption in our scripts
> concerning the location of the plplot_octave.oct dll for the Windows
> case, and I am in the middle of fixing that assumption.
>
> However, once I get that fix done, if Arjen runs into additional issues
> it is good to know that PLplot basically works for octave-3.8.2
> so many thanks for proving that.
>
> With regard to the hdf5.h location issue you discovered on Ubuntu,
> could you please make the required small adjustment to
> cmake/modules/octave.cmake using PATH_SUFFIXES on the find_path
> command so that it finds hdf5.h preferentially in the traditional
> location (/usr/include/hdf5.h), but if it is not found there it looks
> in the subdirectory of that location which is appropriate for Ubuntu
> (and probably also later versions of Debian than I have at the
> moment).

To Andrew, Arjen and Greg:

@Andrew: You referred above to an hdf5.h issue on Ubuntu.  Please make the
suggested upstream build-system fix so no Ubuntu PLplot builder
runs into that issue.

Also, could you please run

scripts/comprehensive_test.sh --do_test_interactive no

on your Ubuntu platform and send me the resulting report tarball,
../comprehensive_test_disposeable/comprehensive_test.tar.gz ?

Running that script (with --do_test_interactive no) should be
essentially painless (except possibly if you are short of disk space),
and that test report on one of our most important platforms would be
most useful.

The current status of octave on Cygwin is Arjen can now build the
octave (3.8.2) binding of PLplot without issues, and all the "p"
octave examples work, and "x" examples 00 through 19 work as well.
However, he did encounter a segfault for the 20th example.
Greg's recent report for the same platform confirms that
segfault for octave example 20 issue.

Your above good Ubuntu results for octave 3.8.2, and some excellent
results I have just now (commit 338492f) achieved for the
test_noninteractive target of an epa_built plplot_lite that depends on
epa_built octave-3.8.2 supports the hypothesis that the segfault issue
Arjen has found and which Greg confirmed is likely nothing to do with
octave-3.8.2, and is instead some Windows or Cygwin issue with our
Octave-related code or with the octave-3.8.2 Cygwin build or
packaging.

@Arjen and Greg: since it appears to be impossible for Linux users to
replicate the segfault issue you guys are encountering, I think the
only way forward for you is to debug this issue on Cygwin.

To help simplify that debugging process you should locally modify
plplot_test/test_octave.sh.in to remove all examples other than x20.
After that, "make test_octave_psc" should just execute the 20th octave
example.  Once you have achieved that, then proceed with old-fashioned
debugging, i.e., locally modify examples/octave/x20c.m to output
additional results to localize which octave command is generating
the segfault, and then to dump all arguments of that command.

In off-list discussion with Arjen we have proved to our mutual
satisfication via md5sum, that the git checkout of the lena.pgm file
(used by example 20) is identical in the two cases.  In other words,
git is treating this file (as expected) as a binary file rather than a
text file (with accompanying bit flips due to line ending issues). We
have also looked at the octave fopen command that opens this file in
x20c.m. However, if your preliminary analysis to discover which octave
command in x20c.m segfaults indicates the problem could be in the lena
data that is read in, then it would be good to double check by dumping
some parts of that file from within the example.

In any case, I would be happy to run any x20c.m you guys have modified
to dump out results to give you a Linux versus Cygwin comparison of
those dumped results.

Good luck with the bug hunt, and let me know how it goes.

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-devel] The 5-week window of opportunity for the current (post-5.11.1) release cycle

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

Hi All

I have just pushed a commit with a change to the documentation which I
believe reflects the things we have said. The changes are to the
plspage and plsetchr functions in the API section.

If anyone thinks further changes are needed then that's fine, but I
thought it would be good if any changes we were making based on this
discussion could be based on the actual documentation, rather than on
emails that may or may not get properly documented.

Phil

On 21 August 2015 at 21:23, Alan W. Irwin <ir...@be...> wrote:
> To Phil and Jim:
>
> Having slept on the idea of setting an explicit default values for
> xdpi, ydpi, and length arguments (see below) in each stream, I
> have now decided that is a bad idea because of the inability to
> distinguish between the default value and a user-set value for
> the stream.
>
> So what I have done instead (commit id 3e430ae) is to
> leave the default stream value for xdpi and ydpi at 0.,
> add the line
>
> #define PLPLOT_DEFAULT_DPI 90.
>
> to plplotP.h, and change the gd, cgm, and wxwidgets device drivers
> to use this value by default if the user has not set the
> xdpi and ydpi stream values.
>
> I will look further at ps, psttf, and qt to see what can be done with
> user-set and default dpi in those cases, and I request Jim and Phil to
> do the same thing for wingcc and Jim's new driver cases.
>
> On 2015-08-21 09:56+0100 Phil Rosenberg wrote:
>
>> While we are on the topic of standardising DPI is it also worth
>> standardising page size? It might be useful to have a set of default
>> sizes, perhaps portrait A4, for noninteractive drivers, and a default
>> size for interactive drivers which would be a scaled version of that
>> for noninteractive drivers as A4 is significantly bigger than my
>> laptop screen assuming 90 dpi? Not sure if raster and non raster
>> drivers should have different default sizes?
>
>
> I think the same approach of defining symbolic constants in plplotP.h and
> updating
> drivers to use those rather than their own "unique" values would be
> good here.  Note in my above wxwidgets change I carefully separated
> updating dpi from updating length constants so modifying that code
> to use symbolic length constants should be straightforward.
>
>
> 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-devel] The 5-week window of opportunity for the current (post-5.11.1) release cycle

[Alan W. I. <ir...@be...>]

To Phil and Jim:

Having slept on the idea of setting an explicit default values for
xdpi, ydpi, and length arguments (see below) in each stream, I
have now decided that is a bad idea because of the inability to
distinguish between the default value and a user-set value for
the stream.

So what I have done instead (commit id 3e430ae) is to
leave the default stream value for xdpi and ydpi at 0.,
add the line

#define PLPLOT_DEFAULT_DPI 90.

to plplotP.h, and change the gd, cgm, and wxwidgets device drivers
to use this value by default if the user has not set the
xdpi and ydpi stream values.

I will look further at ps, psttf, and qt to see what can be done with
user-set and default dpi in those cases, and I request Jim and Phil to
do the same thing for wingcc and Jim's new driver cases.

On 2015-08-21 09:56+0100 Phil Rosenberg wrote:

> While we are on the topic of standardising DPI is it also worth
> standardising page size? It might be useful to have a set of default
> sizes, perhaps portrait A4, for noninteractive drivers, and a default
> size for interactive drivers which would be a scaled version of that
> for noninteractive drivers as A4 is significantly bigger than my
> laptop screen assuming 90 dpi? Not sure if raster and non raster
> drivers should have different default sizes?

I think the same approach of defining symbolic constants in plplotP.h and updating
drivers to use those rather than their own "unique" values would be
good here.  Note in my above wxwidgets change I carefully separated
updating dpi from updating length constants so modifying that code
to use symbolic length constants should be straightforward.

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-devel] The 5-week window of opportunity for the current (post-5.11.1) release cycle

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

>
> @Jim
> You have perhaps already looked into this but if not this page
> https://msdn.microsoft.com/en-gb/library/windows/desktop/dn469266(v=vs.85).aspx
> is worth a read. You should note that it would appear that if you do
> not call SetProcessDpiAwareness() then Windows will assume the
> application is not scale aware and it will scale your text and UI
> elements for you (although with lower quality than if you did it
> yourself). This will give you double scaling of your text which is
> bad. However, if you do call SetProcessDpiAwareness(), then you are
> potentially overriding a call made by the library user and you are
> forcing a user to do what you want and not what they want. For this
> reason I would suggest that you do not attempt to grab the monitor
> dpi, but instead allow the user to decide whether to be dpi aware and
> deal with it themselves by calling plspage.
>
> While we are on the topic of standardising DPI is it also worth
> standardising page size? It might be useful to have a set of default
> sizes, perhaps portrait A4, for noninteractive drivers, and a default
> size for interactive drivers which would be a scaled version of that
> for noninteractive drivers as A4 is significantly bigger than my
> laptop screen assuming 90 dpi? Not sure if raster and non raster
> drivers should have different default sizes?
>

@Jim again
I should have continued reading the link I sent before sending that message.

It turns out that to set DPI awareness either SetProcessDpiAwareness()
must be called "prior to any Win32API call that forces the system to
begin virtualization" preferably instead DPI awareness should be set
in the application manifest. Within plplot we are therefore in no
position to be able to correctly set dpi awareness. I think this gives
an even stronger case for simply using a fixed default.

Phil

Re: [Plplot-devel] The 5-week window of opportunity for the current (post-5.11.1) release cycle

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

My feeling (but happy to have my mind changed) is that for consistency
all rasterised drivers should all adopt the same strategy. So either
plstrm_init sets the dpi to a constant, or alternatively plstrm_init
has platform dependant code to set it to the monitor resolution. Those
drivers which then require a specific DPI (e.g. ps) can then set that
as they need.

I think however it is important to bear in mind that plplot is a
library - not a program. I think that the most important thing is
simplicity of use (including good documentation - not that I'm good at
that) so it is much easier for us to document and conforms closer to
the principle of least surprise if we state a single default dpi for
raster graphics. This would mean, for example that a plot rendered by
an interactive driver, then redrawn with a non-interactive driver
would look (approximately) the same.

@Jim
You have perhaps already looked into this but if not this page
https://msdn.microsoft.com/en-gb/library/windows/desktop/dn469266(v=vs.85).aspx
is worth a read. You should note that it would appear that if you do
not call SetProcessDpiAwareness() then Windows will assume the
application is not scale aware and it will scale your text and UI
elements for you (although with lower quality than if you did it
yourself). This will give you double scaling of your text which is
bad. However, if you do call SetProcessDpiAwareness(), then you are
potentially overriding a call made by the library user and you are
forcing a user to do what you want and not what they want. For this
reason I would suggest that you do not attempt to grab the monitor
dpi, but instead allow the user to decide whether to be dpi aware and
deal with it themselves by calling plspage.

While we are on the topic of standardising DPI is it also worth
standardising page size? It might be useful to have a set of default
sizes, perhaps portrait A4, for noninteractive drivers, and a default
size for interactive drivers which would be a scaled version of that
for noninteractive drivers as A4 is significantly bigger than my
laptop screen assuming 90 dpi? Not sure if raster and non raster
drivers should have different default sizes?

Phil

On 21 August 2015 at 08:15, Alan W. Irwin <ir...@be...> wrote:
> Hi Jim:
>
> On 2015-08-20 23:41-0400 Jim Dishaw wrote:
>
>> My plan was to default to the DPI setting returned by the windows
>
> API. Microsoft has documentation on how to write code that would be
> compatible with high-dpi and regular devices.  I don't see any major
> problems with letting the user set the dpi other than poor quality
> output.
>
>> My goal is to honor the font size height specified by the user as the
>> default behavior.
>
>
> Good.
>
> But what do you do when you see that both plsc->xdpi and plsc->ydpi
> are set to PLPLOT_DEFAULT_API?  (See my second previous post in this
> thread concerning PLPLOT_DEFAULT_API.) Did the user set that because
> they wanted that exact value, or is that the default value which you
> can then override by following the Microsoft prescription?
>
> Maybe for the default we should set
>
> plsc->xdpi = -PLPLOT_DEFAULT_API;
> plsc->ydpi = -PLPLOT_DEFAULT_API;
>
> as a well-known signal that we want to use default DPI?  Most drivers
> would then simply use PLPLOT_DEFAULT_API if plsc->[xy]dpi was set to
> the negative of that, but some might use a different default value
> instead (such as the Microsoft prescription) if either plsc->xdpi
> or plsc->ydpi was -PLPLOT_DEFAULT_API?
>
> Just thinking aloud here to stir up more discussion....
>
>
> 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-devel] The 5-week window of opportunity for the current (post-5.11.1) release cycle

[Alan W. I. <ir...@be...>]

Hi Jim:

On 2015-08-20 23:41-0400 Jim Dishaw wrote:

> My plan was to default to the DPI setting returned by the windows
API. Microsoft has documentation on how to write code that would be
compatible with high-dpi and regular devices.  I don't see any major
problems with letting the user set the dpi other than poor quality
output.

> My goal is to honor the font size height specified by the user as the default behavior.

Good.

But what do you do when you see that both plsc->xdpi and plsc->ydpi
are set to PLPLOT_DEFAULT_API?  (See my second previous post in this
thread concerning PLPLOT_DEFAULT_API.) Did the user set that because
they wanted that exact value, or is that the default value which you
can then override by following the Microsoft prescription?

Maybe for the default we should set

plsc->xdpi = -PLPLOT_DEFAULT_API;
plsc->ydpi = -PLPLOT_DEFAULT_API;

as a well-known signal that we want to use default DPI?  Most drivers
would then simply use PLPLOT_DEFAULT_API if plsc->[xy]dpi was set to
the negative of that, but some might use a different default value
instead (such as the Microsoft prescription) if either plsc->xdpi
or plsc->ydpi was -PLPLOT_DEFAULT_API?

Just thinking aloud here to stir up more discussion....

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-devel] The 5-week window of opportunity for the current (post-5.11.1) release cycle

[Jim D. <ji...@di...>]

> On Aug 20, 2015, at 7:43 PM, Alan W. Irwin <ir...@be...> wrote:
> 
>> On 2015-08-20 21:48+0100 Phil Rosenberg wrote:
>> 
>>> On 20 August 2015 at 20:44, Alan W. Irwin <ir...@be...> wrote:
>>> [...]If you agree with this approach for setting default PLplot-wide
>>> plsc->xdpi and plsc->ydpi values will you please push a commit to this
>>> effect to get this preliminary out of the way?
>> 
>> This seems perfectly sensible to me. I will make this change and commit it.
> 
> Hi Phil (and Jim too since this affects the new device he is
> implementing):
> 
> I have now looked further, and it turns out this proposed change will
> need a follow-up commit because the non-zero default values for plsc->xdpi and plsc->ydpi will interfere with the following type of
> logic that is currently in our device-driver code:
> 
> software@raven> grep -A 6 'if.*dpi.*0' drivers/*
> drivers/cgm.c:    if ( pls->xdpi <= 0 )
> drivers/cgm.c-    {
> drivers/cgm.c-// This corresponds to a typical monitor resolution of 4 pixels/mm.
> drivers/cgm.c-        plspage( 4. * 25.4, 4. * 25.4, 0, 0, 0, 0 );
> drivers/cgm.c-    }
> drivers/cgm.c-    else
> drivers/cgm.c-    {
> --
> drivers/gd.c:    if ( pls->xdpi <= 0 )
> drivers/gd.c-    {
> drivers/gd.c-// This corresponds to a typical monitor resolution of 4 pixels/mm.
> drivers/gd.c-        plspage( 4. * 25.4, 4. * 25.4, 0, 0, 0, 0 );
> drivers/gd.c-    }
> drivers/gd.c-    else
> drivers/gd.c-    {
> --
> drivers/gd.c:    if ( pls->xdpi <= 0 )
> drivers/gd.c-    {
> drivers/gd.c-// This corresponds to a typical monitor resolution of 4 pixels/mm.
> drivers/gd.c-        plspage( 4. * 25.4, 4. * 25.4, 0, 0, 0, 0 );
> drivers/gd.c-    }
> drivers/gd.c-    else
> drivers/gd.c-    {
> --
> drivers/ps.c:    if ( pls->xdpi <= 0 )
> drivers/ps.c-        pls->xdpi = 72.;
> drivers/ps.c:    if ( pls->ydpi <= 0 )
> drivers/ps.c-        pls->ydpi = 72.;
> drivers/ps.c-
> drivers/ps.c-    pxlx = YPSSIZE / LPAGE_X;
> drivers/ps.c-    pxly = XPSSIZE / LPAGE_Y;
> drivers/ps.c-
> drivers/ps.c-    if ( text )
> --
> drivers/psttf.cc:    if ( pls->xdpi <= 0 )
> drivers/psttf.cc-        pls->xdpi = 72.;
> drivers/psttf.cc:    if ( pls->ydpi <= 0 )
> drivers/psttf.cc-        pls->ydpi = 72.;
> drivers/psttf.cc-
> drivers/psttf.cc-
> drivers/psttf.cc-    pxlx = YPSSIZE / LPAGE_X;
> drivers/psttf.cc-    pxly = XPSSIZE / LPAGE_Y;
> drivers/psttf.cc-
> --
> drivers/qt.cpp:    if ( pls->xdpi <= 0. )
> drivers/qt.cpp-        dpi = DEFAULT_DPI;
> drivers/qt.cpp-    else
> drivers/qt.cpp-        dpi = pls->xdpi;
> drivers/qt.cpp-
> drivers/qt.cpp-    // Shamelessly copied on the Cairo stuff :)
> drivers/qt.cpp-    if ( pls->xlength <= 0 || pls->ylength <= 0 )
> --
> drivers/qt.cpp:    if ( pls->xdpi <= 0. )
> drivers/qt.cpp-        dpi = DEFAULT_DPI;
> drivers/qt.cpp-    else
> drivers/qt.cpp-        dpi = pls->xdpi;
> drivers/qt.cpp-
> drivers/qt.cpp-    // Set the plot size to the memory buffer size, on the off chance
> drivers/qt.cpp-    // that they are different.
> --
> drivers/wingcc.c:    if ( pls->xdpi <= 0 ) // Get DPI from windows
> drivers/wingcc.c-    {
> drivers/wingcc.c-        plspage( GetDeviceCaps( dev->hdc, HORZRES ) / GetDeviceCaps( dev->hdc, HORZSIZE ) * 25.4,
> drivers/wingcc.c-            GetDeviceCaps( dev->hdc, VERTRES ) / GetDeviceCaps( dev->hdc, VERTSIZE ) * 25.4, 0, 0, 0, 0 );
> drivers/wingcc.c-    }
> drivers/wingcc.c-    else
> drivers/wingcc.c-    {
> --
> drivers/wxwidgets_dev.cpp:    if ( pls->xdpi == 0.0 || pls->ydpi == 0 )
> drivers/wxwidgets_dev.cpp-    {
> drivers/wxwidgets_dev.cpp:        if ( pls->xdpi == 0.0 && pls->ydpi == 0 )
> drivers/wxwidgets_dev.cpp-            c_plspage( 90, 90, 0, 0, 0, 0 );
> drivers/wxwidgets_dev.cpp-        else
> drivers/wxwidgets_dev.cpp-        {
> drivers/wxwidgets_dev.cpp-            PLFLT dpi = MAX( pls->xdpi, pls->ydpi );
> drivers/wxwidgets_dev.cpp-            pls->xdpi = dpi;
> drivers/wxwidgets_dev.cpp-            pls->ydpi = dpi;
> 
> In the cgm and gd cases, the cure is simply to remove those stanzas so
> that those devices use the PLplot default or user-set plsc->xdpi and
> plsc->ydpi values rather than the current special default for those devices of
> 4*25.4 = 101.6 (!).
> 
> I am pretty sure for the ps and psttf cases that the results should be
> completely independent of default or user-set dpi.  After all, a
> printer point unit (important for PostScript) is defined to be 1/72 of
> an inch, and allowing the user to fiddle with that strikes me as a
> hack to use a false definition of a printer point to scale the
> results. Instead, I am pretty sure scaling should be done using the
> -geometry option or the equivalent call to plspage with non-zero 3rd
> and following arguments.
> 
> I am not sure quite what needs to be done in the qt, wingcc, and
> wxwidgets cases, but I am pretty sure it will be obvious once one of
> us takes a detailed look at the relevant code.
> 
> After your commit creating the default plsc->xdpi and plsc->ydpi
> values, I would be willing to take responsibility for the required
> logic modifications of cgm, gd, ps, psttf, and qt.  Would you be
> similarly willing to do the same thing for the wingcc and wxwidgets
> devices?
> 
> @Jim:
> 
> I assume you are completely familiar with dpi issues for both wingcc
> and your new device that is a modernized version of that.  So chime in
> here please, if you see any problems with letting users (or PLplot by
> default) set dpi values for those devices.
> 

My plan was to default to the DPI setting returned by the windows API. Microsoft has documentation on how to write code that would be compatible with high-dpi and regular devices.  I don't see any major problems with letting the user set the dpi other than poor quality output. 

My goal is to honor the font size height specified by the user as the default behavior. 

> 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-devel] The 5-week window of opportunity for the current (post-5.11.1) release cycle

[Alan W. I. <ir...@be...>]

On 2015-08-20 21:48+0100 Phil Rosenberg wrote:

> On 20 August 2015 at 20:44, Alan W. Irwin <ir...@be...> wrote:
>> [...]If you agree with this approach for setting default PLplot-wide
>> plsc->xdpi and plsc->ydpi values will you please push a commit to this
>> effect to get this preliminary out of the way?
>
> This seems perfectly sensible to me. I will make this change and commit it.

Hi Phil (and Jim too since this affects the new device he is
implementing):

I have now looked further, and it turns out this proposed change will
need a follow-up commit because the non-zero default values for 
plsc->xdpi and plsc->ydpi will interfere with the following type of
logic that is currently in our device-driver code:

software@raven> grep -A 6 'if.*dpi.*0' drivers/*
drivers/cgm.c:    if ( pls->xdpi <= 0 )
drivers/cgm.c-    {
drivers/cgm.c-// This corresponds to a typical monitor resolution of 4 pixels/mm.
drivers/cgm.c-        plspage( 4. * 25.4, 4. * 25.4, 0, 0, 0, 0 );
drivers/cgm.c-    }
drivers/cgm.c-    else
drivers/cgm.c-    {
--
drivers/gd.c:    if ( pls->xdpi <= 0 )
drivers/gd.c-    {
drivers/gd.c-// This corresponds to a typical monitor resolution of 4 pixels/mm.
drivers/gd.c-        plspage( 4. * 25.4, 4. * 25.4, 0, 0, 0, 0 );
drivers/gd.c-    }
drivers/gd.c-    else
drivers/gd.c-    {
--
drivers/gd.c:    if ( pls->xdpi <= 0 )
drivers/gd.c-    {
drivers/gd.c-// This corresponds to a typical monitor resolution of 4 pixels/mm.
drivers/gd.c-        plspage( 4. * 25.4, 4. * 25.4, 0, 0, 0, 0 );
drivers/gd.c-    }
drivers/gd.c-    else
drivers/gd.c-    {
--
drivers/ps.c:    if ( pls->xdpi <= 0 )
drivers/ps.c-        pls->xdpi = 72.;
drivers/ps.c:    if ( pls->ydpi <= 0 )
drivers/ps.c-        pls->ydpi = 72.;
drivers/ps.c-
drivers/ps.c-    pxlx = YPSSIZE / LPAGE_X;
drivers/ps.c-    pxly = XPSSIZE / LPAGE_Y;
drivers/ps.c-
drivers/ps.c-    if ( text )
--
drivers/psttf.cc:    if ( pls->xdpi <= 0 )
drivers/psttf.cc-        pls->xdpi = 72.;
drivers/psttf.cc:    if ( pls->ydpi <= 0 )
drivers/psttf.cc-        pls->ydpi = 72.;
drivers/psttf.cc-
drivers/psttf.cc-
drivers/psttf.cc-    pxlx = YPSSIZE / LPAGE_X;
drivers/psttf.cc-    pxly = XPSSIZE / LPAGE_Y;
drivers/psttf.cc-
--
drivers/qt.cpp:    if ( pls->xdpi <= 0. )
drivers/qt.cpp-        dpi = DEFAULT_DPI;
drivers/qt.cpp-    else
drivers/qt.cpp-        dpi = pls->xdpi;
drivers/qt.cpp-
drivers/qt.cpp-    // Shamelessly copied on the Cairo stuff :)
drivers/qt.cpp-    if ( pls->xlength <= 0 || pls->ylength <= 0 )
--
drivers/qt.cpp:    if ( pls->xdpi <= 0. )
drivers/qt.cpp-        dpi = DEFAULT_DPI;
drivers/qt.cpp-    else
drivers/qt.cpp-        dpi = pls->xdpi;
drivers/qt.cpp-
drivers/qt.cpp-    // Set the plot size to the memory buffer size, on the off chance
drivers/qt.cpp-    // that they are different.
--
drivers/wingcc.c:    if ( pls->xdpi <= 0 ) // Get DPI from windows
drivers/wingcc.c-    {
drivers/wingcc.c-        plspage( GetDeviceCaps( dev->hdc, HORZRES ) / GetDeviceCaps( dev->hdc, HORZSIZE ) * 25.4,
drivers/wingcc.c-            GetDeviceCaps( dev->hdc, VERTRES ) / GetDeviceCaps( dev->hdc, VERTSIZE ) * 25.4, 0, 0, 0, 0 );
drivers/wingcc.c-    }
drivers/wingcc.c-    else
drivers/wingcc.c-    {
--
drivers/wxwidgets_dev.cpp:    if ( pls->xdpi == 0.0 || pls->ydpi == 0 )
drivers/wxwidgets_dev.cpp-    {
drivers/wxwidgets_dev.cpp:        if ( pls->xdpi == 0.0 && pls->ydpi == 0 )
drivers/wxwidgets_dev.cpp-            c_plspage( 90, 90, 0, 0, 0, 0 );
drivers/wxwidgets_dev.cpp-        else
drivers/wxwidgets_dev.cpp-        {
drivers/wxwidgets_dev.cpp-            PLFLT dpi = MAX( pls->xdpi, pls->ydpi );
drivers/wxwidgets_dev.cpp-            pls->xdpi = dpi;
drivers/wxwidgets_dev.cpp-            pls->ydpi = dpi;

In the cgm and gd cases, the cure is simply to remove those stanzas so
that those devices use the PLplot default or user-set plsc->xdpi and
plsc->ydpi values rather than the current special default for those devices of
4*25.4 = 101.6 (!).

I am pretty sure for the ps and psttf cases that the results should be
completely independent of default or user-set dpi.  After all, a
printer point unit (important for PostScript) is defined to be 1/72 of
an inch, and allowing the user to fiddle with that strikes me as a
hack to use a false definition of a printer point to scale the
results. Instead, I am pretty sure scaling should be done using the
-geometry option or the equivalent call to plspage with non-zero 3rd
and following arguments.

I am not sure quite what needs to be done in the qt, wingcc, and
wxwidgets cases, but I am pretty sure it will be obvious once one of
us takes a detailed look at the relevant code.

After your commit creating the default plsc->xdpi and plsc->ydpi
values, I would be willing to take responsibility for the required
logic modifications of cgm, gd, ps, psttf, and qt.  Would you be
similarly willing to do the same thing for the wingcc and wxwidgets
devices?

@Jim:

I assume you are completely familiar with dpi issues for both wingcc
and your new device that is a modernized version of that.  So chime in
here please, if you see any problems with letting users (or PLplot by
default) set dpi values for those devices.

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-devel] The 5-week window of opportunity for the current (post-5.11.1) release cycle

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

On 20 August 2015 at 20:44, Alan W. Irwin <ir...@be...> wrote:
> On 2015-08-20 14:43+0100 Phil Rosenberg wrote:
>
>>>> 1) Text size. As far as I am aware the text size in wxWidgets is
>>>> entirely correct - I haven't double checked this today, but this was
>>>> the case last time I checked. The docs state that the text size
>>>> provided by the user is in mm, and I use a value of 90 pixels per inch
>>>> (converted to metric) to convert to pixels. Counting pixels on the
>>>> screen it appears that the output is as I intended. The pixels per
>>>> inch value I used is the same as used by inkscape - so the wxWidgets
>>>> output should have similar sized text to the svg output rendered by
>>>> inkscape. However as you can find online (e.g.
>>>>
>>>>
>>>> http://stackoverflow.com/questions/1346922/svg-and-dpi-absolute-units-and-user-units-inkscape-vs-firefox-vs-imagemagick)
>>>> different svg renderers assume different pixels per inch in their
>>>> rendering. However if other drivers are providing text that is 2.2
>>>> times the size of that in wxWidgets they must be assuming around 40
>>>> pixels per inch which is much lower than any other standard I have
>>>> seen.
>>>> Basically where I am going is that we should set a standard value for
>>>> pixels per inch for all raster drivers. It would potentially be useful
>>>> to have an API call to set the pixels per inch too. Then each driver
>>>> can be checked to make sure it conforms - perhaps with the Peace
>>>> example being used to check.
>>>
>>>
>>>
>>> I am old school scientist on this issue on the one hand, and completely
>>> semiempirical on the other.  :-)
>>>
>>> I. Old school:
>>>
>>> Pixels per mm (and therefore pixels per inch or DPI) should not be an
>>> assumption.  Your monitor has a definite resolution in pixels and a
>>> definite size in mm so therefore it has a known value for pixels per
>>> mm and DPI in both X and Y.
>>>
>>> However, there are some important caveats about this for the
>>> Linux/X11 case see
>>>
>>> <http://unix.stackexchange.com/questions/75344/how-does-x-server-calculate-dpi>.
>>>
>>> That reference does not mention xrandr which is one way to determine
>>> actual DPI for the Linux/X11 case.
>>>
>>> irwin@raven> xrandr |grep " connected"
>>> HDMI-1 connected 1440x900+0+0 (normal left inverted right x axis y
>>> axis) 410mm x 256mm
>>>
>>> I verified those dimensions with a meter stick since my monitor manual
>>> does not include the actual display dimensions.
>>>
>>> Those results imply actual XDPI is
>>>
>>> irwin@raven> echo "1440*25.4/410" |bc -l
>>> 89.20975609756097560975
>>>
>>> and YDPI is
>>>
>>> irwin@raven> echo "900*25.4/256" |bc -l
>>> 89.29687500000000000000
>>>
>>> So those appear to be reasonably reliable numbers for DPI for my
>>> monitor, but as the discussion in the above URL states, the xdpyinfo
>>> application does _not_ provide reliable DPI information.
>>>
>>> irwin@raven> xdpyinfo | grep -E 'dimensions|resolution'
>>>   dimensions:    1440x900 pixels (381x238 millimeters)
>>>   resolution:    96x96 dots per inch
>>>
>>> That is, that app does report the correct pixels for the monitor, but
>>> arbitrarily fakes the size in millimeters to always return fake DPI
>>> values of 96!  I have read web assertions that these fake values are
>>> simply an attempt to follow a fake DPI "standard" set by Microsoft
>>> Windows, but I don't know that is the case.
>>>
>>> So PLplot could in theory (for at least the Linux/X11 xrandr case) be
>>> able to interrogate the operating system to determine the actual
>>> pixels per mm values and then use those values for all rendering that
>>> is done in units of mm.  But just because the xrandr-derived value was
>>> correct in my case does not mean is will be correct in all cases, and
>>> there is also concern about what to do for other platforms. So I doubt
>>> very much we will go there.
>>>
>>> Another approach might be to assume some reasonable DPI value and then
>>> attempt to enforce that for each of our device drivers. But that might
>>> be tricky for our device drivers like qt and cairo which depend on
>>> external libraries which might have their own independent standards
>>> about what to assume for DPI value.  So for now and perhaps
>>> indefinitely, I think we are stuck with the semiempirical approach
>>> below.
>>>
>>> II.  Semiempirical.
>>>
>>> The semiempirical approach is simply to multiply the character size
>>> for each device driver so it agrees reasonably with the others for the
>>> second page of example 2.  That is, the numbers on that page should be
>>> fairly closely inscribed by the inner square.
>>>
>>> I have just looked at that page for a wide variety of our devices, and
>>> they all pass this test more or less except for wxwidgets where the
>>> numbers are roughly half the size of the inner square.  So it is on
>>> that basis I suggest you approximately double the character size to
>>> match more closely what the other devices do here.
>>>
>>>
>>
>> HI Alan, in some ways I am fine with that. I think actually wxWidgets
>> has a cross platform display class which dimensions can be grabbed
>> from.
>> I did read a while ago about something on Windows where there is a
>> requirement to get into the App Store that an app notices high density
>> (i.e. phone/tablet) screens and scales text appropriately, but I can't
>> remember the details.
>>
>> However, if we decide we have no interest in matching the size of text
>> to an actual metric like mm, then we should remove that from the
>> documentation. The problem then becomes, what do we put in it's place?
>> Having something like "plplot uses an arbitrary and undocumented font
>> scaling which is approximately the same for all drivers but is not
>> linked to any physical dimension of the plot" obviously isn't
>> satisfactory but that is basically what we are doing.
>
>
> Good point.  The semiempirical approach tries to avoid opening this
> can of worms, but you are likely correct we should clean up this mess.
> Since using actual DPI values for each monitor
> used by our users is impossible for the reasons I stated, then probably the
> documented goal (although the documentation should state this is
> not realized yet for all device drivers) should be that PLplot does pixel
> to metric conversions based on a xdpi and ydpi specified by the
> user (via the existing -dpi command-line option or equivalent plspage call)
> or by the default dpi value set by PLplot.
>
> To implement that last, I suggest that default value (note, using 90 for
> that default value seems OK to me) should be specified as follows:
>
> #define PLPLOT_DEFAULT_DPI 90
>
> in include/plplot.h and
>
> plsc->xdpi = PLPLOT_DEFAULT_DPI;
> plsc->ydpi = PLPLOT_DEFAULT_DPI;
>
> in plstrm_init (which initialises all streams).
>
> If you agree with this approach for setting default PLplot-wide
> plsc->xdpi and plsc->ydpi values will you please push a commit to this
> effect to get this preliminary out of the way?

This seems perfectly sensible to me. I will make this change and commit it.

Phil

Re: [Plplot-devel] The 5-week window of opportunity for the current (post-5.11.1) release cycle

[Alan W. I. <ir...@be...>]

On 2015-08-20 14:43+0100 Phil Rosenberg wrote:

>>> 1) Text size. As far as I am aware the text size in wxWidgets is
>>> entirely correct - I haven't double checked this today, but this was
>>> the case last time I checked. The docs state that the text size
>>> provided by the user is in mm, and I use a value of 90 pixels per inch
>>> (converted to metric) to convert to pixels. Counting pixels on the
>>> screen it appears that the output is as I intended. The pixels per
>>> inch value I used is the same as used by inkscape - so the wxWidgets
>>> output should have similar sized text to the svg output rendered by
>>> inkscape. However as you can find online (e.g.
>>>
>>> http://stackoverflow.com/questions/1346922/svg-and-dpi-absolute-units-and-user-units-inkscape-vs-firefox-vs-imagemagick)
>>> different svg renderers assume different pixels per inch in their
>>> rendering. However if other drivers are providing text that is 2.2
>>> times the size of that in wxWidgets they must be assuming around 40
>>> pixels per inch which is much lower than any other standard I have
>>> seen.
>>> Basically where I am going is that we should set a standard value for
>>> pixels per inch for all raster drivers. It would potentially be useful
>>> to have an API call to set the pixels per inch too. Then each driver
>>> can be checked to make sure it conforms - perhaps with the Peace
>>> example being used to check.
>>
>>
>> I am old school scientist on this issue on the one hand, and completely
>> semiempirical on the other.  :-)
>>
>> I. Old school:
>>
>> Pixels per mm (and therefore pixels per inch or DPI) should not be an
>> assumption.  Your monitor has a definite resolution in pixels and a
>> definite size in mm so therefore it has a known value for pixels per
>> mm and DPI in both X and Y.
>>
>> However, there are some important caveats about this for the
>> Linux/X11 case see
>> <http://unix.stackexchange.com/questions/75344/how-does-x-server-calculate-dpi>.
>>
>> That reference does not mention xrandr which is one way to determine
>> actual DPI for the Linux/X11 case.
>>
>> irwin@raven> xrandr |grep " connected"
>> HDMI-1 connected 1440x900+0+0 (normal left inverted right x axis y
>> axis) 410mm x 256mm
>>
>> I verified those dimensions with a meter stick since my monitor manual
>> does not include the actual display dimensions.
>>
>> Those results imply actual XDPI is
>>
>> irwin@raven> echo "1440*25.4/410" |bc -l
>> 89.20975609756097560975
>>
>> and YDPI is
>>
>> irwin@raven> echo "900*25.4/256" |bc -l
>> 89.29687500000000000000
>>
>> So those appear to be reasonably reliable numbers for DPI for my
>> monitor, but as the discussion in the above URL states, the xdpyinfo
>> application does _not_ provide reliable DPI information.
>>
>> irwin@raven> xdpyinfo | grep -E 'dimensions|resolution'
>>   dimensions:    1440x900 pixels (381x238 millimeters)
>>   resolution:    96x96 dots per inch
>>
>> That is, that app does report the correct pixels for the monitor, but
>> arbitrarily fakes the size in millimeters to always return fake DPI
>> values of 96!  I have read web assertions that these fake values are
>> simply an attempt to follow a fake DPI "standard" set by Microsoft
>> Windows, but I don't know that is the case.
>>
>> So PLplot could in theory (for at least the Linux/X11 xrandr case) be
>> able to interrogate the operating system to determine the actual
>> pixels per mm values and then use those values for all rendering that
>> is done in units of mm.  But just because the xrandr-derived value was
>> correct in my case does not mean is will be correct in all cases, and
>> there is also concern about what to do for other platforms. So I doubt
>> very much we will go there.
>>
>> Another approach might be to assume some reasonable DPI value and then
>> attempt to enforce that for each of our device drivers. But that might
>> be tricky for our device drivers like qt and cairo which depend on
>> external libraries which might have their own independent standards
>> about what to assume for DPI value.  So for now and perhaps
>> indefinitely, I think we are stuck with the semiempirical approach
>> below.
>>
>> II.  Semiempirical.
>>
>> The semiempirical approach is simply to multiply the character size
>> for each device driver so it agrees reasonably with the others for the
>> second page of example 2.  That is, the numbers on that page should be
>> fairly closely inscribed by the inner square.
>>
>> I have just looked at that page for a wide variety of our devices, and
>> they all pass this test more or less except for wxwidgets where the
>> numbers are roughly half the size of the inner square.  So it is on
>> that basis I suggest you approximately double the character size to
>> match more closely what the other devices do here.
>>
>>
>
> HI Alan, in some ways I am fine with that. I think actually wxWidgets
> has a cross platform display class which dimensions can be grabbed
> from.
> I did read a while ago about something on Windows where there is a
> requirement to get into the App Store that an app notices high density
> (i.e. phone/tablet) screens and scales text appropriately, but I can't
> remember the details.
>
> However, if we decide we have no interest in matching the size of text
> to an actual metric like mm, then we should remove that from the
> documentation. The problem then becomes, what do we put in it's place?
> Having something like "plplot uses an arbitrary and undocumented font
> scaling which is approximately the same for all drivers but is not
> linked to any physical dimension of the plot" obviously isn't
> satisfactory but that is basically what we are doing.

Good point.  The semiempirical approach tries to avoid opening this
can of worms, but you are likely correct we should 
clean up this mess.  Since using actual DPI values for each monitor
used by our users is impossible for the reasons I stated, then probably the
documented goal (although the documentation should state this is
not realized yet for all device drivers) should be that PLplot does pixel
to metric conversions based on a xdpi and ydpi specified by the
user (via the existing -dpi command-line option or equivalent plspage call)
or by the default dpi value set by PLplot.

To implement that last, I suggest that default value (note, using 90 for
that default value seems OK to me) should be specified as follows:

#define PLPLOT_DEFAULT_DPI 90

in include/plplot.h and

plsc->xdpi = PLPLOT_DEFAULT_DPI;
plsc->ydpi = PLPLOT_DEFAULT_DPI;

in plstrm_init (which initialises all streams).

If you agree with this approach for setting default PLplot-wide
plsc->xdpi and plsc->ydpi values will you please push a commit to this
effect to get this preliminary out of the way?

Here is the current status for how drivers use plspage (where if the
first two arguments are zero, user-defined or default DPI values are
not overridden, but otherwise they are overriden).

software@raven> grep plspage drivers/*
drivers/cgm.c:// or plspage
drivers/cgm.c:        plspage( 0., 0., 800, 600, 0, 0 );
drivers/cgm.c:        plspage( 4. * 25.4, 4. * 25.4, 0, 0, 0, 0 );
drivers/deprecated_wxwidgets.cpp:        plspage( 0.0, 0.0, (PLINT) ( CANVAS_WIDTH * DEVICE_PIXELS_PER_IN ),
drivers/deprecated_wxwidgets.cpp:    plspage( VIRTUAL_PIXELS_PER_IN / dev->scalex, VIRTUAL_PIXELS_PER_IN / dev->scaley, 0, 0, 0, 0 );
drivers/deprecated_wxwidgets_app.cpp:        plspage( 0.0, 0.0, width, height, 0, 0 );
drivers/deprecated_wxwidgets_app.cpp:        //plspage( 0., 0., width, height, 0, 0 );
drivers/gd.c:// or plspage
drivers/gd.c:        plspage( 0., 0., 800, 600, 0, 0 );
drivers/gd.c:        plspage( 4. * 25.4, 4. * 25.4, 0, 0, 0, 0 );
drivers/gd.c:// or plspage
drivers/gd.c:        plspage( 0., 0., 800, 600, 0, 0 );
drivers/gd.c:        plspage( 4. * 25.4, 4. * 25.4, 0, 0, 0, 0 );
drivers/pdf.c:    plspage( DEVICE_PIXELS_PER_INCH, DEVICE_PIXELS_PER_INCH,
drivers/svg.c:    // Set the bounds for plotting in points (unit of 1/72 of an inch).  Default is SVG_Default_X points x SVG_Default_Y points unless otherwise specified by plspage or -geometry option.
drivers/tkwin.c:// size: pls->xlength, pls->ylength (use plspage() or -geo option)
drivers/wingcc.c:        // or plspage
drivers/wingcc.c:        plspage( 0., 0., 800, 600, 0, 0 );
drivers/wingcc.c:        plspage( GetDeviceCaps( dev->hdc, HORZRES ) / GetDeviceCaps( dev->hdc, HORZSIZE ) * 25.4,
drivers/wxwidgets_dev.cpp:    // the user might have already set this with plspage
drivers/wxwidgets_dev.cpp:        c_plspage( 90, 90, 900, 675, 0, 0 );
drivers/wxwidgets_dev.cpp:            c_plspage( 90, 90, 0, 0, 0, 0 );
drivers/xwin.c:// size: pls->xlength, pls->ylength (use plspage() or -geo option)

So most of our device drivers and especially our "best" drivers (e.g.,
svg, qt, and cairo) do not attempt to override user-set or default
(above) dpi values, and assuming you implement the above suggestion,
then the only change to wxwidgets would be setting the first two
arguments of plspage to 0., to use the default (or user-set) dpi
values instead of wxwidgets-specific values of 90 regardless of what
the user sets.

And then the hard slogging begins for each maintainer of a device
driver to (a) review whether it is really necessary to override
default or user-set dpi values as occurs for all plspage calls above
with non-zero first two arguments, and (b) honoring the dpi values
that have been set by default or by the user. It sounds like this
might all just work fine for the new wxwidgets device driver with the
changes above I have recommended, and I also notice lots of
dpi-related logic for drivers/qt.cpp so that device driver may be OK,
but drivers/cairo.c doesn't have anything relevant to dpi that I can
find so presumably there will be lots of work to do by whoever
(Hazen?) is maintaining that device driver.

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-devel] The 5-week window of opportunity for the current (post-5.11.1) release cycle

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

>> 1) Text size. As far as I am aware the text size in wxWidgets is
>> entirely correct - I haven't double checked this today, but this was
>> the case last time I checked. The docs state that the text size
>> provided by the user is in mm, and I use a value of 90 pixels per inch
>> (converted to metric) to convert to pixels. Counting pixels on the
>> screen it appears that the output is as I intended. The pixels per
>> inch value I used is the same as used by inkscape - so the wxWidgets
>> output should have similar sized text to the svg output rendered by
>> inkscape. However as you can find online (e.g.
>>
>> http://stackoverflow.com/questions/1346922/svg-and-dpi-absolute-units-and-user-units-inkscape-vs-firefox-vs-imagemagick)
>> different svg renderers assume different pixels per inch in their
>> rendering. However if other drivers are providing text that is 2.2
>> times the size of that in wxWidgets they must be assuming around 40
>> pixels per inch which is much lower than any other standard I have
>> seen.
>> Basically where I am going is that we should set a standard value for
>> pixels per inch for all raster drivers. It would potentially be useful
>> to have an API call to set the pixels per inch too. Then each driver
>> can be checked to make sure it conforms - perhaps with the Peace
>> example being used to check.
>
>
> I am old school scientist on this issue on the one hand, and completely
> semiempirical on the other.  :-)
>
> I. Old school:
>
> Pixels per mm (and therefore pixels per inch or DPI) should not be an
> assumption.  Your monitor has a definite resolution in pixels and a
> definite size in mm so therefore it has a known value for pixels per
> mm and DPI in both X and Y.
>
> However, there are some important caveats about this for the
> Linux/X11 case see
> <http://unix.stackexchange.com/questions/75344/how-does-x-server-calculate-dpi>.
>
> That reference does not mention xrandr which is one way to determine
> actual DPI for the Linux/X11 case.
>
> irwin@raven> xrandr |grep " connected"
> HDMI-1 connected 1440x900+0+0 (normal left inverted right x axis y
> axis) 410mm x 256mm
>
> I verified those dimensions with a meter stick since my monitor manual
> does not include the actual display dimensions.
>
> Those results imply actual XDPI is
>
> irwin@raven> echo "1440*25.4/410" |bc -l
> 89.20975609756097560975
>
> and YDPI is
>
> irwin@raven> echo "900*25.4/256" |bc -l
> 89.29687500000000000000
>
> So those appear to be reasonably reliable numbers for DPI for my
> monitor, but as the discussion in the above URL states, the xdpyinfo
> application does _not_ provide reliable DPI information.
>
> irwin@raven> xdpyinfo | grep -E 'dimensions|resolution'
>   dimensions:    1440x900 pixels (381x238 millimeters)
>   resolution:    96x96 dots per inch
>
> That is, that app does report the correct pixels for the monitor, but
> arbitrarily fakes the size in millimeters to always return fake DPI
> values of 96!  I have read web assertions that these fake values are
> simply an attempt to follow a fake DPI "standard" set by Microsoft
> Windows, but I don't know that is the case.
>
> So PLplot could in theory (for at least the Linux/X11 xrandr case) be
> able to interrogate the operating system to determine the actual
> pixels per mm values and then use those values for all rendering that
> is done in units of mm.  But just because the xrandr-derived value was
> correct in my case does not mean is will be correct in all cases, and
> there is also concern about what to do for other platforms. So I doubt
> very much we will go there.
>
> Another approach might be to assume some reasonable DPI value and then
> attempt to enforce that for each of our device drivers. But that might
> be tricky for our device drivers like qt and cairo which depend on
> external libraries which might have their own independent standards
> about what to assume for DPI value.  So for now and perhaps
> indefinitely, I think we are stuck with the semiempirical approach
> below.
>
> II.  Semiempirical.
>
> The semiempirical approach is simply to multiply the character size
> for each device driver so it agrees reasonably with the others for the
> second page of example 2.  That is, the numbers on that page should be
> fairly closely inscribed by the inner square.
>
> I have just looked at that page for a wide variety of our devices, and
> they all pass this test more or less except for wxwidgets where the
> numbers are roughly half the size of the inner square.  So it is on
> that basis I suggest you approximately double the character size to
> match more closely what the other devices do here.
>
>

HI Alan, in some ways I am fine with that. I think actually wxWidgets
has a cross platform display class which dimensions can be grabbed
from.
I did read a while ago about something on Windows where there is a
requirement to get into the App Store that an app notices high density
(i.e. phone/tablet) screens and scales text appropriately, but I can't
remember the details.

However, if we decide we have no interest in matching the size of text
to an actual metric like mm, then we should remove that from the
documentation. The problem then becomes, what do we put in it's place?
Having something like "plplot uses an arbitrary and undocumented font
scaling which is approximately the same for all drivers but is not
linked to any physical dimension of the plot" obviously isn't
satisfactory but that is basically what we are doing.

One item of note - and this is based on memory, not recent checking.
But I think on initialisation the scale parameter for text is set as a
nonlinear function of the plot size. It could be that the disparities
are to do with the fact that the plots are different sizes and this
nonlinearity, rather than the fact that either is doing anything
wrong.

Phil

Re: [Plplot-devel] The 5-week window of opportunity for the current (post-5.11.1) release cycle

[Alan W. I. <ir...@be...>]

Hi Phil:

On 2015-08-19 12:01+0100 Phil Rosenberg wrote:

> Hi Alan
> Congratulations on getting that release out.

You are welcome.

> On with the next one!
>>
>> Currently I am aware of the following development possibilities for
>> this release cycle:
>>
>> 1. Phil has already prepared an important memory management fix for
>> wxwidgets, and I assume he will also want to deal with some/all of the
>> remaining wxwidgets bugs.
>
> I will push that fix as soon as I get chance.

I look forward to that push.

I just discovered another serious issue for wxwidgets which is it
sometimes just hangs depending on when a PLplot example that uses -dev
wxwidgets is launched and other things going on at the time.  For
example, my interactive comprehensive test had no trouble with this
issue prior to release. However, post-release I reorganized that
script to do interactive tests in a more concentrated matter, and
under those changed conditions wxwidgets hangs occur and make it
impossible to finish the interactive comprehensive test unless
wxwidgets is excluded from the interactive testing.

I assume the hangs are due to something going wrong with IPC between
app and wxPLViewer on Linux.  Once you get your memory management fix
pushed, I will attempt to figure out a simple way to demonstrate the
hangs so it will make it much easier for you to verify the issue.

> Thanks for the testing
> and the bug reports. I will spend my time this release cycle working
> on these. However there are two points I would like to bring up:
>
> 1) Text size. As far as I am aware the text size in wxWidgets is
> entirely correct - I haven't double checked this today, but this was
> the case last time I checked. The docs state that the text size
> provided by the user is in mm, and I use a value of 90 pixels per inch
> (converted to metric) to convert to pixels. Counting pixels on the
> screen it appears that the output is as I intended. The pixels per
> inch value I used is the same as used by inkscape - so the wxWidgets
> output should have similar sized text to the svg output rendered by
> inkscape. However as you can find online (e.g.
> http://stackoverflow.com/questions/1346922/svg-and-dpi-absolute-units-and-user-units-inkscape-vs-firefox-vs-imagemagick)
> different svg renderers assume different pixels per inch in their
> rendering. However if other drivers are providing text that is 2.2
> times the size of that in wxWidgets they must be assuming around 40
> pixels per inch which is much lower than any other standard I have
> seen.
> Basically where I am going is that we should set a standard value for
> pixels per inch for all raster drivers. It would potentially be useful
> to have an API call to set the pixels per inch too. Then each driver
> can be checked to make sure it conforms - perhaps with the Peace
> example being used to check.

I am old school scientist on this issue on the one hand, and completely
semiempirical on the other.  :-)

I. Old school:

Pixels per mm (and therefore pixels per inch or DPI) should not be an
assumption.  Your monitor has a definite resolution in pixels and a
definite size in mm so therefore it has a known value for pixels per
mm and DPI in both X and Y.

However, there are some important caveats about this for the
Linux/X11 case see
<http://unix.stackexchange.com/questions/75344/how-does-x-server-calculate-dpi>.

That reference does not mention xrandr which is one way to determine
actual DPI for the Linux/X11 case.

irwin@raven> xrandr |grep " connected"
HDMI-1 connected 1440x900+0+0 (normal left inverted right x axis y
axis) 410mm x 256mm

I verified those dimensions with a meter stick since my monitor manual
does not include the actual display dimensions.

Those results imply actual XDPI is

irwin@raven> echo "1440*25.4/410" |bc -l
89.20975609756097560975

and YDPI is

irwin@raven> echo "900*25.4/256" |bc -l
89.29687500000000000000

So those appear to be reasonably reliable numbers for DPI for my
monitor, but as the discussion in the above URL states, the xdpyinfo
application does _not_ provide reliable DPI information.

irwin@raven> xdpyinfo | grep -E 'dimensions|resolution'
   dimensions:    1440x900 pixels (381x238 millimeters)
   resolution:    96x96 dots per inch

That is, that app does report the correct pixels for the monitor, but
arbitrarily fakes the size in millimeters to always return fake DPI
values of 96!  I have read web assertions that these fake values are
simply an attempt to follow a fake DPI "standard" set by Microsoft
Windows, but I don't know that is the case.

So PLplot could in theory (for at least the Linux/X11 xrandr case) be
able to interrogate the operating system to determine the actual
pixels per mm values and then use those values for all rendering that
is done in units of mm.  But just because the xrandr-derived value was
correct in my case does not mean is will be correct in all cases, and
there is also concern about what to do for other platforms. So I doubt
very much we will go there.

Another approach might be to assume some reasonable DPI value and then
attempt to enforce that for each of our device drivers. But that might
be tricky for our device drivers like qt and cairo which depend on
external libraries which might have their own independent standards
about what to assume for DPI value.  So for now and perhaps
indefinitely, I think we are stuck with the semiempirical approach
below.

II.  Semiempirical.

The semiempirical approach is simply to multiply the character size
for each device driver so it agrees reasonably with the others for the
second page of example 2.  That is, the numbers on that page should be
fairly closely inscribed by the inner square.

I have just looked at that page for a wide variety of our devices, and
they all pass this test more or less except for wxwidgets where the
numbers are roughly half the size of the inner square.  So it is on
that basis I suggest you approximately double the character size to
match more closely what the other devices do here.


> 2) The second point is to do with alignment. Does anybody on the list
> have a thorough understanding of how the various alignment and aspect
> ratio variables (are intended to) interact? I have fought through
> these more than once now and yet on Linux and Windows I am getting
> different results - which in itself is baffling. This might be the
> cause of the text alignment problems. Changing to a floating point
> coordinate system might help as it will remove one level of scaling,
> but I currently don't understand how all the core scaling variables
> work.

I cannot help you with the inner details of PLplot on that matter, but
if you get different alignment for Linux and Windows results for the
wxwidgets device driver, that is very likely a bug in the wxwidgets
library and not a bug in the wxwidgets device driver.  And similarly
for our qt and cairo device drivers if you get different alignment for
those results depending on platform.

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-devel] The 5-week window of opportunity for the current (post-5.11.1) release cycle

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

 Hi Alan
Congratulations on getting that release out. On with the next one!
>
> Currently I am aware of the following development possibilities for
> this release cycle:
>
> 1. Phil has already prepared an important memory management fix for
> wxwidgets, and I assume he will also want to deal with some/all of the
> remaining wxwidgets bugs.

I will push that fix as soon as I get chance. Thanks for the testing
and the bug reports. I will spend my time this release cycle working
on these. However there are two points I would like to bring up:

1) Text size. As far as I am aware the text size in wxWidgets is
entirely correct - I haven't double checked this today, but this was
the case last time I checked. The docs state that the text size
provided by the user is in mm, and I use a value of 90 pixels per inch
(converted to metric) to convert to pixels. Counting pixels on the
screen it appears that the output is as I intended. The pixels per
inch value I used is the same as used by inkscape - so the wxWidgets
output should have similar sized text to the svg output rendered by
inkscape. However as you can find online (e.g.
http://stackoverflow.com/questions/1346922/svg-and-dpi-absolute-units-and-user-units-inkscape-vs-firefox-vs-imagemagick)
different svg renderers assume different pixels per inch in their
rendering. However if other drivers are providing text that is 2.2
times the size of that in wxWidgets they must be assuming around 40
pixels per inch which is much lower than any other standard I have
seen.
Basically where I am going is that we should set a standard value for
pixels per inch for all raster drivers. It would potentially be useful
to have an API call to set the pixels per inch too. Then each driver
can be checked to make sure it conforms - perhaps with the Peace
example being used to check.

 2) The second point is to do with alignment. Does anybody on the list
have a thorough understanding of how the various alignment and aspect
ratio variables (are intended to) interact? I have fought through
these more than once now and yet on Linux and Windows I am getting
different results - which in itself is baffling. This might be the
cause of the text alignment problems. Changing to a floating point
coordinate system might help as it will remove one level of scaling,
but I currently don't understand how all the core scaling variables
work.

Phil

[Plplot-devel] The 5-week window of opportunity for the current (post-5.11.1) release cycle

[Alan W. I. <ir...@be...>]

To all developers here:

5.11.1 has been released.  (For more details about that release, see
the announcement on plplot-general.)

During the release process I discovered and fixed a pretty obvious but
long-standing oversight (no D or Lua source code) for our website. I
think such oversights just slip through because most of us are too
familiar with our website to recognize any issues with it. So I would
appreciate it if those here who are fairly new to our website or who
feel they have a good critical eye to look carefully at our website to
see if can spot any other oversights or errors that should be fixed.

The 5.11.1 release means the release-related freeze is now gone, and I
highly encourage you to push your matured topic branches to master for
(a) thorough testing by all of us as we use the git master branch
version of PLplot for our daily plot use and for comprehensive tests,
and (b) inclusion in the next release.  I plan to reinstate a soft
freeze (no more pushes of big code changes) in mid-September to allow
for plenty of testing time for such changes between then and the next
release date (roughly 4 months from now).

Currently I am aware of the following development possibilities for
this release cycle:

1. Phil has already prepared an important memory management fix for
wxwidgets, and I assume he will also want to deal with some/all of the
remaining wxwidgets bugs.

2. Arjen is in the middle of a complete rewrite of our f95 bindings.

3. Jim is developing a new interactive device driver for Windows
and has plans to create new plmeta capability which will be
based on substantial changes to the plbuf code.

4. I hope for this release cycle to make a substantial fill fix, update epa_build,
improve CMake exporting of PLplot targets, and fix Ada language
support issues on Cygwin and MSYS2.  And, of course, deal with any
Build-system issues that are turned up by on-going comprehensive testing
on all platforms.

If the above summary isn't quite right I encourage Phil, Arjen, and
Jim to reword the summary here, and if anyone else has possible
development plans to add to this summary, please do that.

I doubt we will all get everything done from the above list in the
next 5 weeks before the soft freeze occurs, but I do hope we can all
make a substantial dent in this list during this window of
opportunity.

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-devel] Status of 5.11.1 release

[Alan W. I. <ir...@be...>]

The current status is the release process is still continuing and the
associated hard freeze (except for no-brainer fixes, etc.) on pushes
to master is still in effect.  I believe the rest of the release
process should be fairly routine so I hope to get out the release
late today if other constaints on my time permit that.

I thank Tom Schoonjans for a no-brainer fix which I have
pushed (commit id f3f22e8).

@Phil:

As part of due diligence for this release I did the following test of
wxwidgets yesterday:

# Prepare all needed prerequisites for the test below
make -j4 test_c_psc; make -j4 wxwidgets

# Must move to this directory in the build tree so that
# the lena image (automatically generated by the above preparation
# of prerequisties) will be found by example 20.
cd examples

# Run each of our C examples (built above) with -dev wxwidgets and
# take the time to look at every page of every example for any rendering
# issues.  The "read ANSWER" command below is simply a device to allow
# you to pause between each of the examples (and continue by hitting
# any key).

for SEQ in $(seq -w 0 33); do
   echo $SEQ
   c/x${SEQ}c -dev wxwidgets
   read ANSWER
done

As a result of these tests (done with Debian oldstable = Debian wheezy
with the system version 2.8.12.1-12 of the wxwidgets libraries), I
discovered that due to the wxwidgets changes you have made in this
release cycle some of the bugs mentioned in our composite bug 151
report have now been fixed, but some new bugs have been introduced (or
else I am only noticing them for the first time).  Accordingly I have
closed bug 151 as outdated (and also because having a composite bug
report is a bad idea), and instead I have introduced 14 new
single-issue bug reports (bug 165 through bug 178) for wxwidgets for
the issues I noticed from the above test.

I hasten to add I don't think any of these issues is release critical,
but at the same time I believe cleaning up these 14 bugs is necessary
to make your new wxwidgets device driver of similar quality to the qt
and cairo device drivers.  Therefore, after the 5.11.1 release is
completed and after you have pushed your fix for the wxwidgets memory
management issue you discovered, I highly recommend you fix all these
14 bugs in a timely manner (with systematic repeats of the test above
for _all_ examples to make sure you can replicate the issues I have
found and also to make sure any given fix for one example does not
generate additional problems for other examples).

Note if you are having trouble getting access to a POSIX Linux
platform (such as Ubuntu or CentOS) for the above tests, I am pretty
sure from the success of Arjen's comprehensive testing on Cygwin and
Greg Jung's comprehensive testing on Cygwin and mingw-w64-x86_64/MSYS2
that the above test will also work fine on either of those platforms.

@Everybody:

I have recently (commit id = 4f49d20) updated the release notes
(README.release) to say something about the success on Cygwin and
mingw-w64-x86_64/MSYS2. That latter Windows platform has only been
around for a couple of years but it provides almost as many PLplot
soft prerequisites as Cygwin does, provides native Windows results
(i.e., the results do not depend on the MSYS2 dll unlike Cygwin where
the results do depend on the Cygwin dll), and already has huge and
still exponentially growing popularity according to SF download
statistics. So I am very pleased that Greg Jung has discovered that
PLplot builds and tests work so well on this platform. Thanks, Greg,
for all the testing iterations you put in to achieve this result!

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-devel] Status of 5.11.1 release

[Alan W. I. <ir...@be...>]

@ Everybody:

The release is on a temporary (short) hold to allow me to fix a small build
system issue that a last-minute comprehensive test of the
-DOLD_WXWIDGETS=ON case has demonstrated.

@Arjen and Greg:

I have just now (9653b7c) committed a description of recent
comprehensive testing in README.release.  These tables of results (in
SourceForge markdown format) will be propagated to our wiki once the
bugs in the recently introduced SF markdown editor that I have
discussed before have been fixed.

Please take a look at these results to make sure I represented your
work correctly.  You should take care to look at the table notes and
especially the important distinctions I make there concerning platform
constraints ("not available"), arbitrary constraints imposed by the
tester to simplify testing ("not installed" or "ignored"), or explicit
workarounds for PLplot issues for the platform ("disabled").

@Greg: Please note I did not include your recent comprehensive testing
of openSUSE because I view that effort as not completed yet.  For
example, more openSUSE packages need to be installed to support
additional components of PLplot for the testing, and your existing
script test results failed in a peculiar way at the very last hurdle
(static libraries, traditional build _cleanup_ failed). Once we get
these last comprehensive testing issues sorted out for openSUSE I will
be happy to insert the relevant table in README.release for our next
release and also in our Wiki (once that can be edited).

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-devel] Status of 5.11.1 release

[Alan W. I. <ir...@be...>]

On 2015-08-02 00:04-0700 Alan W. Irwin wrote:

> Anyhow, I am hoping for a quick response from SF staff concerning how
> they can make it possible to update complex wiki pages like ours again
> (e.g., by giving us the option to use the old editor that actually
> works), but if I don't get that quick response, I guess as a temporary
> measure, I could put all the markdown format for tables filled with
> recent comprehensive test reports from Arjen, Greg, and myself
> directly into our release notes and copy those markdown data to our
> wiki later when it is finally possible to do so.

I finally got a response, see comments for
<https://sourceforge.net/blog/introducing-sourceforges-new-markdown-text-editor/>

They are actively working on resolving the biggest issue (mislocated
cursor position in certain cases) I reported.  But I sense that
resolution will not be quick.

Furthermore, it appears the mouse select and middle button paste
issues are known, but resolution will be slow.  The new SourceForge
markdown editor uses the CodeMirror library which exposes a firefox
(and presumably konqueror) bug concerning mouse select and middle
button paste.

Therefore, my plan now is to go ahead with the release (starting today
but probably finishing tomorrow) using the idea of putting our
comprehensive test reports directly into the release notes using
SourceForge markdown table format.

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-devel] Status of 5.11.1 release

[Alan W. I. <ir...@be...>]

On 2015-08-01 12:52-0700 Alan W. Irwin wrote:

> Just to keep you guys informed, it looks doubtful that I will be able
> to finish the release process today, but I hope to finish that tomorrow.

Update: one of the first essential items is to update comprehensive
test results on our Wiki so our release notes can just refer to that
wiki item, but SF has just deployed a new markdown editor that 
completely sucks/is unusable for complex wiki pages like ours.  That
"completely sucks/unusable" phrase is not hyperbole.  For example, the
cursor position is misidentified so if you try to insert a line of
text at what appears to be the cursor position it actually appears 5
lines higher in the editing GUI for the tables part of the page I was
attempting to edit.  (This occurs for both konqueror and iceweasel
(the Debian form of firefox.) Elsewhere in that page the cursor is
correctly identified.  So nothing is predictable.  Similarly, any
attempt to delete stuff ends up deleting the wrong stuff.  And the
usual normal cut and paste with the mouse no longer works.  I have
been fighting with these issues for several hours today and have got
precisely nowhere.

Anyhow, I am hoping for a quick response from SF staff concerning how
they can make it possible to update complex wiki pages like ours again
(e.g., by giving us the option to use the old editor that actually
works), but if I don't get that quick response, I guess as a temporary
measure, I could put all the markdown format for tables filled with
recent comprehensive test reports from Arjen, Greg, and myself
directly into our release notes and copy those markdown data to our
wiki later when it is finally possible to do so.

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
__________________________

[Plplot-devel] Status of 5.11.1 release

[Alan W. I. <ir...@be...>]

Just to keep you guys informed, it looks doubtful that I will be able
to finish the release process today, but I hope to finish that tomorrow.

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
__________________________

[Plplot-devel] Parallel build issues on Windows platforms

[Alan W. I. <ir...@be...>]

There exist parallel build issues on the MinGW/MSYS, Cygwin, and
MinGW-w64/MSYS2 windows platforms (see below) so I have looked for
race conditions caused by ill-considered CMake logic in our build
system concerning target and file dependencies, but have not found
any instances of that (although the timing conditions of my tests
may just not be right to trigger such a race condition).

An example of such ill-considered logic is if you have two separate
custom targets file depend directly or indirectly on the same custom
command. Under these conditions, the custom command gets executed once
for each target which is normally not an issue for non-parallel builds
or parallel builds where the two custom targets happen to be executed
at separate times. However, when by chance the two custom targets are
being executed at the same time for parallel builds the resulting race
condition will cause substantial build issues.  We have lots of custom
commands and custom targets in our build so historically we have had a
lot of such race conditions to deal with.  But as far as I know (hah!)
CMake code review of the various custom commands and targets that are
generated has by now found them all.

Furthermore, here is a run-time test to discover whether any such race
conditions are occurring.  N.B. such race conditions critically depend
on timing (e.g., the N value used in the -jN make option, the hardware
platform, etc.) so this is a necessary but not sufficient test that we
have gotten rid of all such race conditions via CMake code review.

It turns out that even if race conditions that occur for a given
timing enviroment do not cause obvious build issues, they are still
easy to spot because each time a custom command is executed at build
time (whenever its OUTPUT files are non-existent or older than its
file depends), there is a correponding build message

Generating <list of OUTPUT files from the custom command>.

So that message will be duplicated if two separate custom targets
attempt to build the custom command at the same time, i.e., whenever
a race condition occurs for the given timing regardless of the symptoms
(or lack of symptoms) from such a race.

I have created the following set of commands to test for
duplicate messages of that form for both the test_noninteractive target
and the all target

# test_noninteractive target

# Do this test for an absolutely fresh build, i.e., cmake with
# -DBUILD_TEST=ON option in an initially empty build tree followed by
make -j4 test_noninteractive >& test_noninteractive.out
# Find essentially all occurrences of commands being run by looking for
# anything with "ing" with some exceptions.  Sort the result once
# without duplicates being eliminated and sort once with duplicates
# eliminated.
grep ing test_noninteractive.out |\
sed -e 's?\[.*\] ??g' |\
grep -vE 'Scanning|Differing|Missing' |\
grep -v bindings |\
grep -v "using command" |\
grep -v "Testing" |\
grep -v "switching to" |\
sort -u >| unique_builds.out

grep ing test_noninteractive.out |\
sed -e 's?\[.*\] ??g' |\
grep -vE 'Scanning|Differing|Missing' |\
grep -v bindings |\
grep -v "using command" |\
grep -v "Testing" |\
grep -v "switching to" |\
sort >| builds.out

# Compare the two results to see whether anything extra in builds.out
# compared to unique_builds.out
diff -au unique_builds.out builds.out |less

It turns out there is some extra data consisting of
duplicate instances of

Generating tclIndex

and duplicate instances of

Generating x00

and similarly for almost every other x?? file.

These all turned out to be false alarms.  The two tclIndex files are
actually created by distinct custom commands in bindings/tcl and
examples/tcl. And similarly the x?? files are actually created by
distinct custom commands in examples/python and examples/tcl.

The one peculiarity that I found from the above test is that

Generating x01
Generating x25
Generating x26

did not have duplicate instances.  However, I double checked that two
files were created in each case (one in examples/tcl and one in
examples/python) so the conclusion must be I have turned up a minor
bug in CMake (3.0.2) where it does not always emit a

Generating <filename>

message when a custom command generates an OUTPUT file at run time.

# all target

I also did the equivalent test for the "all" target starting from
an initially empty build tree with similar good results concerning
the lack of race conditions for the given timing conditions.

There were duplicate messages for

plgrid.tcl, plplot.tcl, tclIndex (4 instances instead of the 2 that
occurred for the test_noninteractive target), x??, and x??.tcl.

In all cases, further analysis showed these were all false alarms due to a
file with the same name being created by different custom commands in
different directories.

So my conclusion is there is no evidence of parallel build race
conditions for the "test_noninteractive" or "all" targets in the core
build tree for the given timing conditions which is a limited but
still satisfactory conclusion. Note at some point I should do a
similar test for the test_interactive target in the build tree and
also for the all, test_noninteractive, and test_interactive targets
for the installed examples, but I don't have time for that now.

The big motivation for the above experiment to look for parallel race
conditions is due to following parallel build issues that show up in
all our current comprehensive tests on various Windows platforms:

1. For my comprehensive test on MinGW/MSYS in the last release using
parallel builds with -j4, I ran into the following message intermittently (i.e.,
just once, and the repeat test did not encounter the problem)

make.exe error: "INTERNAL: Exiting with 1 jobserver tokens available;
should be 4!"

That along with the historical MSYS make.exe hangs for parallel builds (see
<https://sourceforge.net/p/mingw/bugs/1950/>) lead me to the
conclusion that for the most reliable results you should never use
parallel builds on the MinGW/MSYS platform. Arjen's recent test of
MinGW/MSYS followed that recommendation and (probably as a result) did
not have any build or ctest problems.  However, the above bug report
now claims the hang issue has finally been solved so it might be
worth it to experimentally try parallel builds on this platform when
we test it again some time in the next release cycle.

2. Greg Jung has also recently encountered a similar warning message
for -j4:

make: INTERNAL: Exiting with 3 jobserver tokens available; should be 4!

on MinGW-w64/MSYS2.  That build warning was
was accompanied by parallel
ctest just hanging until Greg killed the job.  Since then, Greg has had
no further trouble with the issue if he uses the

--ctest_command "ctest"
--build_command "make"
--traditional_build_command "make"

options to the comprehensive_test.sh script, i.e., drops both the
parallel build and parallel ctest on the MinGW-w64/MSYS2 platform.

3. Both Greg and Arjen have experienced the

make: INTERNAL: Exiting with 3 jobserver tokens available; should be 4!

warning on Cygwin.  However, that does not seem to interfere with parallel builds, and
parallel ctest works fine on that platform as well.

My conclusions are as follows:

* PLplot has no parallel build race conditions for the
   test_noninteractive and all targets that I can detect for the given
   timing conditions.  So this is a necessary test to prove no race
   conditions but not a conclusive test so we are still really relying
   on our CMake code review here to keep us out of race condition
   trouble for all timing conditions.

* Cygwin, MSYS, and MSYS2 make all emit warnings for parallel builds
   with -j4 consisting of messages similar to

make: INTERNAL: Exiting with 3 jobserver tokens available; should be 4!

Until the issue (most likely a Windows make.exe bug, but it could also
be a race condition for the given timings in each case) that causes
these warning messages is addressed, all parallel build results on
Cygwin, MinGW/MSYS, and MinGW-w64/MSYS2 should be viewed with some
suspicion.

* Parallel ctest hangs on MinGW-w64/MSYS.  It is currently not clear
if this is strictly a ctest issue or a byproduct of some parallel
build issue that occurred.  Therefore, more experimentation on this
platform post-release, e.g., with non-parallel build but parallel
ctest will be needed to help sort out the true cause of this issue.

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-devel] Need help with test_extXdrawable target regression introduced by "Fix to the multiple keypress bug on page advance"

[Alan W. I. <ir...@be...>]

On 2015-07-30 06:42-0400 Jim Dishaw wrote:

>> On Jul 30, 2015, at 6:36 AM, Jim Dishaw <ji...@di...> wrote:
[...]
>> That patch [to insert a XSynchronize call] fixes the problem when PLPlot is creating the window. Try adding one more inside the "then" case at line 1983.
>
> Oops, that won't work. I think the only solution right now is to roll back the patch.

>>> Jim, since the above idea does not appear to work do you see any issue
>>> with instead reverting your changes just for the cairo device driver
>>> using the attached patch?
>> That would work and we wouldn't be any worse off then we were before.

OK.  I have pushed [d64d9c6] for now to revert your "multiple keypress
bug on page advance" fix for the cairo device driver, and you should
be able to straightforwardly revert d64d9c6 post-release as a start to
finding the right approach for getting the multiple keypress bug on
page advance fixed for the cairo device driver without compromising
the test_extXdrawable target result.

Late in release cycles like this there is lots of time pressure on the
release manager to make quick decisions so my thanks for the immediate
responses you made to my questions about this tricky issue.

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
__________________________