Re: [Plplot-devel] About svg
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:laurent.ber...@univ-lemans.fr] > Sent: Thursday, August 14, 2014 2:40 PM > To: plplot-devel@lists.sourceforge.net > 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.00e+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 > Plplot-devel@lists.sourceforge.net > 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. -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
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 ); pls->col0( 2 ); pls->lab( "x", "y", "Histogram"); for (int j=0;jcol0( 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 Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] About svg
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:laurent.ber...@univ-lemans.fr] > Sent: Thursday, August 14, 2014 3:46 PM > To: plplot-devel@lists.sourceforge.net > 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 { > 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 > Plplot-devel@lists.sourceforge.net > 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. -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] About svg
Arjen might well be right about the replot function, or maybe the stored replot data. What happens if you resize a Plplot window? Does that also show problems? Phil -Original Message- From: "Arjen Markus" Sent: 14/08/2014 15:08 To: "laurent Berger" ; "plplot-devel@lists.sourceforge.net" Subject: Re: [Plplot-devel] About svg 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:laurent.ber...@univ-lemans.fr] > Sent: Thursday, August 14, 2014 3:46 PM > To: plplot-devel@lists.sourceforge.net > 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 { > 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 > Plplot-devel@lists.sourceforge.net > 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. -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] About svg
Hi Phil, With some additional analysis from Laurent we were able to track down the cause: The routine rd_data() in plbuf.c is reading a U_CHAR value, whereas the width has been changed to a floating-point number. Changing the type solves the problem: switch ( op ) { case PLSTATE_WIDTH: { PLFLT width; rd_data( pls, &width, sizeof ( PLFLT ) ); pls->width = width; plP_state( PLSTATE_WIDTH ); break; } (The companion wr_data uses pls->width directly.) Maybe we should recode this to: rd_data( pls, &(pls->width), sizeof(pls->width); so that the code is agnostic to the actual data type, just as wr_data() is. That is what I have done in my repository – next step: get knowledgeable about git ;). Regards, Arjen From: Phil Rosenberg [mailto:philip_rosenb...@yahoo.com] Sent: Friday, August 15, 2014 12:08 AM To: Arjen Markus; laurent Berger; plplot-devel@lists.sourceforge.net Subject: RE: [Plplot-devel] About svg Arjen might well be right about the replot function, or maybe the stored replot data. What happens if you resize a Plplot window? Does that also show problems? Phil From: Arjen Markus<mailto:arjen.mar...@deltares.nl> Sent: 14/08/2014 15:08 To: laurent Berger<mailto:laurent.ber...@univ-lemans.fr>; plplot-devel@lists.sourceforge.net<mailto:plplot-devel@lists.sourceforge.net> Subject: Re: [Plplot-devel] About svg 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:laurent.ber...@univ-lemans.fr] > Sent: Thursday, August 14, 2014 3:46 PM > To: plplot-devel@lists.sourceforge.net > 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 { > 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 > Plplot-devel@lists.sourceforge.net > 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 resulti
Re: [Plplot-devel] About svg
Hi Arjen I had a look at this as well this morning and found the same thing, I thought I sent an email out, but I just found that email waiting in my drafts folder - oops. At least we found the same problem :-) I agree that the line rd_data( pls, &(pls->width), sizeof(pls->width); would be best as it makes things robust to later changes. Might be worth making similar changes to other reads. Yes as you say once we have a confirmed workflow the solution can be pushed up to the repo. I also noticed some other potential problems though. Firstly in a really simple example that I used to debug - just a call to plinit, then plwidth then plreplot, a number of unrecognised commands were found when the buffer was read, which presumably shouldn't be the case. I thought these were caused by the bad read of the width, causing misalignment of the read pointer, but it turned out at least some remain after the fix. I also noticed that font changes don't seem to be logged in the buffer. I'm not sure if there is anything else that is missing, but perhaps we should look? Following on from this - does anyone use the buffer to write to file? I have vague recollections that there is an option to do so. If so then we might be causing ourselves issues. If the font is added to the buffer then older versions of the library that trys to read a more modern version of a file will see an unrecognised entry, not know how many bytes to read and will end up with a misaligned read pointer affecting the reading of the remainder of the file. The same would be true of the fixed width parameter. However I guess even now the options of PLFLT as a float or double mean the file would be ambiguous. By the way Arjen, just out of curiosity - you use VC++ and Windows, is that right? If so do you just use nmake or do you use the full VC++ IDE and debugger? Phil From: Arjen Markus To: Phil Rosenberg ; laurent Berger ; "plplot-devel@lists.sourceforge.net" Sent: Friday, 15 August 2014, 10:42 Subject: RE: [Plplot-devel] About svg Hi Phil, With some additional analysis from Laurent we were able to track down the cause: The routine rd_data() in plbuf.c is reading a U_CHAR value, whereas the width has been changed to a floating-point number. Changing the type solves the problem: switch ( op ) { case PLSTATE_WIDTH: { PLFLT width; rd_data( pls, &width, sizeof ( PLFLT ) ); pls->width = width; plP_state( PLSTATE_WIDTH ); break; } (The companion wr_data uses pls->width directly.) Maybe we should recode this to: rd_data( pls, &(pls->width), sizeof(pls->width); so that the code is agnostic to the actual data type, just as wr_data() is. That is what I have done in my repository – next step: get knowledgeable about git ;). Regards, Arjen From:Phil Rosenberg [mailto:philip_rosenb...@yahoo.com] Sent: Friday, August 15, 2014 12:08 AM To: Arjen Markus; laurent Berger; plplot-devel@lists.sourceforge.net Subject: RE: [Plplot-devel] About svg Arjen might well be right about the replot function, or maybe the stored replot data. What happens if you resize a Plplot window? Does that also show problems? Phil From: Arjen Markus Sent: 14/08/2014 15:08 To: laurent Berger; plplot-devel@lists.sourceforge.net Subject: Re: [Plplot-devel] About svg 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:laurent.ber...@univ-lemans.fr] > Sent: Thursday, August 14, 2014 3:46 PM > To: plplot-devel@lists.sourceforge.net > 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,12
Re: [Plplot-devel] About svg
Hi Phil, Forgot your last question: For regular builds I use the nmake utility but if I need to trace some nasty bug then I do indeed rely on the IDE and the debugger – but quite often the venerable print method also works ;). Regards, Arjen From: phil rosenberg [mailto:philip_rosenb...@yahoo.com] Sent: Friday, August 15, 2014 4:40 PM To: Arjen Markus; laurent Berger; plplot-devel@lists.sourceforge.net Subject: Re: [Plplot-devel] About svg Hi Arjen I had a look at this as well this morning and found the same thing, I thought I sent an email out, but I just found that email waiting in my drafts folder - oops. At least we found the same problem :-) I agree that the line rd_data( pls, &(pls->width), sizeof(pls->width); would be best as it makes things robust to later changes. Might be worth making similar changes to other reads. Yes as you say once we have a confirmed workflow the solution can be pushed up to the repo. I also noticed some other potential problems though. Firstly in a really simple example that I used to debug - just a call to plinit, then plwidth then plreplot, a number of unrecognised commands were found when the buffer was read, which presumably shouldn't be the case. I thought these were caused by the bad read of the width, causing misalignment of the read pointer, but it turned out at least some remain after the fix. I also noticed that font changes don't seem to be logged in the buffer. I'm not sure if there is anything else that is missing, but perhaps we should look? Following on from this - does anyone use the buffer to write to file? I have vague recollections that there is an option to do so. If so then we might be causing ourselves issues. If the font is added to the buffer then older versions of the library that trys to read a more modern version of a file will see an unrecognised entry, not know how many bytes to read and will end up with a misaligned read pointer affecting the reading of the remainder of the file. The same would be true of the fixed width parameter. However I guess even now the options of PLFLT as a float or double mean the file would be ambiguous. By the way Arjen, just out of curiosity - you use VC++ and Windows, is that right? If so do you just use nmake or do you use the full VC++ IDE and debugger? Phil From: Arjen Markus mailto:arjen.mar...@deltares.nl>> To: Phil Rosenberg mailto:philip_rosenb...@yahoo.com>>; laurent Berger mailto:laurent.ber...@univ-lemans.fr>>; "plplot-devel@lists.sourceforge.net<mailto:plplot-devel@lists.sourceforge.net>" mailto:plplot-devel@lists.sourceforge.net>> Sent: Friday, 15 August 2014, 10:42 Subject: RE: [Plplot-devel] About svg Hi Phil, With some additional analysis from Laurent we were able to track down the cause: The routine rd_data() in plbuf.c is reading a U_CHAR value, whereas the width has been changed to a floating-point number. Changing the type solves the problem: switch ( op ) { case PLSTATE_WIDTH: { PLFLT width; rd_data( pls, &width, sizeof ( PLFLT ) ); pls->width = width; plP_state( PLSTATE_WIDTH ); break; } (The companion wr_data uses pls->width directly.) Maybe we should recode this to: rd_data( pls, &(pls->width), sizeof(pls->width); so that the code is agnostic to the actual data type, just as wr_data() is. That is what I have done in my repository – next step: get knowledgeable about git ;). Regards, Arjen From: Phil Rosenberg [mailto:philip_rosenb...@yahoo.com] Sent: Friday, August 15, 2014 12:08 AM To: Arjen Markus; laurent Berger; plplot-devel@lists.sourceforge.net<mailto:plplot-devel@lists.sourceforge.net> Subject: RE: [Plplot-devel] About svg Arjen might well be right about the replot function, or maybe the stored replot data. What happens if you resize a Plplot window? Does that also show problems? Phil From: Arjen Markus<mailto:arjen.mar...@deltares.nl> Sent: 14/08/2014 15:08 To: laurent Berger<mailto:laurent.ber...@univ-lemans.fr>; plplot-devel@lists.sourceforge.net<mailto:plplot-devel@lists.sourceforge.net> Subject: Re: [Plplot-devel] About svg 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:laurent.ber...@univ-lemans.fr] > Sent: Thursday, August 14, 2014 3:46 PM > To: > plplot-devel@lists.sourceforge.net<mailto:plplot-devel@lists.sourceforge.net> > Subject: Re: [Plplot-devel] About svg >
Re: [Plplot-devel] About svg
Hi Phil, I do not think we give the replotting facility the same thorough workout as the rest of the API, this may indeed have led to some bitrot. I am not all that familiar with that part of Plplot, but it is indeed possible to write to a buffer file and replot from that. It migh tbe worthwhile to implement the replotting in all examples (just it is done in x01c and x20c) and exercise this path in the non-interactive testing. Or create a single example to do this testing. Regards, Arjen From: phil rosenberg [mailto:philip_rosenb...@yahoo.com] Sent: Friday, August 15, 2014 4:40 PM To: Arjen Markus; laurent Berger; plplot-devel@lists.sourceforge.net Subject: Re: [Plplot-devel] About svg Hi Arjen I had a look at this as well this morning and found the same thing, I thought I sent an email out, but I just found that email waiting in my drafts folder - oops. At least we found the same problem :-) I agree that the line rd_data( pls, &(pls->width), sizeof(pls->width); would be best as it makes things robust to later changes. Might be worth making similar changes to other reads. Yes as you say once we have a confirmed workflow the solution can be pushed up to the repo. I also noticed some other potential problems though. Firstly in a really simple example that I used to debug - just a call to plinit, then plwidth then plreplot, a number of unrecognised commands were found when the buffer was read, which presumably shouldn't be the case. I thought these were caused by the bad read of the width, causing misalignment of the read pointer, but it turned out at least some remain after the fix. I also noticed that font changes don't seem to be logged in the buffer. I'm not sure if there is anything else that is missing, but perhaps we should look? Following on from this - does anyone use the buffer to write to file? I have vague recollections that there is an option to do so. If so then we might be causing ourselves issues. If the font is added to the buffer then older versions of the library that trys to read a more modern version of a file will see an unrecognised entry, not know how many bytes to read and will end up with a misaligned read pointer affecting the reading of the remainder of the file. The same would be true of the fixed width parameter. However I guess even now the options of PLFLT as a float or double mean the file would be ambiguous. By the way Arjen, just out of curiosity - you use VC++ and Windows, is that right? If so do you just use nmake or do you use the full VC++ IDE and debugger? Phil From: Arjen Markus mailto:arjen.mar...@deltares.nl>> To: Phil Rosenberg mailto:philip_rosenb...@yahoo.com>>; laurent Berger mailto:laurent.ber...@univ-lemans.fr>>; "plplot-devel@lists.sourceforge.net<mailto:plplot-devel@lists.sourceforge.net>" mailto:plplot-devel@lists.sourceforge.net>> Sent: Friday, 15 August 2014, 10:42 Subject: RE: [Plplot-devel] About svg Hi Phil, With some additional analysis from Laurent we were able to track down the cause: The routine rd_data() in plbuf.c is reading a U_CHAR value, whereas the width has been changed to a floating-point number. Changing the type solves the problem: switch ( op ) { case PLSTATE_WIDTH: { PLFLT width; rd_data( pls, &width, sizeof ( PLFLT ) ); pls->width = width; plP_state( PLSTATE_WIDTH ); break; } (The companion wr_data uses pls->width directly.) Maybe we should recode this to: rd_data( pls, &(pls->width), sizeof(pls->width); so that the code is agnostic to the actual data type, just as wr_data() is. That is what I have done in my repository – next step: get knowledgeable about git ;). Regards, Arjen From: Phil Rosenberg [mailto:philip_rosenb...@yahoo.com] Sent: Friday, August 15, 2014 12:08 AM To: Arjen Markus; laurent Berger; plplot-devel@lists.sourceforge.net<mailto:plplot-devel@lists.sourceforge.net> Subject: RE: [Plplot-devel] About svg Arjen might well be right about the replot function, or maybe the stored replot data. What happens if you resize a Plplot window? Does that also show problems? Phil From: Arjen Markus<mailto:arjen.mar...@deltares.nl> Sent: 14/08/2014 15:08 To: laurent Berger<mailto:laurent.ber...@univ-lemans.fr>; plplot-devel@lists.sourceforge.net<mailto:plplot-devel@lists.sourceforge.net> Subject: Re: [Plplot-devel] About svg 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- &
Re: [Plplot-devel] About svg
On 2014-08-15 14:49- Arjen Markus wrote: > Hi Phil, > > > > Forgot your last question: > > For regular builds I use the nmake utility but if I need to trace some nasty bug then I do indeed rely on the IDE and the debugger – but quite often the venerable print method also works ;). Hi Phil and Arjen: If you are using a gcc compiler on Windows (i.e., Cygwin, MinGW, or MinGW-w64), then gdb is an excellent debugger that is worth learning. The only debugger I use on Linux is gdb, and I have had a lot of success with it on that platform. I have used gdb on MinGW/Wine only a few times (since there has been so few MinGW-only debugging situations), but when I have used it, I have had similar success. If I recall correctly, Arjen once tried gdb on Cygwin without much success, but my guess is he simply missed one essential in its use which is gcc by default does not include debugging symbols in compiled results, and gdb is pretty useless in those circumstances. Instead, for debugging situations you have to rebuild from scratch using the gcc -g option (or remember to compile all the time with that option) which includes the debugging symbols in compiled results that are required by gdb. 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 mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] About svg
Yeah, I think you are correct about an example. I don't really use plreplot - I think mostly because when I first started using Plplot I noticed the lack of font support, but that was before I started digging into the code. I presume it gets well used by the interactive drivers. It certainly does in wxWidgets and I would use it in my code if it worked properly. Something I wondered, do you think it would be overkill to add the size in bytes to each buffer entry? That way if Plplot found an entry it did not support it could ignore it safely? Cheers for the answer re vc++, it is good to know there is someone else on the list using the same tools as me. I have tried using gdb in eclipse on Linux before and it almost does the same job, but I just don't quite find eclipse overall as slick as vc++. I don't think gdb does edit and continue like the vc++ debugger either, but anyway I didn't intend to start a compiler comparison conversation. Phil -Original Message- From: "Arjen Markus" Sent: 15/08/2014 15:49 To: "phil rosenberg" ; "laurent Berger" ; "plplot-devel@lists.sourceforge.net" Subject: RE: [Plplot-devel] About svg Hi Phil, Forgot your last question: For regular builds I use the nmake utility but if I need to trace some nasty bug then I do indeed rely on the IDE and the debugger – but quite often the venerable print method also works ;). Regards, Arjen From: phil rosenberg [mailto:philip_rosenb...@yahoo.com] Sent: Friday, August 15, 2014 4:40 PM To: Arjen Markus; laurent Berger; plplot-devel@lists.sourceforge.net Subject: Re: [Plplot-devel] About svg Hi Arjen I had a look at this as well this morning and found the same thing, I thought I sent an email out, but I just found that email waiting in my drafts folder - oops. At least we found the same problem :-) I agree that the line rd_data( pls, &(pls->width), sizeof(pls->width); would be best as it makes things robust to later changes. Might be worth making similar changes to other reads. Yes as you say once we have a confirmed workflow the solution can be pushed up to the repo. I also noticed some other potential problems though. Firstly in a really simple example that I used to debug - just a call to plinit, then plwidth then plreplot, a number of unrecognised commands were found when the buffer was read, which presumably shouldn't be the case. I thought these were caused by the bad read of the width, causing misalignment of the read pointer, but it turned out at least some remain after the fix. I also noticed that font changes don't seem to be logged in the buffer. I'm not sure if there is anything else that is missing, but perhaps we should look? Following on from this - does anyone use the buffer to write to file? I have vague recollections that there is an option to do so. If so then we might be causing ourselves issues. If the font is added to the buffer then older versions of the library that trys to read a more modern version of a file will see an unrecognised entry, not know how many bytes to read and will end up with a misaligned read pointer affecting the reading of the remainder of the file. The same would be true of the fixed width parameter. However I guess even now the options of PLFLT as a float or double mean the file would be ambiguous. By the way Arjen, just out of curiosity - you use VC++ and Windows, is that right? If so do you just use nmake or do you use the full VC++ IDE and debugger? Phil From: Arjen Markus To: Phil Rosenberg ; laurent Berger ; "plplot-devel@lists.sourceforge.net" Sent: Friday, 15 August 2014, 10:42 Subject: RE: [Plplot-devel] About svg Hi Phil, With some additional analysis from Laurent we were able to track down the cause: The routine rd_data() in plbuf.c is reading a U_CHAR value, whereas the width has been changed to a floating-point number. Changing the type solves the problem: switch ( op ) { case PLSTATE_WIDTH: { PLFLT width; rd_data( pls, &width, sizeof ( PLFLT ) ); [The entire original message is not included.]-- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel