From: Arjen M. <arj...@wl...> - 2003-08-19 08:11:39
|
Hello, according to the documentation I found with PLplot 5.2.1, it can be used on MS Windows (at least a few of the varieties currently in existence), but further than that I can find no information on how to proceed - for instance there is no driver for the Windows platform, as far as I can tell. Can someone shed some light? In particular: how does one control printing under Windows? (I mean: sending a picture directly to the printer, without the user having to start a utility like Ghostview). Kind regards, Arjen Markus |
From: Olof S. <sve...@es...> - 2003-08-19 08:52:55
|
Hi Arjen, Yes, plplot can be used on MS Windows however you need MS VC++ to compile the code. The win3 device for the Windows platform is working but it needs more work, for example one thing missing is the possibility of printing directly from plplot, now the only possibility is to create a PostScript file and print it via Ghostview. Unfortunately my present professional obligations leave me with no time to continue the win3 development, I can only do a minimum of maintenance, and so far no volunteer has showed up to continue the work. So, in the short future, I think the best is to use Cygwin for compiling and running plplot on MS Windows. Cygwin has the advantage that you don't need to buy the rather expensive MS VC++. There are now some problems when trying to compile plplot on Windows however I got the impression that there are people looking into these issues. Best regards, Olof Svensson Arjen Markus wrote: > > Hello, > > according to the documentation I found with PLplot 5.2.1, it can be used > on MS Windows (at least a few of the varieties currently in existence), > but further than that I can find no information on how to proceed - > for instance there is no driver for the Windows platform, as far as > I can tell. > > Can someone shed some light? > > In particular: how does one control printing under Windows? (I mean: > sending a picture directly to the printer, without the user having > to start a utility like Ghostview). > > Kind regards, > > Arjen Markus > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > _______________________________________________ > Plplot-general mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-general |
From: Arjen M. <arj...@wl...> - 2003-08-19 09:06:18
|
Olof Svensson wrote: > > Hi Arjen, > > Yes, plplot can be used on MS Windows however you need MS VC++ to > compile the code. The win3 device for the Windows platform is working > but it needs more work, for example one thing missing is the possibility > of printing directly from plplot, now the only possibility is to create > a PostScript file and print it via Ghostview. > > Unfortunately my present professional obligations leave me with no time > to continue the win3 development, I can only do a minimum of > maintenance, and so far no volunteer has showed up to continue the work. > So, in the short future, I think the best is to use Cygwin for compiling > and running plplot on MS Windows. Cygwin has the advantage that you > don't need to buy the rather expensive MS VC++. There are now some > problems when trying to compile plplot on Windows however I got the > impression that there are people looking into these issues. > > Thank you for that information. Here we use MSVC, so that should not be a problem. I am concerned about the printing stuff though. Hm. I have not seen a win3 driver by the way in the distribution. Should I look for that in the CVS head? And I had some issues with the Linux version - I will write them up in detail, but where should I send that to? Regards, Arjen |
From: Olof S. <sve...@es...> - 2003-08-19 09:22:42
|
Arjen Markus wrote: > > Thank you for that information. Here we use MSVC, so that should not be > a problem. I am concerned about the printing stuff though. Hm. > > I have not seen a win3 driver by the way in the distribution. Should I > look for that in the CVS head? The MSVC++ version is in plplot-5.2.1/sys/win32/msdev. Have a look at the README.TXT and INSTALL.TXT files in that directory. > And I had some issues with the Linux version - I will write them up > in detail, but where should I send that to? I guess the appropriate forum would be the plplot-devel list (mailto:plp...@li...). Regards, Olof |
From: Alan W. I. <ir...@be...> - 2003-08-19 21:47:29
|
> Olof Svensson wrote: > > So, in the short future, I think the best is to use Cygwin for compiling > > and running plplot on MS Windows. Cygwin has the advantage that you > > don't need to buy the rather expensive MS VC++. There are now some > > problems when trying to compile plplot on Windows however I got the > > impression that there are people looking into these issues. I agree the cygwin platform has great potential, but we are not there yet. Specifically, we have some near show-stopper issues with plplot-5.2.1 on cygwin (and probably Mac OS X as well although I have received no reports [pro or con] for that platform) because we used libtool-1.4.3 to generate the plplot-5.2.1 tarball. The libtool-1.5 release announcement emphasizes the much better cygwin and Mac OS X support of that version. Unfortunately, libtool-1.5 has been temporarily withdrawn by the FSF because of all the integrity checks they have to do after their ftp server was cracked, but soon after libtool-1.5 is reinstated I plan to use it to generate a PLplot tarball for testing on the cygwin and Mac OS X platforms. Watch this space for an announcement in the next week or so. On Tue, 19 Aug 2003, Arjen Markus wrote: > I have not seen a win3 driver by the way in the distribution. Should I > look for that in the CVS head? See plplot-5.2.1/sys/win32/msdev/README.TXT for what to do. > > And I had some issues with the Linux version - I will write them up > in detail, but where should I send that to? There is no hard and fast rule. However, generally speaking this list is used for announcement and reasonably simple questions and answers for ordinary PLplot users. Use plplot-devel for matters where you want to report more in-depth investigations. The developers participate on both lists so be sure and remember not to cross-post. 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...> - 2003-08-20 10:57:16
|
I have built a small function to plot (filled) circles via polygons and I have noticed that the polygons are clipped by removing vertices that fall outside the viewport. The consequence is that large circles are no longer recognisable as circles. Is there a way out of this? The polygons should - in my opinion - be drawn from all the vertices and the clipping should occur on the polygon as a whole. Regards, Arjen |
From: Maurice L. <mj...@ga...> - 2003-08-24 18:47:27
|
Arjen Markus writes: > I have built a small function to plot (filled) circles via polygons and > I have noticed that the polygons are clipped by removing vertices that > fall > outside the viewport. The consequence is that large circles are no > longer > recognisable as circles. > > Is there a way out of this? The polygons should - in my opinion - be > drawn from all the vertices and the clipping should occur on the polygon > as a whole. Polygon clipping is fairly complex. The issue really raised its head when I implemented zooming in the plplot TK interface and started doing a lot of shade plotting, way back in '94 or so. I worked on it for a while before giving up due to lack of progress even though there were still a lot of problems with it. As an example, run "x16c -dev tk", zoom in on a section and then pan around. Anyway I decided to take another look at the code and noticed right away problems with the existing approach. Emboldened, I set about to improve it and now am happy to say it works much better than before. Grab the latest src/plline.c from cvs HEAD and see if the new code fixes your problem. Note it still does not work perfectly -- at a sufficiently high level of zooming we start to get clipping problems again. These I suspect are due to a fidelity problem, either in clipline() or somewhere else. Anyway no more time to work on it for now. -- Maurice LeBrun Lightspeed Semiconductor Corp |
From: Arjen M. <arj...@wl...> - 2003-08-25 06:43:23
|
Maurice LeBrun wrote: > > > Polygon clipping is fairly complex. The issue really raised its head when I > implemented zooming in the plplot TK interface and started doing a lot of > shade plotting, way back in '94 or so. I worked on it for a while before > giving up due to lack of progress even though there were still a lot of > problems with it. As an example, run "x16c -dev tk", zoom in on a section and > then pan around. > > Anyway I decided to take another look at the code and noticed right away > problems with the existing approach. Emboldened, I set about to improve it > and now am happy to say it works much better than before. Grab the latest > src/plline.c from cvs HEAD and see if the new code fixes your problem. > > Note it still does not work perfectly -- at a sufficiently high level of > zooming we start to get clipping problems again. These I suspect are due to a > fidelity problem, either in clipline() or somewhere else. Anyway no more time > to work on it for now. > > That sounds great. When I wrote the original e-mail, I started thinking how this could be improved - I soon realised that a completely general solution is very difficult/tedious. I will have a look at the new source. Thanks for looking into it. Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2003-08-26 10:53:35
|
Hello, I have found that with the X Window driver the values returned by plgspa() are/can be too small by a factor of approximately 1.4. Is this somehow due to my set-up (hardware/the program involved) or is this more commonly recognised as a problem? Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2003-08-26 14:35:41
|
Arjen Markus wrote: > > That sounds great. When I wrote the original e-mail, I started thinking > how > this could be improved - I soon realised that a completely general > solution > is very difficult/tedious. I will have a look at the new source. > > Thanks for looking into it. > Forget my second reply to this: I forgot to "make install" :( Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2003-08-26 12:17:23
|
Arjen Markus wrote: > > Maurice LeBrun wrote: > > > > > > > Polygon clipping is fairly complex. The issue really raised its head when I > > implemented zooming in the plplot TK interface and started doing a lot of > > shade plotting, way back in '94 or so. I worked on it for a while before > > giving up due to lack of progress even though there were still a lot of > > problems with it. As an example, run "x16c -dev tk", zoom in on a section and > > then pan around. > > > > Anyway I decided to take another look at the code and noticed right away > > problems with the existing approach. Emboldened, I set about to improve it > > and now am happy to say it works much better than before. Grab the latest > > src/plline.c from cvs HEAD and see if the new code fixes your problem. > > > > Note it still does not work perfectly -- at a sufficiently high level of > > zooming we start to get clipping problems again. These I suspect are due to a > > fidelity problem, either in clipline() or somewhere else. Anyway no more time > > to work on it for now. > > > > > > That sounds great. When I wrote the original e-mail, I started thinking > how > this could be improved - I soon realised that a completely general > solution > is very difficult/tedious. I will have a look at the new source. > > Thanks for looking into it. > I just tried with this new version. The result is the same: severed polygons. As I am having problems with gdb - it shows very strange lines to be executed next (see below for a transcript) - it is difficult to make sure that all is being as it should. Looking further ... Regards, Arjen ------------------------- Transcript of gdb session ------------------------- (gdb) break 63 Breakpoint 2 at 0x81d651b: file plfill.c, line 63. (gdb) c Continuing. Breakpoint 2, c_plfill (n=21, x=0xbfffd074, y=0xbfffd014) at plfill.c:64 64 plP_plfclp(xpoly, ypoly, n, plsc->clpxmi, plsc->clpxma, (gdb) s plP_plfclp (x=0xbfffcbd4, y=0xbfffc7d4, npts=22, xmin=5461, xmax=27306, ymin=5461, ymax=22755, draw=0x81cf71c <plP_fill>) at plline.c:551 551 (gdb) n 545 * correct. For the fill cases encountered in plplot, this treatment should (gdb) n 547 * the typical return value is 3 or -3, since 3 turns are necessary in order 548 * to complete the fill region. Only for really oddly shaped fill regions 549 * will it give the wrong answer. 550 \*----------------------------------------------------------------------*/ 551 552 static int 553 circulation(PLINT *x, PLINT *y, PLINT npts) 554 { 555 int xproduct, direction = 0; 556 PLINT i, x1, y1, x2, y2, x3, y3; (gdb) n 553 circulation(PLINT *x, PLINT *y, PLINT npts) (gdb) n 554 { (gdb) n 555 int xproduct, direction = 0; (gdb) n 557 for (i = 0; i < npts - 1; i++) { (gdb) n --- gdb shows the header of a routine I am not in yet ... |
From: Arjen M. <arj...@wl...> - 2003-08-27 12:25:29
|
Hello, when I run an example program on Windows XP, it seems impossible to get output in a window, if the program starts on a network disk. The message is: *** PLPLOT ERROR *** plbuf_init: Error opening plot data storage file. Program aborted If, however, I copy it to a local hard disk, then there is no problem. But, a furhter problem is that it does not seem to be able to find the fonts (by setting PLPLOT_HOME). I f I copy the files into the local directory, there is no problem. Does any one know a more convenient solution for either problem? Regards, Arjen |