This thread is becoming a bit unwieldy, but I will try to answer below @Jim I had already written and tested a fix for the hatchings and have just committed it, sorry if you spent time on this. Regarding the plhrsh issue, my build is fine - although it is a static build, so perhaps that is the difference. However I couldn't see any reference to plhersh in plmeta.c. I will commit your change though as exposing it should not affect anything else.
@Alan, Andrew and Arjen I followed the link you gave Andrew, then a link to a further page http://wiki.tcl.tk/1831. The tests on this page give correct results on my Centos machine, although it is of note that there is a post on that page with someone reporting correct test result onCentos, but the same issue. I will check my Ubuntu machine tonight, presumably there is little point performing tests of x via ssh with x forwarding. My tcl version is 8.6 on Ubuntu, but only 8.5 on Centos, so perhaps the tcl version explains the Centos problems. Note my tests on Ubuntu have all been via shh with x forwarding, maybe trying direct connection would help. Phil On 12 March 2015 at 04:03, Jim Dishaw <j...@dishaw.org> wrote: > I made a fix for double line fill bug. Please see attached file > > > > > I noticed a different bug. If you don't resize a plot, pressing enter > advances to the next page. After resizing a plot, it takes more than one key > press to advance. I'm not sure the cause, my suspicion is that there are > some additional commands (perhaps EOPs) creeping in at the end of the plot > buffer. I will investigate further. > > > On Mar 11, 2015, at 11:36 PM, Jim Dishaw <j...@dishaw.org> wrote: > >> >> On Mar 11, 2015, at 4:59 PM, Phil Rosenberg <p.d.rosenb...@gmail.com> wrote: >> >>> Hi Alan >>> >>> A quick bit of stepping through my code has confirmed my suspicion >>> from below. In plfill_soft plP_draphy is called for each line of the >>> pattern and these lines are saved in the buffer, so basically writing >>> to buffer needs switching off in this function. the change is about 3 >>> lines of code, but I will save it for post release if you prefer. >>> >> >> That is essentially correct. It appears that the issue is there is both a >> PLESC_FILL in the buffer and then the lines that were generated by plP_fill. >> There should be only one and not both and the PLESC_FILL should be the one >> to stay in the buffer. >> >> The first solution that comes to my mind is to set plsc->plbuf_write = 0 >> after the plbuf_esc() call and restore the original value at the end of the >> function. >> >>> Phil >>> >>> On 11 March 2015 at 18:31, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote: >>>> On 2015-03-11 13:01-0000 Phil Rosenberg wrote: >>>> >>>>>> >>>>>> * Example 13; extra lines in "Maurice", "Vince", and "Rafael" parts >>>>>> of the pie chart, but the other slices are fine. >>>>> >>>>> This isn't shown on Windows. Perhaps the cause is that both the lines >>>>> and the fill are being saved to the buffer meaning the lines get >>>>> rendered twice. This is just a guess though >>>> >> >> >> ------------------------------------------------------------------------------ >> Dive into the World of Parallel Programming The Go Parallel Website, >> sponsored >> by Intel and developed in partnership with Slashdot Media, is your hub for >> all >> things parallel software development, from weekly thought leadership blogs to >> news, videos, case studies, tutorials and more. Take a look and join the >> conversation now. http://goparallel.sourceforge.net/ >> _______________________________________________ >> Plplot-devel mailing list >> Plplot-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/plplot-devel > > ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
