From: Andrew R. <and...@us...> - 2004-02-10 15:00:05
|
I've submitted a patch to change plarrows. The user can now supply a series of line segments to create their own arrow style using the new plsarrow function. The plarrows API is unchanged and the default behaviour is to plot the old arrow style if no user style is provided so the changes are backward compatible. I've also written a very basic C example (x22c) to demonstrate this. Do people think this is a good way to proceed? If so I'll try and add the new function in to the other bindings and also write corresponding examples. I think making the arrow up from line segments should be fairly flexible. The only things it doesn't cover are filled arrow heads and possibly the type of arrows used on meteorological charts where the number of tails on the arrow shows the speed. The latter might be a bit specialised anyway. An alternative (or maybe complementary) implementation would be to have a series of default styles (which could include open and closed arrows) and also parameters to control the width and length of the head, e.g. something like plsarrow2( PLINT arrow_style, PLFLT head_width, PLFLT head_length) Any comments? Andrew |
From: Andrew R. <and...@us...> - 2004-02-11 11:48:13
|
Just to update you, I've commited another patch to add a fill option to the new plsarrow function. x22c.c now demostrate this too. There is also now an equivalent C++ example x22.cc. Andrew On Tue, Feb 10, 2004 at 02:59:56PM +0000, Andrew Ross wrote: > > I've submitted a patch to change plarrows. The user can now supply a > series of line segments to create their own arrow style using the new > plsarrow function. The plarrows API is unchanged and the default > behaviour is to plot the old arrow style if no user style is provided so > the changes are backward compatible. I've also written a very basic C > example (x22c) to demonstrate this. Do people think this is a good way > to proceed? If so I'll try and add the new function in to the other > bindings and also write corresponding examples. > > I think making the arrow up from line segments should be fairly > flexible. The only things it doesn't cover are filled arrow heads and > possibly the type of arrows used on meteorological charts where the > number of tails on the arrow shows the speed. The latter might be a bit > specialised anyway. > > An alternative (or maybe complementary) implementation would be to have > a series of default styles (which could include open and closed arrows) > and also parameters to control the width and length of the head, e.g. > something like > > plsarrow2( PLINT arrow_style, PLFLT head_width, PLFLT head_length) > > Any comments? > > Andrew |
From: Alan W. I. <ir...@be...> - 2004-02-12 00:48:26
|
On 2004-02-11 11:47-0000 Andrew Ross wrote: > > Just to update you, I've commited another patch to add a fill option to > the new plsarrow function. x22c.c now demostrate this too. There is also > now an equivalent C++ example x22.cc. A minor issue is the colours. For example, I believe red labels and box and yellow vectors on a black background would look better than the current red on black. The other issue is the API. The last time this was discussed on list, the definitive comment was Maurice's, I believe. ************* It would be a whole different API. Right now we have: void plarrows(PLFLT *u, PLFLT *v, PLFLT *x, PLFLT *y, PLINT n, PLFLT scale, PLFLT dx, PLFLT dy) I'd change this to input 2 quantities (Ax_ij, Ay_ij) using the usual function evaluator approach. I think a single function pointer but different client data for each is sufficient. I'd drop the dx,dy stuff and instead have it do a pre-pass to determine what the maximum vector length should be so that vectors don't overlap, taking into account possible coordinate transformations. Then the internal entry point would look something like: plvecf_int(PLFLT (*plf2eval) (PLINT, PLINT, PLPointer), PLPointer plf2eval_data1, PLPointer plf2eval_data2, PLINT (*defined) (PLFLT, PLFLT, PLPointer), PLPointer defined_data, PLINT nx, PLINT ny, PLFLT scale, void (*pltr) (PLFLT, PLFLT, PLFLT *, PLFLT *, PLPointer), PLPointer pltr_data); where defined() here includes the new client data pointer syntax. It'd need a nice front-end to it with a suitably picked function evaluator similar to in pl*cont* and pl*shade*. Looks like some work. ************* To substantially simplify this, I would drop the defined part of it (which I brought up in the first place for the previous thread). Right now we don't have "defined" API for plcont, and I really don't think we need it for this API. But we do need the overall function evaluator stuff. Somebody will immediately want to be plotting vector fields for polar coordinates or irregularly shaped x,y regions, and plcont handles those cases with ease because of its function evaluator approach. Andrew, I have got to say that your example 22 already looks pretty good so I hope we can settle the API issue then extend that and example 22 (with colour changes and possibly adding a page with a vector field for polar coordinates) to all the language interfaces. I would be willing to do all of that latter project for python, java, fortran, and tcl, but I would leave to you doing the internal changes to implement the function evaluator approach along the lines of what Maurice suggested and also the required changes to the C++ interface and x22.cc. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Andrew R. <and...@us...> - 2004-02-16 10:12:31
|
On Wed, Feb 11, 2004 at 04:47:20PM -0800, Alan Irwin wrote: > On 2004-02-11 11:47-0000 Andrew Ross wrote: > > > > > Just to update you, I've commited another patch to add a fill option to > > the new plsarrow function. x22c.c now demostrate this too. There is also > > now an equivalent C++ example x22.cc. > > A minor issue is the colours. For example, I believe red labels and box and > yellow vectors on a black background would look better than the current red > on black. Fixed. > > The other issue is the API. The last time this was discussed on list, the > definitive comment was Maurice's, I believe. > > ************* > It would be a whole > different API. Right now we have: > > void > plarrows(PLFLT *u, PLFLT *v, PLFLT *x, PLFLT *y, PLINT n, > PLFLT scale, PLFLT dx, PLFLT dy) > > I'd change this to input 2 quantities (Ax_ij, Ay_ij) using the usual function > evaluator approach. I think a single function pointer but different client > data for each is sufficient. I'd drop the dx,dy stuff and instead have it > do a pre-pass to determine what the maximum vector length should be so that > vectors don't overlap, taking into account possible coordinate > transformations. Then the internal entry point would look something like: > > plvecf_int(PLFLT (*plf2eval) (PLINT, PLINT, PLPointer), > PLPointer plf2eval_data1, PLPointer plf2eval_data2, > PLINT (*defined) (PLFLT, PLFLT, PLPointer), > PLPointer defined_data, > PLINT nx, PLINT ny, PLFLT scale, > void (*pltr) (PLFLT, PLFLT, PLFLT *, PLFLT *, PLPointer), > PLPointer pltr_data); > > where defined() here includes the new client data pointer syntax. > > It'd need a nice front-end to it with a suitably picked function evaluator > similar to in pl*cont* and pl*shade*. > > Looks like some work. > ************* > > To substantially simplify this, I would drop the defined part of it (which I > brought up in the first place for the previous thread). Right now we don't > have "defined" API for plcont, and I really don't think we need it for this > API. But we do need the overall function evaluator stuff. Somebody will > immediately want to be plotting vector fields for polar coordinates or > irregularly shaped x,y regions, and plcont handles those cases with ease > because of its function evaluator approach. Thanks for the suggestions. I have now implemented something along these lines. Example 22 has been updated to reflect this and also to demonstrate polar plots. We might want to rename the front end function from plarrows2 to something more meaningful. To avoid problems with the existing if underused and undocumented plarrows() interface we could rename the new functions plvects() and plsvect() for plotting vectors if people prefer. A few points worth noting: The vectors have to be in cartesian coordinates even if the coordinates are in e.g. polars (see example 22). This is mostly because of the way our coordinate transforms work. I see this probably as more of a feature rather than a limitation. If you think otherwise let me know. The auto-scaling is not particularly sophisticated and may well not work for complicated coordinate systems. To keep the work to a minimum it assumes that the adjacent points in the cgrid2 coordinate arrays are the adjacent points in real space. Again this is probably not a major limitation. If people have wierd and wonderful or even random arrays of points to plot vectors at then they can always provide a scaling themselves. A more robust algorithm would have to work out the distances from every point to every other point which could be expensive for large arrays. I may yet implement this. > Andrew, I have got to say that your example 22 already looks pretty good so > I hope we can settle the API issue then extend that and example 22 (with > colour changes and possibly adding a page with a vector field for polar > coordinates) to all the language interfaces. I would be willing to do all > of that latter project for python, java, fortran, and tcl, but I would leave > to you doing the internal changes to implement the function evaluator > approach along the lines of what Maurice suggested and also the required > changes to the C++ interface and x22.cc. Alan, if we think the interface is ok then I would be grateful for help adding the API to other languages and porting example 22. Cheers Andrew |
From: Rafael L. <rla...@us...> - 2004-02-16 10:42:48
|
* Andrew Ross <and...@us...> [2004-02-16 10:08]: > Alan, if we think the interface is ok then I would be grateful for help > adding the API to other languages and porting example 22. ... and also the appropriate documentation to the DocBook manual. At any rate, thanks for your great work. -- Rafael |
From: Alan W. I. <ir...@be...> - 2004-02-16 18:14:28
|
Maurice, could you take a look at this new API to make sure everything is okay, please? That review would be a big help before we go to the effort of propagating this to the various language interfaces. Alan On 2004-02-16 10:08-0000 Andrew Ross wrote: > On Wed, Feb 11, 2004 at 04:47:20PM -0800, Alan Irwin wrote: > > On 2004-02-11 11:47-0000 Andrew Ross wrote: > > > > > > > > Just to update you, I've commited another patch to add a fill option to > > > the new plsarrow function. x22c.c now demostrate this too. There is also > > > now an equivalent C++ example x22.cc. > > > > A minor issue is the colours. For example, I believe red labels and box and > > yellow vectors on a black background would look better than the current red > > on black. > > Fixed. > > > > > The other issue is the API. The last time this was discussed on list, the > > definitive comment was Maurice's, I believe. > > > > ************* > > It would be a whole > > different API. Right now we have: > > > > void > > plarrows(PLFLT *u, PLFLT *v, PLFLT *x, PLFLT *y, PLINT n, > > PLFLT scale, PLFLT dx, PLFLT dy) > > > > I'd change this to input 2 quantities (Ax_ij, Ay_ij) using the usual function > > evaluator approach. I think a single function pointer but different client > > data for each is sufficient. I'd drop the dx,dy stuff and instead have it > > do a pre-pass to determine what the maximum vector length should be so that > > vectors don't overlap, taking into account possible coordinate > > transformations. Then the internal entry point would look something like: > > > > plvecf_int(PLFLT (*plf2eval) (PLINT, PLINT, PLPointer), > > PLPointer plf2eval_data1, PLPointer plf2eval_data2, > > PLINT (*defined) (PLFLT, PLFLT, PLPointer), > > PLPointer defined_data, > > PLINT nx, PLINT ny, PLFLT scale, > > void (*pltr) (PLFLT, PLFLT, PLFLT *, PLFLT *, PLPointer), > > PLPointer pltr_data); > > > > where defined() here includes the new client data pointer syntax. > > > > It'd need a nice front-end to it with a suitably picked function evaluator > > similar to in pl*cont* and pl*shade*. > > > > Looks like some work. > > ************* > > > > To substantially simplify this, I would drop the defined part of it (which I > > brought up in the first place for the previous thread). Right now we don't > > have "defined" API for plcont, and I really don't think we need it for this > > API. But we do need the overall function evaluator stuff. Somebody will > > immediately want to be plotting vector fields for polar coordinates or > > irregularly shaped x,y regions, and plcont handles those cases with ease > > because of its function evaluator approach. > > Thanks for the suggestions. I have now implemented something along these > lines. Example 22 has been updated to reflect this and also to > demonstrate polar plots. > > We might want to rename the front end function from plarrows2 to > something more meaningful. To avoid problems with the existing if > underused and undocumented plarrows() interface we could rename the new > functions plvects() and plsvect() for plotting vectors if people prefer. > > A few points worth noting: > > The vectors have to be in cartesian coordinates even if the coordinates > are in e.g. polars (see example 22). This is mostly because of the way > our coordinate transforms work. I see this probably as more of a feature > rather than a limitation. If you think otherwise let me know. > > The auto-scaling is not particularly sophisticated and may well not work > for complicated coordinate systems. To keep the work to a minimum it > assumes that the adjacent points in the cgrid2 coordinate arrays are the > adjacent points in real space. Again this is probably not a major > limitation. If people have wierd and wonderful or even random arrays of > points to plot vectors at then they can always provide a scaling > themselves. A more robust algorithm would have to work out the distances > from every point to every other point which could be expensive for large > arrays. I may yet implement this. > > > Andrew, I have got to say that your example 22 already looks pretty good so > > I hope we can settle the API issue then extend that and example 22 (with > > colour changes and possibly adding a page with a vector field for polar > > coordinates) to all the language interfaces. I would be willing to do all > > of that latter project for python, java, fortran, and tcl, but I would leave > > to you doing the internal changes to implement the function evaluator > > approach along the lines of what Maurice suggested and also the required > > changes to the C++ interface and x22.cc. > > Alan, if we think the interface is ok then I would be grateful for help > adding the API to other languages and porting example 22. > > Cheers > > Andrew > __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Andrew R. <and...@us...> - 2004-02-16 18:47:57
|
On Mon, Feb 16, 2004 at 10:10:33AM -0800, Alan Irwin wrote: > Maurice, could you take a look at this new API to make sure everything is > okay, please? That review would be a big help before we go to the effort of > propagating this to the various language interfaces. > > Alan I've just committed a change to rename plarrows2 / plsarrow to plvect and plsvect to avoid any possible confusion with the old version. I've backed out the changes to plarrows so it will still operate just as it always did. This way we can depreciate and remove plarrows (which was never documented or part of the common API) without affecting the new interface. I've also added a fortran binding very much in the same style as the fortran plcon[t012] interface. All 3 examples produce identical results. Andrew |
From: Alan W. I. <ir...@be...> - 2004-02-16 21:22:08
|
On 2004-02-16 18:44-0000 Andrew Ross wrote: > On Mon, Feb 16, 2004 at 10:10:33AM -0800, Alan Irwin wrote: > > Maurice, could you take a look at this new API to make sure everything is > > okay, please? That review would be a big help before we go to the effort of > > propagating this to the various language interfaces. > > > > Alan > > I've just committed a change to rename plarrows2 / plsarrow to plvect > and plsvect to avoid any possible confusion with the old version. I've > backed out the changes to plarrows so it will still operate just as it > always did. This way we can depreciate and remove plarrows (which was > never documented or part of the common API) without affecting the new > interface. > > I've also added a fortran binding very much in the same style as the > fortran plcon[t012] interface. All 3 examples produce identical results. Thanks, Andrew. I just now cvs updated, and make install with all your recent changes went fine. Since I am not an API expert, I will confine my comments just to example 22, and specifically c/x22c.c since the C++ and f77 versions mimic that. * Thanks for the colour change. I think it looks better. * That default arrow on the first page is probably something you inherited, but I still think it looks fairly ugly. I suggest using the arrow defined for the current second page the default. Then you could eliminate a page and have the default style produce what is now the second page, and the user-defined arrow be filled as in the current 3rd page. * I would suggest using a more interesting vector field to serve for the (new) first and second pages. Example 8 plots an interesting "rosen" function. One possibility is to use the gradient of that function as the vector field. * For similar "interest" reasons, I would suggest using the gradient of the shielded potential of two charges in a conducting sphere (example 9, 5th page) for your final page. * For that final page, I would also surround it by a circle (just like example 9, 5th page) rather than a box. Andrew, I have suggested a large number of C example changes that entail a fair amount of work, but as soon as I get some other PLplot projects finished up this week (java, python, and gd linking issues, and rpms), and assuming you agree with the example changes, I would be willing to help with that effort as well as propagation of the 22nd C example to the other interfaces. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Arjen M. <arj...@wl...> - 2004-02-17 09:01:33
|
Hello, I noticed, analysing the rather awkward scaling of my plots on paper, that the PSC driver is using a paper size of 8.5 by 11 inches. Is there any way to make it use A4 size (or even A3, just to have the option)? Regards, Arjen |
From: Rafael L. <rla...@us...> - 2004-02-17 10:59:34
|
* Arjen Markus <arj...@wl...> [2004-02-17 09:57]: > I noticed, analysing the rather awkward scaling of my plots on paper, > that the PSC driver is using a paper size of 8.5 by 11 inches. The values are hardcoded in include/ps.h: #define XSIZE 540 /* 7.5 x 10 [inches] */ #define YSIZE 720 /* (72 points = 1 inch) */ #define XOFFSET 32 /* Margins -- */ #define YOFFSET 32 /* .5 inches each */ > Is there any way to make it use A4 size (or even A3, just to have the > option)? Here is a great project for a developer with plenty of free time: 1) Get PLplot to use libpaper in system where it is available. libpaper is a library that reads /etc/papersize (a site-wide configuration file) and give informations about paper format. I have here (on Debian): $ cat /etc/papersize a4 $ paperconf -s 595 842 2) As a fall back, add an option --with-paper to configure. -- Rafael |
From: Arjen M. <arj...@wl...> - 2004-02-17 11:08:58
|
Rafael Laboissiere wrote: > > * Arjen Markus <arj...@wl...> [2004-02-17 09:57]: > > > I noticed, analysing the rather awkward scaling of my plots on paper, > > that the PSC driver is using a paper size of 8.5 by 11 inches. > > The values are hardcoded in include/ps.h: > > #define XSIZE 540 /* 7.5 x 10 [inches] */ > #define YSIZE 720 /* (72 points = 1 inch) */ > #define XOFFSET 32 /* Margins -- */ > #define YOFFSET 32 /* .5 inches each */ > > > Is there any way to make it use A4 size (or even A3, just to have the > > option)? > > Here is a great project for a developer with plenty of free time: > > 1) Get PLplot to use libpaper in system where it is available. libpaper > is a library that reads /etc/papersize (a site-wide configuration > file) and give informations about paper format. I have here (on > Debian): > > $ cat /etc/papersize > a4 > $ paperconf -s > 595 842 > > 2) As a fall back, add an option --with-paper to configure. > Well, perhaps not plenty of free time, but a great need for A4! Let me see what I can do here ... (Hm, no libpaper on my RedHat Linux system) Regards, Arjen |
From: Rafael L. <rla...@us...> - 2004-02-17 11:39:48
|
* Arjen Markus <arj...@wl...> [2004-02-17 12:04]: > Well, perhaps not plenty of free time, but a great need for A4! > Let me see what I can do here ... Well, a quick solution is to change the values of XSIZE and YSIZE in ps.h... > (Hm, no libpaper on my RedHat Linux system) Try rpmfind.net. libpaper is native Debian, but I guess it has been ported elsewhere. -- Rafael |
From: Alan W. I. <ir...@be...> - 2004-02-17 16:48:20
|
On 2004-02-17 12:04+0100 Arjen Markus wrote: > (Hm, no libpaper on my RedHat Linux system) Somebody suggested trying rpmfind, but generally, I find that you get more complete results from RPM Search (http://rpm.pbone.net/). There, if you search for libpaper.so, you will find libpaper Mandrake rpms. If libpaper is really simple with no dependencies these rpms might work well on all rpm-based systems. Somebody in the thread suggested using -geometry as an interim measure. I doubt that is honored by all devices. Perhaps an even better interim option to try would be the -a option (aspect ratio). I believe that option is honored by all devices. It's only drawback is you would have to get out your calculator to figure out the aspect ratio of a4. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Arjen M. <arj...@wl...> - 2004-02-18 11:20:54
|
"Alan W. Irwin" wrote: > > On 2004-02-17 12:04+0100 Arjen Markus wrote: > > (Hm, no libpaper on my RedHat Linux system) > > Somebody suggested trying rpmfind, but generally, I find that you get more > complete results from RPM Search (http://rpm.pbone.net/). There, if you > search for libpaper.so, you will find libpaper Mandrake rpms. If libpaper > is really simple with no dependencies these rpms might work well on all > rpm-based systems. > > Somebody in the thread suggested using -geometry as an interim measure. I > doubt that is honored by all devices. Perhaps an even better interim option > to try would be the -a option (aspect ratio). I believe that option is > honored by all devices. It's only drawback is you would have to get out > your calculator to figure out the aspect ratio of a4. > I am not sure that these interim solutions are worth the effort. It seems to me that a limited version is quite feasible (recognise the most common types and allow arbitrary sizes via detailed options). Besides, you can not chose the paper size with all drivers - some are simply stuck with the physical properties of the device. I have written a short description of how I would like to solve this. See below. Comments are quite welcome. I will try to come up with a first solution today or tomorrow. Regards, Arjen ----- Description of the interface to set paper sizes: ------------------------------------------------ The paper size is defined by three quantities: 1. The shorter side of the paper, the "width" 2. The longer side of the paper, the "height" 3. The margin to use from the physical edges on all sides These quantities do not depend on the orientation of the paper. They can also define a completely arbitrary plotting surface (for instance to define an image in a PostScript file that can be embedded in a document without resizing). The useable surface extends from x=margin to x=width-margin, y=margin to y=height-margin. The following command-line arguments are defined: -papersize name -paperwidth width-in-mm -paperheight height-in-mm -papermargin margin-in-mm Use the plsetopt() interface to set these values programmatically. The name is a name like "A4", "a4" or "legal" to indicate a common paper size. Using the -papersize option means that default values for width, height and margin are set. These can be overwritten by later command-line options. If no paper size is set, the default is dependent on the driver. Note that not all drivers allow the paper size to be set. For the PostScript driver this is 8.5x11 inches, the ANSI A size. The paper size must be set to a specific choice before plinit() is called. Otherwise it will have no effect. The C API to query the size is: PLFLT plPaperHeight( int unit ) ; PLFLT plPaperWidth( int unit ) ; PLFLT plPaperMargin( int unit ) ; For flexibility, the unit argument can be used to specify that the unit for the paper size is to be: mm - unit = UNIT_MM inch - unit = UNIT_INCH points - unit = UNIT_POINTS Notes on libpaper: ----------------- The Debian library libpaper can be a good resource for the actual implementation. Right now, this is not done, because it will require a twofold solution: - if libpaper is available, then we should use it - if it is not available on the system, then we need an alternative Also, libpaper does not handle margins, so that something extra is still needed (though we could say the default margin is 0) |
From: Rafael L. <rla...@us...> - 2004-02-18 11:42:25
|
* Arjen Markus <arj...@wl...> [2004-02-18 12:15]: > Description of the interface to set paper sizes: > ------------------------------------------------ > > [...] Thanks for the design. It looks sound. > Notes on libpaper: > ----------------- > The Debian library libpaper can be a good resource for the actual > implementation. Right now, this is not done, because it will > require a twofold solution: > - if libpaper is available, then we should use it > - if it is not available on the system, then we need an alternative libpaper is a small library. We could include the sources in the tarball, but the system's version would take priority over them (this would be checked by configure). We are already doing a similar thing with libltdl, so we have the know-how. > Also, libpaper does not handle margins, so that something extra is > still needed (though we could say the default margin is 0) Well, strictly speaking, margins are not properties of paper formats, in the same sense as width and height are. Margins should be specified by the user but PLplot could use a sensible default. BTW, I think that a default of 0 is appropriate for the margins, since it would produce EPS files whose bounding boxes really surround the printed area. -- Rafael |
From: Andrew R. <and...@us...> - 2004-02-18 13:10:33
|
On Wed, Feb 18, 2004 at 12:15:44PM +0100, Arjen Markus wrote: Arjen, This sounds good to me. > Description of the interface to set paper sizes: > ------------------------------------------------ > > The paper size is defined by three quantities: > 1. The shorter side of the paper, the "width" > 2. The longer side of the paper, the "height" > 3. The margin to use from the physical edges on all sides Although we already have the capability to do portrait and landscape with the -ori option, I see no particular reason to mandate that width < height. > These quantities do not depend on the orientation of > the paper. They can also define a completely arbitrary > plotting surface (for instance to define an image in a > PostScript file that can be embedded in a document without > resizing). > > The useable surface extends from x=margin to x=width-margin, > y=margin to y=height-margin. > > The following command-line arguments are defined: > -papersize name > -paperwidth width-in-mm > -paperheight height-in-mm > -papermargin margin-in-mm Would it add significantly to the work to do what other packages do and allow the units to be specificed with the values? E.g. -paperwidth 100mm -paperheight 5in . Since you propose an interface to get the units in various formats we should be able to set them too. > Use the plsetopt() interface to set these values programmatically. > > The name is a name like "A4", "a4" or "legal" to indicate > a common paper size. Using the -papersize option means > that default values for width, height and margin are set. > These can be overwritten by later command-line options. > > If no paper size is set, the default is dependent on the driver. > Note that not all drivers allow the paper size to be set. > For the PostScript driver this is 8.5x11 inches, the ANSI A size. > > The paper size must be set to a specific choice before > plinit() is called. Otherwise it will have no effect. > > The C API to query the size is: > > PLFLT plPaperHeight( int unit ) ; > PLFLT plPaperWidth( int unit ) ; > PLFLT plPaperMargin( int unit ) ; > > For flexibility, the unit argument can be used to specify > that the unit for the paper size is to be: > mm - unit = UNIT_MM > inch - unit = UNIT_INCH > points - unit = UNIT_POINTS We have the plsopt mechanism for setting command line arguments. I wonder if we ought to have some similar plgopt mechanism for situations like this to try and prevent API bloat? > Notes on libpaper: > ----------------- > The Debian library libpaper can be a good resource for the actual > implementation. Right now, this is not done, because it will > require a twofold solution: > - if libpaper is available, then we should use it > - if it is not available on the system, then we need an alternative > > Also, libpaper does not handle margins, so that something extra is > still needed (though we could say the default margin is 0) > > > > ------------------------------------------------------- > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > Build and deploy apps & Web services for Linux with > a free DVD software kit from IBM. Click Now! > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Andrew R. <and...@us...> - 2004-02-17 14:30:42
|
On Mon, Feb 16, 2004 at 01:18:05PM -0800, Alan Irwin wrote: > On 2004-02-16 18:44-0000 Andrew Ross wrote: > > > I've just committed a change to rename plarrows2 / plsarrow to plvect > > and plsvect to avoid any possible confusion with the old version. I've > > backed out the changes to plarrows so it will still operate just as it > > always did. This way we can depreciate and remove plarrows (which was > > never documented or part of the common API) without affecting the new > > interface. > > > > I've also added a fortran binding very much in the same style as the > > fortran plcon[t012] interface. All 3 examples produce identical results. > > Thanks, Andrew. > > I just now cvs updated, and make install with all your recent changes went > fine. > > Since I am not an API expert, I will confine my comments just to example 22, > and specifically c/x22c.c since the C++ and f77 versions mimic that. > > * Thanks for the colour change. I think it looks better. > > * That default arrow on the first page is probably something you inherited, > but I still think it looks fairly ugly. I suggest using the arrow defined > for the current second page the default. Then you could eliminate a page and > have the default style produce what is now the second page, and the > user-defined arrow be filled as in the current 3rd page. I've changed the default arrow style. I don't think anyone could disagree. The old plarrow still uses the old style if anyone cares. > * I would suggest using a more interesting vector field to serve for the > (new) first and second pages. Example 8 plots an interesting "rosen" > function. One possibility is to use the gradient of that function as the > vector field. > > * For similar "interest" reasons, I would suggest using the gradient of > the shielded potential of two charges in a conducting sphere (example 9, 5th > page) for your final page. > > * For that final page, I would also surround it by a circle (just like > example 9, 5th page) rather than a box. > > Andrew, I have suggested a large number of C example changes that entail a > fair amount of work, but as soon as I get some other PLplot projects > finished up this week (java, python, and gd linking issues, and rpms), and > assuming you agree with the example changes, I would be willing to help with > that effort as well as propagation of the 22nd C example to the other > interfaces. I've committed an alternative x22c.c. See what you think. I agree mine examples were a little dull. Not convinced these are better though. A good polar example seems particularly hard. Suggestions welcome. Andrew |
From: Maurice L. <mj...@ga...> - 2004-02-18 04:40:55
|
Andrew Ross writes: > On Mon, Feb 16, 2004 at 10:10:33AM -0800, Alan Irwin wrote: > > Maurice, could you take a look at this new API to make sure everything is > > okay, please? That review would be a big help before we go to the effort of > > propagating this to the various language interfaces. > > > > Alan > > I've just committed a change to rename plarrows2 / plsarrow to plvect > and plsvect to avoid any possible confusion with the old version. I've > backed out the changes to plarrows so it will still operate just as it > always did. This way we can depreciate and remove plarrows (which was > never documented or part of the common API) without affecting the new > interface. > > I've also added a fortran binding very much in the same style as the > fortran plcon[t012] interface. All 3 examples produce identical results. Looks great. -- Maurice LeBrun |
From: Arjen M. <arj...@wl...> - 2004-02-18 14:05:31
|
Andrew Ross wrote: > > On Wed, Feb 18, 2004 at 12:15:44PM +0100, Arjen Markus wrote: > > Arjen, > > This sounds good to me. > > > Description of the interface to set paper sizes: > > ------------------------------------------------ > > > > The paper size is defined by three quantities: > > 1. The shorter side of the paper, the "width" > > 2. The longer side of the paper, the "height" > > 3. The margin to use from the physical edges on all sides > > Although we already have the capability to do portrait and landscape > with the -ori option, I see no particular reason to mandate that width < > height. > At least for the PostScript driver, -ori and -portrait/-landscape do different things. -ori sets the rotation and that can be changed dynamically, -portrait/-landscape also set the field "portrait" in PLstream, which instructs the driver to change the extents. These options have no effect after plinit(). [This merits a separate section in the documentation, I think. I had some trouble finding out why my pictures were cut off!] The only reason to define width <= height is that then you do not need to consider the actual orientation - it is rather tough to keep realising what orientation you have, I can assure you :) > > > > The following command-line arguments are defined: > > -papersize name > > -paperwidth width-in-mm > > -paperheight height-in-mm > > -papermargin margin-in-mm > > Would it add significantly to the work to do what other packages do and > allow the units to be specificed with the values? E.g. -paperwidth 100mm > -paperheight 5in . Since you propose an interface to get the units in > various formats we should be able to set them too. > I did not want to be too eurocentric or SI-centric. But that is a good suggestion. > > The C API to query the size is: > > > > PLFLT plPaperHeight( int unit ) ; > > PLFLT plPaperWidth( int unit ) ; > > PLFLT plPaperMargin( int unit ) ; > > > > For flexibility, the unit argument can be used to specify > > that the unit for the paper size is to be: > > mm - unit = UNIT_MM > > inch - unit = UNIT_INCH > > points - unit = UNIT_POINTS > > We have the plsopt mechanism for setting command line arguments. I > wonder if we ought to have some similar plgopt mechanism for situations > like this to try and prevent API bloat? > You can ask for individual settings - plgdrv() is one that comes to mind, but that is in much the same fashion as the above. What I can imagine is: plPaperMeasures( int unit, PLFLT *width, PLFLT *height, PLFLT *margin ) - just one function then. As for the margin (Rafael's remark): That is not an intrinsic property of the paper, but many devices use some small, seldom-documented margin beyond which you can not plot. Providing a small default margin would be beneficial when you go and print the result. Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2004-02-18 18:21:53
|
On 2004-02-18 15:00+0100 Arjen Markus wrote: > As for the margin (Rafael's remark): > That is not an intrinsic property of the paper, but many devices use > some small, seldom-documented margin beyond which you can not plot. > Providing a small default margin would be beneficial when you go > and print the result. I think adding margins is normally the domain of the printing system. (See http://www.cups.org/sum.html#4_4_4 for how CUPS [the Common Unix Print System] allows you to set arbitrary margins.) However, if you feel PLplot needs this capability for special situations where the (broken) print system cannot handle margins, then please make the default no margin at all since we normally expect the printing system to be able to adjust the margins. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Arjen M. <arj...@wl...> - 2004-02-19 08:53:55
|
Rafael mentioned the possibility of incorporating libpaper's sources in the distribution. As that library is distributed under GPL (not LGPL) we would be forced to change the license of PLplot as a whole to GPL, or do I misunderstand the licensing issues? Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2004-02-19 09:07:18
|
On 2004-02-19 09:48+0100 Arjen Markus wrote: > Rafael mentioned the possibility of incorporating libpaper's sources > in the distribution. As that library is distributed under GPL > (not LGPL) we would be forced to change the license of PLplot > as a whole to GPL, or do I misunderstand the licensing issues? I think you are right. In fact, if that library is GPL, then my understanding is we are not even allowed to link to an independent version of that library without relicensing PLplot to GPL (which is not realistic because we would have to contact a lot of copyright holders to get their OK which they might not want to give). GPL programmes and libraries can link to LGPL libraries, but LGPL programmes and libraries cannot link to GPL libraries. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Maurice L. <mj...@ga...> - 2004-02-19 09:21:03
|
Arjen Markus writes: > Rafael mentioned the possibility of incorporating libpaper's sources > in the distribution. As that library is distributed under GPL > (not LGPL) we would be forced to change the license of PLplot > as a whole to GPL, or do I misunderstand the licensing issues? You couldn't possibly include any source from libpaper. What I do think is ok is to provide configuration-time support for building against GPL'ed libs if that's something the user wants to do. So it should be disabled by default. For example, I played with adding readline support (also GPL) to the plplot Tcl shell, so a similar issue. Just as long as all GPL headers & libs stay out unless the user specifically asks for it, I think no problems. OTOH, an LGPL substitute, if there is one, seems to be the better choice. -- Maurice LeBrun |
From: Arjen M. <arj...@wl...> - 2004-02-19 09:17:56
|
"Alan W. Irwin" wrote: > > On 2004-02-19 09:48+0100 Arjen Markus wrote: > > > Rafael mentioned the possibility of incorporating libpaper's sources > > in the distribution. As that library is distributed under GPL > > (not LGPL) we would be forced to change the license of PLplot > > as a whole to GPL, or do I misunderstand the licensing issues? > > I think you are right. In fact, if that library is GPL, then my > understanding is we are not even allowed to link to an independent version > of that library without relicensing PLplot to GPL (which is not realistic > because we would have to contact a lot of copyright holders to get their OK > which they might not want to give). GPL programmes and libraries can link to > LGPL libraries, but LGPL programmes and libraries cannot link to GPL > libraries. > Not to mention that all the users of PLplot will have to agree on the GPL license and the consequences thereof - I for one would be forced to look for another library :( Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2004-02-20 08:36:42
|
"Alan W. Irwin" wrote: > > On 2004-02-18 15:00+0100 Arjen Markus wrote: > > > As for the margin (Rafael's remark): > > That is not an intrinsic property of the paper, but many devices use > > some small, seldom-documented margin beyond which you can not plot. > > Providing a small default margin would be beneficial when you go > > and print the result. > > I think adding margins is normally the domain of the printing system. (See > http://www.cups.org/sum.html#4_4_4 for how CUPS [the Common Unix Print > System] allows you to set arbitrary margins.) However, if you feel PLplot > needs this capability for special situations where the (broken) print system > cannot handle margins, then please make the default no margin at all since > we normally expect the printing system to be able to adjust the margins. > The problem I am referring to is that the origin of the coordinate system as used by the printer may actually be outside the area that is available for printing. The margin can then be used to reposition the _logical_ coordinate system so that the user does not have to do that him/herself. Regards, Arjen |