On 2007-08-05 12:02-0400 Hazen Babcock wrote: > > On Aug 3, 2007, at 3:54 AM, Alan W. Irwin wrote: > >> On 2007-08-02 23:04-0700 Alan W. Irwin wrote: >> >>> Now for some issues I discovered with the pscairo results. >>> >>> (1) The bounding box is not correct. (I believe that is a known issue >>> which >>> you plan to fix.) > > Is the problem that the bounding box does not match the size of the plot?
Yes. > That the plots "bleed" over onto subsequent pages? No. > Do you have a example that > demonstrates the undesired behavior? Example 10. I ran the following commands: ./x10c -dev psc -o test.psc ./x10c -dev psttfc -o test.psttfc ./x10c -dev pscairo -o test.pscairo Here are the bounding boxes from those results: [EMAIL PROTECTED]> grep -i bounding test.ps* test.psc:%%BoundingBox: 32 32 572 752 test.pscairo:%%BoundingBox: 0 0 720 540 test.pscairo:%%PageBoundingBox: 0 0 720 540 test.psttfc:%%BoundingBox: 32 32 572 752 test.psttfc:%%HiResBoundingBox: 32 32 572 752 You can see devices psc and psttfc agree (and also the gv viewer confirms the bounding boxes are correct for those cases), but for the pscairo case the bounding box is correct except that the x and y coordinates of the bounding box have been switched (which causes lots of troubles for the gv viewer with part of the plot cut off). It appears pscairo always (I have checked other examples as well) sets the same bounding boxes regardless of size of the plot. For now, if you swap the x and y bounding boxes you will most likely always get it too big, but at least you won't cut off part of the plot (which is what is happening for most of the examples now with swapped x and y bounding box values). Later as a much lower priority you may want to revisit this issue and set an exact bounding box to take care of some of our example cases (such as example 3) where the plot is actually smaller than 0 0 540 720. When playing with this I found issue number 5 which is (5) pscairo ignores the -portrait flag and the -ori flag gives strange looking results with part of the plot (the titles) oriented to a new direction and the rest of the plot ignoring -ori altogether. As far as I am concerned this is a low priority, but I bring it up because it will obviously affect the bounding box once you get -portrait and -ori implemented. > >>> (2) At least for single pages I planned to get around the bounding box >>> issue >>> using >>> >>> -dev pscairo -o - | ps2eps -l -q --ignoreBB > filename.eps. >>> >>> but stdout (at least when invoked by "-o -" which is the PLplot standard >>> for >>> specifying stdout) does not work. In fact, if you try it with -dev >>> pscairo >>> you will simply get output to the filename "-". (Files with that name >>> are >>> tough to get rid of unless you remember the special construct "rm -- >>> -".) >>> >>> I can get around this stdout issue for now by the following clumsy >>> construct >>> to fix the bounding box >>> >>> -dev pscairo -o temp.ps ; cat temp.ps |ps2eps -l -q --ignoreBB > >>> filename; \ >>> rm -f temp.ps > > I was not aware of this convention, but I'll see if that is possible. I have never looked at these internals before, but it appears to be straightforward. When your device calls plOpenFile it looks at the filename that has been set up, and if it is "-" it sets pls->OutFile = stdout; pls->output_type = 1; It appears to be the responsibility of the file device driver to use OutFile (see ps.c where OF is #defined to by pls->OutFile), but currently cairo.c closes that file and uses FileName instead which is at least part of the source of the trouble. Currently no device other than plmeta uses pls->output_type logic (which is only set for filename of "-" case in plOpenFile), but for the cairo case where you are dealing with both interactive and file devices it might be useful. > >>> (3) There are still minor 3D plot labelling problems. For example, if >>> you >>> look at example 8 the y-axis labels (and possibly the z-axis labels) are >>> oriented properly (Hazen, thanks for fixing that issue!), but they have >>> a >>> size that is too large. To see this I suggest you visually compare with >>> the >>> same plot generated with -dev psc. > > Is this just for the 3D labels? Yes. I see no problems like this for example 1 (which is just 2D). But if you compare -dev psc and -dev pscairo results for example 8, you will see "y-axis" and the left-hand "z-axis strings are stretched in their vertical directions and similarly for the tick mark labels for both the y axis and left-hand z axis, but the x axis and right-hand z axis (both title and tick labels) are fine. > I'm not sure why 2D labels would be > differently sized than 3D labels. Perhaps there is some additional logic for the 3D case that needs fixing for the y and left-hand z axis? The x- and right-hand z-axis logic seems fine. > >> Just discovered another pscairo issue. >> >> (4) Text clipping has not yet been implemented. (The first page of example >> 9 >> shows this issue as well as some of my research plots.) > > Do you mean clipping the text at the edge of the plotting area? Yes. Look at the first page of example 9, and you should immediately see the problem (contour labels slopping over outside the viewport). I think you have a device with great potential here so it is worth it to get all these 5 niggling issues straightened out. Therefore, I will be happy to test any fixups you come up with. 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); PLplot scientific plotting software package (plplot.org); 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 __________________________ ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
