> On Mar 12, 2015, at 7:06 AM, Phil Rosenberg <p.d.rosenb...@gmail.com> wrote:
> 
> 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.

No problem. It was only a 5 minute fix. 

> 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.
> 

It is in src/plmetafile.c not plmeta.c. 

> 
>> 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

Reply via email to