On Feb 17, 2015, at 3:23 PM, "Alan W. Irwin" <ir...@beluga.phys.uvic.ca> wrote:

> Hi Jim:
> 
> On 2015-02-17 13:11-0500 Jim Dishaw wrote:
> 
>> Hopefully this patch series will work correctly.  I started a new
> topic branch as recommended.
> 
> IMPORTANT.  Which means your patch series and my subsequent patch
> to style it are now in the master branch at SourceForge and any further
> changes you do to plmeta/plbuf should start from a fresh new topic
> branch based on master tip.
> 

Thanks for the tip.

> Although I am obviously willing to run scripts/style_source.sh myself,
> I also encourage you to look at the recent thread here concerning how
> to do that for yourself to get the result of your series of commits to
> match PLplot code standards.
> 

I tried to use the plplot-c-style.el, but I'm not sure it is working correctly. 
 Does that file have the correct formatting style?

>> The plot metafile read will generate an output identical to
> plrender.  Visually, the plot is similar to the output generated by
> plplot directly; however, due to the difference in coordinates the
> file contents are not identical.
> 
> For me, this is a big issue for the current code in master tip.  I did
> read the comments in your 6th patch which said this change in
> coordinates was necessary, but is that really the case?
> 
> I am concerned you are trying to replicate the old bad behaviour of
> the plmeta device rather than rewriting plmeta/plrender completely
> (without that old bad behaviour) using plbuf capabilities.
> 

In the long term I don't think it is necessary.  My goal for this version was 
not to change the behavior that plrender exhibits--I wanted to avoid turning to 
many knobs while getting things working.

> Here is my mental model of what goes on with PLplot coordinates.
> (Please update/correct this if your recent digging into
> PLplot code shows you something different is going on.)
> 
> The user specifies a series of plot commands using a variety of
> coordinate systems that are available to the user (world coordinates,
> normalized subpage coordinates, etc.) Then when using any device, that
> series of plot commands containing a variety of coordinates are
> transformed into (currently 16-bit) internal physical coordinates
> which the device driver code linearly transforms into real physical
> coordinates of the device.

I have not untangled the hierarchy of coordinate system transformations.  When 
I directly used the coordinates from the plmeta driver, the resulting plots 
were not rendered correctly. I think I need to change what is generated by the 
plmeta driver and that will be incorporated in the 2015-1 metafile format.

> 
> So to my mind, if the new plmeta device did no linear transformation
> from internal physical coordinates to real physical coordinates (i.e,
> simply stored in the plmeta file the internal physical coordinates
> associated with each command), and plrender replayed those commands
> using their associated internal coordinates for <some device> then the
> "indirect" results from
> 
> <some_standard_example> -dev plmeta -o test.plm
> plrender test.plm -dev <some device>
> 
> should be absolutely identical (by construction of the new plmeta/plrender
> capability) with the "direct" result
> 
> <some_standard_example> -dev <some device>
> 

That is also my goal.


------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Reply via email to