> On Jun 10, 2015, at 3:57 AM, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote:
>
>> On 2015-06-09 23:10-0400 Jim Dishaw wrote:
>>
>>
>>> On Jun 9, 2015, at 10:39 PM, Alan W. Irwin <ir...@beluga.phys.uvic.ca>
>>> wrote:
>>>
>>> On 2015-06-09 18:18-0400 Jim Dishaw wrote:
>>>
>>>> Attached is a patch series that corrects a NUL termination bug in
>>> the plot buffer that I discovered while working on the windows GDI
>>> driver.
>>>
>>> Hi Jim:
>>>
>>> I applied this result to a private branch using "git am", styled this
>>> result (which was very easy to do, see previous comment), amended your
>>> commit with those style changes using "git add" and "git commit
>>> --amend", and then pushed that result using the normal procedure in
>>> README.developers as commit id = 868f790.
>> Thanks, I will get uncrustify working on the Windows machine I’m using so I
>> don’t keep inconveniencing you.
>>
>>> Note, I did not test this commit in the slightest, but I assumed you
>>> had done that already.
>
>> The benefit of developing the the windows GDI driver is that it is
> exercising code pathways in the plot buffer that have never been
> tested. It appears that all the other GUI drivers have shifted to
> using unicode for strings. This error affects drivers that use
> regular strings and rely on the plot buffer, which is a very small
> set.
>
> Hi Jim:
>
> I am sufficiently concerned by your explanation of this fix above that
> I am now beginning to wonder a bit if it was necessary. Of course, I
> could be just missing something, but I would appreciate a fuller
> explanation of the fix to make sure of its necessity.
>
The fix is still necessary to replay the plot buffer with a device that uses
char strings vice the Unicode string. In EscText there are two different ways
of storing strings.
> Here is some random stuff I know about our method of dealing with
> unicode which might help to clarify the discussion.
>
> Input strings for PLplot are all in the UTF-8 representation of
> unicode whether representing glyphs that require a multi-byte UTF-8
> representation or glyphs that require only a single-byte (ascii) but
> still UTF-8 representation of glyphs. In all cases these input strings
> are a series of bytes which are null-terminated. So I really don't see
> how you are getting null-termination problems for some devices and not
> others. Also, the xwin device driver (which is available on Cygwin,
> Mac OS X, and Linux) is an example of a driver that uses regular
> strings and relies on the plot buffer. So this driver should be an
> excellent test case for us of plbuf changes that you do for the
> regular strings case.
>
> How should the latest change of yours affect the xwin device driver
> results?
>
Without the patch text strings could show random characters on redraw events.
With this patch all the strings display correctly on resize events.
> 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
