plplot-devel

Re: [Plplot-devel] Is Qt5 supported?

[Andrew R. <and...@us...>]

On Sat, Mar 15, 2014 at 08:21:46PM +0000, Andrew Ross wrote:
> Yes, that is all with 5.2.0. I've run make test_all_qt and all the 
> targets work except test_qt_example. Note you need the QtImageFormats 
> module for the tiff format. The other bitmap formats are available by 
> default. If you don't install the module then plplot just generates 
> empty files with no warning, as I discovered the hard way.

Changes to get qt_example working are pretty small. Now works in the 
build tree. Just need to fix the install tree case too.

Andrew

Re: [Plplot-devel] Is Qt5 supported?

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

On 2014-03-15 21:08-0000 Andrew Ross wrote:

> On Sat, Mar 15, 2014 at 08:21:46PM +0000, Andrew Ross wrote:
>> Yes, that is all with 5.2.0. I've run make test_all_qt and all the
>> targets work except test_qt_example. Note you need the QtImageFormats
>> module for the tiff format. The other bitmap formats are available by
>> default. If you don't install the module then plplot just generates
>> empty files with no warning, as I discovered the hard way.
>
> Changes to get qt_example working are pretty small. Now works in the
> build tree. Just need to fix the install tree case too.

Hi Andrew:

Thanks for extending what Qt5 can do by knocking off that FIXME.

Assuming you want to continue extending our use of Qt5 there are 3
more issues to deal with to make our use of Qt5 as extensive as the
Qt4 case.

1. For the install-tree case you mentioned above, probably all you
have to do is to propagate the PLPLOT_USE_QT5 variable in
examples/plplot_configure.cmake_installed_examples.in.

2. For the pyqt4 case, all that you _might_ have to do is to remove my
PLPLOT_USE_QT5 test associated with the FIXME comment in
cmake/modules/qt.cmake.  I don't have a clue whether
bindings/qt_gui/pyqt4 will work or not with Qt5, but it is certainly
possible that directory name simply reflects what was available at the
time when that part of our build system was implemented and is not
actually a warning that it will only work with Qt4.

3. The other FIXME in cmake/modules/qt.cmake simply turns off the Qt
components of our traditional build system for the installed examples
for the Qt5 case.  If you turn that on again, you will likely have to
modify the configuration of examples/c++/Makefile.examples.in in order
to be able to build qt_example with our traditional (Makefile +
pkg-config) build system for the installed examples in the Qt5 case.

Note, if you don't currently have time to deal with all these issues,
I will try to deal with whatever is left after I get access to Qt5.

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] Is Qt5 supported?

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

On 2014-03-15 21:08-0000 Andrew Ross wrote:

> On Sat, Mar 15, 2014 at 08:21:46PM +0000, Andrew Ross wrote:
>> Yes, that is all with 5.2.0. I've run make test_all_qt and all the
>> targets work except test_qt_example. Note you need the QtImageFormats
>> module for the tiff format. The other bitmap formats are available by
>> default. If you don't install the module then plplot just generates
>> empty files with no warning, as I discovered the hard way.
>
> Changes to get qt_example working are pretty small. Now works in the
> build tree. Just need to fix the install tree case too.

Hi Andrew:

I just got the epa_build of "qt5_lite" to work (revision 13089) on
Linux. With that version (Qt-5.2.1), I confirmed your good test
results above for a system version of Qt-5.2.0 that you had access to.
(For further details of all the build- and run-time tests that I tried
see the revison 13089 commit message.)

I looked at all qt file device results for the first 5 standard
examples, and they all looked identical with each other (as expected)
for each page of those examples. I also checked for any zero-length
file device results, and there were none.  I also specifically looked
in detail at the pngqt file device results for all 33 of our standard
examples, and the only rendering issue I spotted is all text appears
to be vertically offset by ~half a character height compared to qt
device driver results with Qt4 and also cairo device driver results.

Do you confirm that offset with your system version of Qt5?

For some reason, there always seems to be arbitrary vertical offsets
we have to apply for text rendering and those offsets are different
for each major external library dependency such as Qt5 (or pango/cairo
or Qt4).

Fixing that issue (without destroying the good vertical offset for
text we already have for the Qt4 version of qt) is next on my agenda.

@Andrew and all others here with access to Linux or Mac OS X
platforms: when you get a chance could you follow up by doing your own
epa_build and test of qt5_lite? That epa_build currently takes an
hour, i.e., four times as long as the equivalent build of qt4_lite. I
strongly encourage any/all of you to modify the epa_build
configuration to drop unnecessary (to PLplot) components of Qt5 if you
spot some Qt5 configure option that I missed to do that.

@others here with access to Windows platforms:

With epa_build of qt5_lite now working so well on Linux, I need a
Windows volunteer to follow up by testing that epa_build configuration
(and adjusting it if required) on Windows following the directions in
cmake/epa_build/README.

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] Is Qt5 supported?

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

On 2014-03-31 17:11-0700 Alan W. Irwin wrote:

> [The only Qt5] rendering issue I spotted is all text appears
> to be vertically offset by ~half a character height compared to qt
> device driver results with Qt4 and also cairo device driver results.
>
> Do you confirm that offset with your system version of Qt5?
>
> For some reason, there always seems to be arbitrary vertical offsets
> we have to apply for text rendering and those offsets are different
> for each major external library dependency such as Qt5 (or pango/cairo
> or Qt4).
>
> Fixing that issue (without destroying the good vertical offset for
> text we already have for the Qt4 version of qt) is next on my agenda.

Done as of revision 13091.  The text rendering now looks a lot better
in the epa_built Qt5 case, but there are some minor caveats.  For details about
those, see the commit message.

@Andrew: IMPORTANT do you confirm reasonable looking vertical text alignment
for this revision and your system version of Qt5?

As part of this empirical vertical text alignment work, I completely
rewrote examples/python/test_circle.py (as of revision 13092) to
demonstrate any remaining vertical offset issues for many additional
UTF-8 glyphs beyond what was done before for the UTF-8 "large circle", "box
drawings light diagonal cross", "asterisk operator", and "ordinary
asterisk" glyphs.

My first discovery from these results (which I should have figured out
from the old version of this example but did not) is that the ordinary
asterisk is a very poor symbol to use for plotting points since font
designers apparently have a long artistic tradition of centering this
particular symbol substantially above the centre of the character box.
Replacing the ascii asterisk symbol, "*" used in standard examples 4,
26 and 33 with "#(728)" (which for both Hershey and Unicode fonts
translates to an asterisk operator glyph which has far superior
vertical alignment) gives much better looking results for those
standard examples.  I have already done this change for C and Python
locally and making the remaining example changes consistently for all
languages and commiting all these example changes is next on my
agenda.

The second discovery is that the Qt4, pango/cairo, and Qt5 libraries
all configure fontconfig differently to obtain the "best" system font
to render the requested unicode glyph.  The evidence for this is a
variety of glyph sizes and shapes for the three different cases as
well as occasional (i.e., the Korean glyphs in example 24) missing
glyphs in the Qt5 case which are not missing for the other two cases.
Note, that test_circle.py is extraorinarily sensitive to vertical
alignment issues; e.g., a vertical offset of 0.01 of the character
height can (just) be detected. So assuming the different font sets
have different artistic impressions of the correct vertical alignment
within the character box, you expect the slightly different vertical
alignment results in the three different cases that I have observed
with test_circle.py.

Given that caveat, the "artistic" variations in vertical alignment are
fairly small between the various fonts chosen in the three different
cases.  Furthermore, the dispersion in vertical alignment between the
various UTF-8 characters is smallest for our qt device driver (using
Qt4), next smallest for our cairo device, and largest (but still
probably acceptable) for our qt device driver (using Qt5). The first
two dispersion results were obtained with no mean empirical offset in
vertical text position, but the latter result was derived using a
substantial (more than half a character height) empirical offset that
best aligned the "box drawings light diagonal cross" glyph.
Presumably, whenever the Qt5 issues with font selection and vertical
alignment of characters are fixed so that there is consistency with
the same results for Qt4, that empirical offset will have to be
replaced by zero, but revision 13091 should be good enough for now
with epa_built Qt5.2.1 (and also system versions of Qt5.2.x if Andrew
confirms the vertical alignment is OK for his Qt5.2.x version).

Other Qt5 issues I have mentioned before are the following:

1. pyqt4 is disabled.  I don't have any sip or pyqt expertise
so we need a volunteer to look at this for the Qt5 case.

2. All Qt5 tests have so far only been done in the build tree for the
shared library/dynamic devices case.  Thus, our usual comprehensive
testing will likely reveal more Qt5 build-system issues that I plan to
deal with as second on my current agenda after the examples changes
mentioned above.

In addition, if I recall correctly there were a lot of difficulties
with font selection and the vertical alignment of text with early
versions of Qt4.x before it finally settled down, and it looks like
Qt5 (which is also in an early development stage) currently has these
issues as well. Thus, because of these Qt5 issues (and also because of
the two PLplot issues above) I am going to continue to label the
-DPLPLOT_USE_QT5=ON cmake option as experimental and leave it OFF by
default.  However, this option continues to improve (i.e., with the
present vertical alignment workaround for Qt5 vertical alignment
issues) so I encourage those here to test this option either with a
system version of Qt5 (if available) or an epa_built version of Qt5.

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] Is Qt5 supported?

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

On 2014-04-01 14:19-0700 Alan W. Irwin wrote:

> My first discovery from these results (which I should have figured out
> from the old version of this example but did not) is that the ordinary
> asterisk is a very poor symbol to use for plotting points since font
> designers apparently have a long artistic tradition of centering this
> particular symbol substantially above the centre of the character box.
> Replacing the ascii asterisk symbol, "*" used in standard examples 4,
> 26 and 33 with "#(728)" (which for both Hershey and Unicode fonts
> translates to an asterisk operator glyph which has far superior
> vertical alignment) gives much better looking results for those
> standard examples.  I have already done this change for C and Python
> locally and making the remaining example changes consistently for all
> languages and commiting all these example changes is next on my
> agenda.

Done as of revision 13093.

> [...]All Qt5 tests have so far only been done in the build tree for the
> shared library/dynamic devices case.  Thus, our usual comprehensive
> testing will likely reveal more Qt5 build-system issues [....]

This potential issue is now first on my agenda.

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] Is Qt5 supported?

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

@Hazen and others here: There are remarks about the conversion of our
SF repository from svn to git at the end.

@Andrew:
On 2014-04-02 00:46-0700 Alan W. Irwin wrote:

> On 2014-04-01 14:19-0700 Alan W. Irwin wrote:
>> [...]All Qt5 tests have so far only been done in the build tree for the
>> shared library/dynamic devices case.  Thus, our usual comprehensive
>> testing will likely reveal more Qt5 build-system issues [....]
>
> This potential issue is now first on my agenda.

Qt5 is handled very differently (as a CMake import library) than Qt4
by our build system, and (as expected above) comprehensive tests
tripped over build-system issues for the case of import libraries like
Qt5.  With some essential help from Steve Kelly on the CMake mailing
list I have finally solved most of those so I now (as of revision
13106) have achieved the first completely successful comprehensive
test of the -DPLPLOT_USE_QT5=ON case.

However, that comprehensive test success was only made possible
because for the -DPLPLOT_USE_QT5=ON case I disable pyqt4, and we need
a volunteer to fix that.

I currently also disable the build and test of qt_example for both the
traditional and CMake-based build systems for the installed examples.
Next (and last) on my immediate PLplot agenda is to make fundamental
build system changes so I can drop those workarounds while continuing
comprehensive testing success for the -DPLPLOT_USE_QT5=ON case.

IMPORTANT: After that last item on my immediate PLplot agenda is
completed in the next day or so, I plan to stop working directly on
PLplot for roughly a month or so. Instead, I plan to take time to get
out a long-promised maintenance release of libLASi and then finally
start working on the long-promised conversion of the timeephem project
from svn to git. The latter should help me become familiar with git
and assuming that experiment is a success and because no other PLplot
developers have strongly objected to the idea, then Hazen's plan is to
convert the PLplot repository at SourceForge from svn to git as soon
as (and if) I report timeephem conversion success.

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] Is Qt5 supported?

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

On 2014-04-20 23:40-0700 Alan W. Irwin wrote:

> I currently also disable the build and test of qt_example for both the
> traditional and CMake-based build systems for the installed examples.
> Next (and last) on my immediate PLplot agenda is to make fundamental
> build system changes so I can drop those workarounds while continuing
> comprehensive testing success for the -DPLPLOT_USE_QT5=ON case.

DONE as of revision 13112 (including all the epa_build updates
required to build Qt5 and comprehensively test it with PLplot).  The
only Qt5 issue left that I am aware of is pyqt4 which currently is
automatically disabled for the Qt5 case. Note, I didn't try testing
pyqt4 because I thought it would be Qt4-only just from the name.  But
I don't know that is the case. Anyhow, someone else with pyqt
expertise will have to investigate this issue.

> IMPORTANT: After that last item on my immediate PLplot agenda is
> completed in the next day or so, I plan to stop working directly on
> PLplot for roughly a month or so. Instead, I plan to take time to get
> out a long-promised maintenance release of libLASi and then finally
> start working on the long-promised conversion of the timeephem project
> from svn to git. The latter should help me become familiar with git
> and assuming that experiment is a success and because no other PLplot
> developers have strongly objected to the idea, then Hazen's plan is to
> convert the PLplot repository at SourceForge from svn to git as soon
> as (and if) I report timeephem conversion success.

Indeed, I am now done with all the PLplot projects I have planned for
this release cycle other than the adjustment of all our scripts from
using svn tools to using the equivalent git tools just before we
release. But obviously that release will be much later after I do the
two projects outside of PLplot that I mention above, Hazen converts
our repository to git, and we all have a chance to settle in to use
git routinely with PLplot development. However, during my time away
from PLplot development I will be monitoring this list in case there
are any short questions I can help with, and I also will be asking my
own questions about git here from time to time as I get up to speed
with 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
__________________________

[Plplot-devel] OnInit call in wxpng driver

[laurent B. <Lau...@un...>]

Hi,

I have got a programm in C++ with wxwidgets using plplot on windows 7. i 
want to save my plplot graph in a fucntion called FenetreHistogramme::Plot :
plotwindow->SavePlot(wxString("svg"),wxString("tt.svg"));
plotwindow->SavePlot(wxString("xfig"),wxString("tt.xfig"));
plotwindow->SavePlot(wxString("ps"),wxString("tt.ps"));
plotwindow->SavePlot(wxString("wxpng"),wxString("tt.png"));
svg, xfig and ps files are saved. With png my program because OnInit is 
called twice. Stack trace is
>	wxOpenCV.exe!wxOsgApp::OnInit() Ligne 498	C++
  	wxbase30ud_vc_custom.dll!wxAppConsoleBase::CallOnInit() Ligne 93	C++
  	wxwidgets.dll!install_buffer(PLStream * pls) Ligne 1301	C++
  	wxwidgets.dll!plD_line_wxwidgets(PLStream * pls, short x1a, short 
y1a, short x2a, short y2a) Ligne 630	C++
  	plplotd.dll!grline(short * x, short * y, int UNUSED_npts) Ligne 1272	C
  	plplotd.dll!plP_pllclp(int * x, int * y, int npts, int xmin, int 
xmax, int ymin, int ymax, void (short *, short *, int) * draw) Ligne 680	C
  	plplotd.dll!plP_line(short * x, short * y) Ligne 382	C
  	plplotd.dll!rdbuf_line(PLStream * pls) Ligne 481	C
  	plplotd.dll!plbuf_control(PLStream * pls, unsigned char c) Ligne 1035	C
  	plplotd.dll!plRemakePlot(PLStream * pls) Ligne 993	C
  	plplotd.dll!c_plreplot() Ligne 3361	C
  	plplotwxwidgetsd.dll!wxPLplotwindow::SavePlot(const wxString & 
devname, const wxString & filename) Ligne 179	C++
  	wxOpenCV.exe!FenetreHistogramme::Plot(char fenetreActive) Ligne 544	C++

How can I avoid this second call of OnInit?

Thanks for yours answers

[Plplot-devel] About svg

[laurent B. <Lau...@un...>]

Hi,

My program plot histogram using plplot and wxwidgets driver. On my 
screen plot is nice. When plot is saved in svg format I cannot see 
histogram with Inkscape.
I don't know svg format but If I change all stroke-width="0.000000e+000" 
with stroke-width="1" svg is OK in Inkscape.
In program I have define a width of  2( pls->width( 2 );) so
how can I solve this ?
Thanks for yours answers



In PS file histogram is good but it is a black white plot.

Re: [Plplot-devel] About svg

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

Hi Laurent,

I am not quite sure what is going on, but the code fragment suggests you have an integer pen width. Could you try with a floating-point pen width, i.e. "2.0" instead of "2" (without the " of course). I do not see any overloaded function that could be accepting an integer value, so it is little more than a wild hunch.

What version of Plplot are you using? Could you post the relevant actual code fragment? This often helps to avoid typos that might just clarify what is going on.

Note that there is a colour PostScript driver too, in case all else fails, this might be a workaround.

Regards,

Arjen

> -----Original Message-----
> From: laurent Berger [mailto:Lau...@un...]
> Sent: Thursday, August 14, 2014 2:40 PM
> To: plp...@li...
> Subject: [Plplot-devel] About svg
>
> Hi,
>
> My program plot histogram using plplot and wxwidgets driver. On my screen plot is
> nice. When plot is saved in svg format I cannot see histogram with Inkscape.
> I don't know svg format but If I change all stroke-width="0.000000e+000"
> with stroke-width="1" svg is OK in Inkscape.
> In program I have define a width of  2( pls->width( 2 );) so how can I solve this ?
> Thanks for yours answers
>
>
>
> In PS file histogram is good but it is a black white plot.
>
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

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] About svg

[laurent B. <Lau...@un...>]

Thanks you for your answer.
plplot 5.9.10, wxwidgets 3.0.0 visual studio 2012 C++
with  pls->width( 2.0 ); nothing changes.
You can download source file and svg, ps and xfig  here : 
perso.univ-lemans.fr/~berger/aqzersPLPLOT
My source code is :
wxPLplotstream* pls=plotwindow->GetStream();
int iMin=0,iMax=16383;

const size_t np=65536;
if (x[0]==NULL)
     for (int i=0;i<3;i++)
         {
         x[i]=new PLFLT[np];
         y[i]=new PLFLT[np];
         yFiltre[i]=new PLFLT[np];
         }
PLFLT xmin=iMin, xmax=iMax;
PLFLT ymin=1e30, ymax=-1e30;
....

pls->adv( 0 );
pls->scol0 (    3, 0,0,255);
pls->scol0 (    4, 0,0,128);
pls->scol0 (    5, 0,255,0);
pls->scol0 (    6, 0,128,0);
pls->scol0 (    7, 255,0,0);
pls->scol0 (    8, 128,0,0);

if(bgcolor)
     {
     pls->scol0( 0, 255, 255, 255 );
     pls->scol0( 15, 0, 0, 0 );
     }
else
     {
     pls->scol0( 15, 255, 255, 255 );
     pls->scol0( 0, 0, 0, 0 );
     }
pls->col0( 1 );
pls->env( xmin, xmax, ymin*.99, ymax*1.01, 0, 0 );
pls->col0( 2 );
pls->lab( "x", "y", "Histogram");
for (int j=0;j<nbPlan;j++)
     {
         pls->col0( 3+2*j);
         pls->width( 2.0 );
         pls->line( nbGraines[j], x[j], y[j] );
         pls->col0( 4+2*j);
         pls->width( 3.0 );
         pls->line( nbGraines[j], x[j], yFiltre[j] );
     }
pls->RenewPlot();
Refresh();
plotwindow->SavePlot(wxString("svg"),wxString("tt.svg"));
plotwindow->SavePlot(wxString("xfig"),wxString("tt.xfig"));
plotwindow->SavePlot(wxString("ps"),wxString("tt.ps"));
//plotwindow->SavePlot(wxString("wxpng"),wxString("tt.png")); BUG

Re: [Plplot-devel] About svg

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

Hi Laurent,
The odd thing is that the SVG plots produced _directly_ with one of the standard examples shows all the right line widths. It must be that the replot function (called in plotwindow->SavePlot(..)) is faulty - the line width might not be set properly. It is not an area of Plplot I am familiar with though. (I am still trying to figure out where the pls->width(..) function is overloaded).
Regards,
Arjen

> -----Original Message-----
> From: laurent Berger [mailto:Lau...@un...]
> Sent: Thursday, August 14, 2014 3:46 PM
> To: plp...@li...
> Subject: Re: [Plplot-devel] About svg
>
> Thanks you for your answer.
> plplot 5.9.10, wxwidgets 3.0.0 visual studio 2012 C++ with  pls->width( 2.0 ); nothing
> changes.
> You can download source file and svg, ps and xfig  here :
> perso.univ-lemans.fr/~berger/aqzersPLPLOT
> My source code is :
> wxPLplotstream* pls=plotwindow->GetStream(); int iMin=0,iMax=16383;
>
> const size_t np=65536;
> if (x[0]==NULL)
>      for (int i=0;i<3;i++)
>          {
>          x[i]=new PLFLT[np];
>          y[i]=new PLFLT[np];
>          yFiltre[i]=new PLFLT[np];
>          }
> PLFLT xmin=iMin, xmax=iMax;
> PLFLT ymin=1e30, ymax=-1e30;
> ....
>
> pls->adv( 0 );
> pls->scol0 (    3, 0,0,255);
> pls->scol0 (    4, 0,0,128);
> pls->scol0 (    5, 0,255,0);
> pls->scol0 (    6, 0,128,0);
> pls->scol0 (    7, 255,0,0);
> pls->scol0 (    8, 128,0,0);
>
> if(bgcolor)
>      {
>      pls->scol0( 0, 255, 255, 255 );
>      pls->scol0( 15, 0, 0, 0 );
>      }
> else
>      {
>      pls->scol0( 15, 255, 255, 255 );
>      pls->scol0( 0, 0, 0, 0 );
>      }
> pls->col0( 1 );
> pls->env( xmin, xmax, ymin*.99, ymax*1.01, 0, 0 ); col0( 2 ); lab( "x",
> pls->"y", "Histogram");
> for (int j=0;j<nbPlan;j++)
>      {
>          pls->col0( 3+2*j);
>          pls->width( 2.0 );
>          pls->line( nbGraines[j], x[j], y[j] );
>          pls->col0( 4+2*j);
>          pls->width( 3.0 );
>          pls->line( nbGraines[j], x[j], yFiltre[j] );
>      }
> pls->RenewPlot();
> Refresh();
> plotwindow->SavePlot(wxString("svg"),wxString("tt.svg"));
> plotwindow->SavePlot(wxString("xfig"),wxString("tt.xfig"));
> plotwindow->SavePlot(wxString("ps"),wxString("tt.ps"));
> //plotwindow->SavePlot(wxString("wxpng"),wxString("tt.png")); BUG
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

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.