This slightly breaks the chain, but Jim just sent me a patch for adding
colourmaps to the buffer. These include a call to plP_state at the end just
as in plscmap#. My question is, what should a drivers respons be to such a
change mid plot? Currently in wxWidgets the background colour will change
immediately, but the current colour will remain until a call to plcol#. I
just wanted to check everyone thought this was sensible? ( I think it
probably is)
Regarding other things
>>My feeling from what Maurice said is if you abandon the current
>>low-level -dev plmeta approach and use something higher level (which
>>Phil is apparently going to do), then with care you should be able to
>>get exact reproducibility.
Yes, that is my thought - the plbuf.c code and the plstream buffer being
that higher level. In fact I have just written some quick and dirty code to
dump some examples to file for my testing with wxWidget (which is where we
started). Things mostly work quite well. The colour maps are an issue, but
I will test the fix Jim sent me for this. Text is also a problem. In
particular if a driver doesn't support text then Hershey text is saved to
the buffer, if Unicode text is saved to the buffer and a driver which
doesn't support text reads it then that text is discarded. Does anyone know
if plP_text can cope with a Unicode text string? That would be an easy fix
for the latter.
Another text problem (maybe affects other things as well) is that text
which is placed on a gradient using plptex, no longer knows the aspect
ratio of the viewport, so if that aspect ratio is different then the text
will not be at the correct angle. This is rather more complex to fix and is
something that I think affects the interactive drivers now too (if resizing
their window allows the aspect ratio to change - which is true for
wxWidgets at least).
>> 3) Change the data type for coordinates in plbuf to PLINTERNAL (which
will be set to short for the time being)
In the future I think this could do with some thought (and some work!).
When I started as a plplot user the sizing really confused me, especially
with respect to text. I still haven't got my head round references in the
wxWidgets driver to inches and mm. Perhaps some of this is just a
documentation issue though.
Phil
On 14 January 2015 at 06:00, Alan W. Irwin <ir...@beluga.phys.uvic.ca>
wrote:
> On 2015-01-13 22:52-0500 Jim Dishaw wrote:
>
> That [very simple plrender] would be my supposition.
>>
>> I looked at the changes required to switch from short to PLINTERNAL and I
>> have a few questions:
>>
>> 1) Do we want to keep the PLINTERNAL type private to plplot?
>> 2) Where do we want to define the type (the location depends on the
>> answer to #1)?
>>
>
> I am not sure. Andrew might have a good answer here.
>
>
> 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
> __________________________
>
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
