From: Hazen B. <hba...@ma...> - 2007-06-03 22:22:38
|
Hello, I've added the Cairo driver family to PLplot. This includes: xcairo (formally known as xwinttf). pdfcairo (PDF) pscairo (PS) svgcairo (SVG) pngcairo (PNG) memcairo (MEM) Known issues: 1. If you have Cairo but not X Windows your build will likely fail since I still haven't solved the pre-processor directive problem I mentioned Yesterday. 2. The svgcairo driver does not display text properly. I'm not really sure what to do about this one since it seems to be an issue with the cairo library. 3. The pngcairo driver does not support multiple pages. You only get one page, which is the last page that you drew. This could be fixed by having the driver generate multiple files, say my-graph.png, my- graph-2.png, etc... I don't think the PNG format itself supports multiple page output. 4. The memcairo driver is untested. It appears that a side effect of a call to plsmem is to force PLplot to use the "mem" driver. An attempt to overide this behavior by calling plsdev("memcairo") after the plsmem call but before plinit was unsuccessful. 5. Plots output by the pscairo driver do not fit the page, i.e. there is a largish white margin on two sides of a plot. All the drivers are off by default so you will have to turn them on to test them, if you are so inclined. best, -Hazen |
From: Alan W. I. <ir...@be...> - 2007-06-03 23:30:11
|
On 2007-06-03 18:20-0400 Hazen Babcock wrote: > > Hello, > > I've added the Cairo driver family to PLplot. This includes: > > xcairo (formally known as xwinttf). > pdfcairo (PDF) > pscairo (PS) > svgcairo (SVG) > pngcairo (PNG) > memcairo (MEM) > > Known issues: > 1. If you have Cairo but not X Windows your build will likely fail > since I still haven't solved the pre-processor directive problem I > mentioned Yesterday. > 2. The svgcairo driver does not display text properly. I'm not really > sure what to do about this one since it seems to be an issue with the > cairo library. > 3. The pngcairo driver does not support multiple pages. You only get > one page, which is the last page that you drew. This could be fixed > by having the driver generate multiple files, say my-graph.png, my- > graph-2.png, etc... I don't think the PNG format itself supports > multiple page output. That is correct. The way this is taken care of for the png device (as well as jpeg and gif) for gd.c is to use the normal PLplot familying facility (see http://plplot.sourceforge.net/docbook-manual/plplot-html-5.7.3/output-devices.html#familying). It's a bit tricky to set up, but if you follow what is done for gd.c, you should be fine. I thought you might have inadvertently set up familying already simply by following what is done in gd.c, but apparently not since the -fam command-line option only gives the same last page of example 8 that you get without the option. > 4. The memcairo driver is untested. It appears that a side effect of > a call to plsmem is to force PLplot to use the "mem" driver. An > attempt to overide this behavior by calling plsdev("memcairo") after > the plsmem call but before plinit was unsuccessful. > 5. Plots output by the pscairo driver do not fit the page, i.e. there > is a largish white margin on two sides of a plot. > > All the drivers are off by default so you will have to turn them on > to test them, if you are so inclined. I didn't bother with memcairo, but I built all the rest with no build errors on Ubuntu Dapper. I have only done the most superficial tests of the built results, but I immediately noticed two issues on Linux beyond what you mentioned. (1) the 'ldd -r cairo.so' test showed the following problems: undefined symbol: cairo_ps_surface_create (./cairo.so) undefined symbol: cairo_pdf_surface_create (./cairo.so) undefined symbol: cairo_svg_surface_create (./cairo.so) It's fairly urgent to solve these problems since it excludes any testing of the pscairo, pdfcairo, or svgcairo devices on Linux. (2) ./x08c -dev xcairo shows only the first page of that example. Hazen, I am really happy you are developing all these promising cairo-related devices. 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 __________________________ |
From: Hazen B. <hba...@ma...> - 2007-06-05 01:19:45
|
On Jun 3, 2007, at 7:30 PM, Alan W. Irwin wrote: > On 2007-06-03 18:20-0400 Hazen Babcock wrote: > >> >> Hello, >> >> I've added the Cairo driver family to PLplot. This includes: >> >> xcairo (formally known as xwinttf). >> pdfcairo (PDF) >> pscairo (PS) >> svgcairo (SVG) >> pngcairo (PNG) >> memcairo (MEM) >> >> Known issues: >> 1. If you have Cairo but not X Windows your build will likely fail >> since I still haven't solved the pre-processor directive problem I >> mentioned Yesterday. >> 2. The svgcairo driver does not display text properly. I'm not really >> sure what to do about this one since it seems to be an issue with the >> cairo library. >> 3. The pngcairo driver does not support multiple pages. You only get >> one page, which is the last page that you drew. This could be fixed >> by having the driver generate multiple files, say my-graph.png, my- >> graph-2.png, etc... I don't think the PNG format itself supports >> multiple page output. > > That is correct. The way this is taken care of for the png device > (as well > as jpeg and gif) for gd.c is to use the normal PLplot familying > facility > (see > http://plplot.sourceforge.net/docbook-manual/plplot-html-5.7.3/ > output-devices.html#familying). > It's a bit tricky to set up, but if you follow what is done for > gd.c, you > should be fine. I thought you might have inadvertently set up > familying > already simply by following what is done in gd.c, but apparently > not since > the -fam command-line option only gives the same last page of > example 8 that > you get without the option. Ok. I'll implement this approach. >> 4. The memcairo driver is untested. It appears that a side effect of >> a call to plsmem is to force PLplot to use the "mem" driver. An >> attempt to overide this behavior by calling plsdev("memcairo") after >> the plsmem call but before plinit was unsuccessful. >> 5. Plots output by the pscairo driver do not fit the page, i.e. there >> is a largish white margin on two sides of a plot. >> >> All the drivers are off by default so you will have to turn them on >> to test them, if you are so inclined. > > I didn't bother with memcairo, but I built all the rest with no > build errors > on Ubuntu Dapper. > > I have only done the most superficial tests of the built results, > but I > immediately noticed two issues on Linux beyond what you mentioned. > > (1) the 'ldd -r cairo.so' test showed the > following problems: > > undefined symbol: cairo_ps_surface_create (./cairo.so) > undefined symbol: cairo_pdf_surface_create (./cairo.so) > undefined symbol: cairo_svg_surface_create (./cairo.so) > > It's fairly urgent to solve these problems since it excludes any > testing of > the pscairo, pdfcairo, or svgcairo devices on Linux. Maybe this is because I have Cairo v1.2.6 and debian testing is v1.2.4? According the cairo docs these functions have been in the library since 1.2. > (2) ./x08c -dev xcairo shows only the first page of that example. Hm. On OS-X I get a bus error. It is interesting that it works fine if you just type ./x08c and then choose the driver. -Hazen |
From: Hazen B. <hba...@ma...> - 2007-06-10 04:45:28
|
On Jun 4, 2007, at 9:17 PM, Hazen Babcock wrote: > On Jun 3, 2007, at 7:30 PM, Alan W. Irwin wrote: >> >> That is correct. The way this is taken care of for the png device >> (as well >> as jpeg and gif) for gd.c is to use the normal PLplot familying >> facility >> (see >> http://plplot.sourceforge.net/docbook-manual/plplot-html-5.7.3/ >> output-devices.html#familying). >> It's a bit tricky to set up, but if you follow what is done for >> gd.c, you >> should be fine. I thought you might have inadvertently set up >> familying >> already simply by following what is done in gd.c, but apparently >> not since >> the -fam command-line option only gives the same last page of >> example 8 that >> you get without the option. > > Ok. I'll implement this approach. The -fam option should now work with pngcairo. -Hazen |
From: Alan W. I. <ir...@be...> - 2007-08-03 06:04:23
|
On 2007-06-04 21:17-0400 Hazen Babcock wrote: > > On Jun 3, 2007, at 7:30 PM, Alan W. Irwin wrote: > >> I have only done the most superficial tests of the built results, but I >> immediately noticed two issues on Linux beyond what you mentioned. >> >> (1) the 'ldd -r cairo.so' test showed the >> following problems: >> >> undefined symbol: cairo_ps_surface_create (./cairo.so) >> undefined symbol: cairo_pdf_surface_create (./cairo.so) >> undefined symbol: cairo_svg_surface_create (./cairo.so) >> >> It's fairly urgent to solve these problems since it excludes any testing >> of >> the pscairo, pdfcairo, or svgcairo devices on Linux. > > Maybe this is because I have Cairo v1.2.6 and debian testing is v1.2.4? > According the cairo docs these functions have been in the library since 1.2. Hi Hazen: I am reviving this thread because I got some bad news today about libLASi (the library used by the psttf device). It has no support for font hinting. What that means is letters are misaligned relative to the pixel grid of the display device causing letters to have inconsistent shapes if antialiasing is turned off or letters having a "muddy" appearance with antialiasing turned on. A lot of users don't mind such issues so psttf is still going to be useful for them, but for my needs I prefer the hinting of characters to be done correctly so this evening I started evaluating the pscairo alternative for making postscript plots. I built libcairo-1.4.10 for myself since that oldstable Debian did not even have libcairo. 19 of 124 tests failed as a result of "make check". I think that is an expected result since the libcairo developers probably do not have access to such an old set of system libraries for testing purposes (and probably wouldn't want to support such old versions in any case). I didn't see anything wrong in the failed tests that seemed relevant to postscript so I forged ahead. I used the latest pango stack that I had also built for myself on that machine. For the PLplot build, I built all pango-related devices except for the memory one (which I don't know how to test). All seemed well in the build after I removed the duplicates from the X11_INCLUDE_DIR list (see latest commit) that were occurring at least on my Linux system. 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.) (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 (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. Now for the good news about pscairo hinting. It's perfect! Without antialiasing turned on in gv, the letters have consistent shapes because they are consistently aligned with the display device pixel grid. And once you turn on antialiasing the result looks exceptionally clean and clear. Of course you pay for the much cleaner looking pscairo results by somewhat longer plot generation times (e.g., 0.456s versus 0.359s for psttfc) and somewhat larger (e.g., 64K versus 48K for psttfc) compressed postscript file sizes. (These speed/size comparisons between pscairo and psttfc were done for one of my 3D research plots that calls plsurf3dl with options MAG_COLOR | BASE_CONT | SURF_CONT.) The relatively modest speed loss and size gain for pscairo aren't that important for my research plots, and I really like the look of the well-hinted text label results that you get with this device. Thus, I am really happy pscairo exists and my thanks to Hazen for making this possible. 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2007-08-03 07:54:54
|
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.) > > (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 > > (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. 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.) 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 __________________________ |
From: Hazen B. <hba...@ma...> - 2007-08-05 16:04:43
|
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? That the plots "bleed" over onto subsequent pages? Do you have a example that demonstrates the undesired behavior? >> (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. >> (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? I'm not sure why 2D labels would be differently sized than 3D labels. > 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? best, -Hazen |
From: Alan W. I. <ir...@be...> - 2007-06-05 02:19:10
|
On 2007-06-04 21:17-0400 Hazen Babcock wrote: > On Jun 3, 2007, at 7:30 PM, Alan W. Irwin wrote: >> (1) the 'ldd -r cairo.so' test showed the >> following problems: >> >> undefined symbol: cairo_ps_surface_create (./cairo.so) >> undefined symbol: cairo_pdf_surface_create (./cairo.so) >> undefined symbol: cairo_svg_surface_create (./cairo.so) >> >> It's fairly urgent to solve these problems since it excludes any testing >> of >> the pscairo, pdfcairo, or svgcairo devices on Linux. > > Maybe this is because I have Cairo v1.2.6 and debian testing is v1.2.4? > According the cairo docs these functions have been in the library since 1.2. Actually, my platform is Ubuntu Dapper (released almost exactly a year ago) which has version 1.0.4 of the cairo library. So that explains the missing symbols for my platform. Note, _some_ Ubuntu Dapper platforms are going to be around for a long time since Canonical plans to support it for 3 years on the desktop (and 5 years on the server). However, I am not sure the majority of desktop users will actually use Ubuntu Dapper that long since even a one-year old Linux desktop is already way out of date thanks to the huge pace of change for Linux development. (A case in point is this already old libcairo version for Ubuntu Dapper). For example, I plan to move to Debian testing as soon as I can find the time to do the install. That's the best background I can give you about how relevant libcairo-1.0.4 will be in the future, and I will let you be the judge whether you want to support this older version of libcairo or not. I hope to install debian testing some time this summer after I finish my current research project, and after that old libcairo versions won't be an issue for me. > >> (2) ./x08c -dev xcairo shows only the first page of that example. > > Hm. On OS-X I get a bus error. It is interesting that it works fine if you > just type ./x08c and then choose the driver. ./x08c -dev xcairo now actually pretty much works for me. I finally figured out that you should hit CR in the xterm where that command-line is typed and not the GUI (at least when threading is not turned on). Now that I know how to run it, "./x08c -dev xcairo" shows some issues. (1) The 3D labelling needs work on the transformation to determine the rotation and slew of each letter. I thought there was now standard code in the plplot library for that? Or is it a bug in that standard code? (2) Memory management issues Here is the associated error message (after I hit one additional CR after the last page of example 8 is displayed) *** glibc detected *** double free or corruption (!prev): 0x08050358 *** Unless there is some internal problem in the Ubuntu Dapper libraries (this is possible since these are old versions of each library) it sounds like your code might be trying to free something that has already been freed. 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 __________________________ |
From: Hazen B. <hba...@ma...> - 2007-06-07 00:28:50
|
On Jun 4, 2007, at 10:17 PM, Alan W. Irwin wrote: > On 2007-06-04 21:17-0400 Hazen Babcock wrote: > >> On Jun 3, 2007, at 7:30 PM, Alan W. Irwin wrote: > >>> (1) the 'ldd -r cairo.so' test showed the >>> following problems: >>> >>> undefined symbol: cairo_ps_surface_create (./cairo.so) >>> undefined symbol: cairo_pdf_surface_create (./cairo.so) >>> undefined symbol: cairo_svg_surface_create (./cairo.so) >>> >>> It's fairly urgent to solve these problems since it excludes any >>> testing >>> of >>> the pscairo, pdfcairo, or svgcairo devices on Linux. >> >> Maybe this is because I have Cairo v1.2.6 and debian testing is >> v1.2.4? >> According the cairo docs these functions have been in the library >> since 1.2. > > That's the best background I can give you about how relevant > libcairo-1.0.4 > will be in the future, and I will let you be the judge whether you > want to > support this older version of libcairo or not. I hope to install > debian > testing some time this summer after I finish my current research > project, > and after that old libcairo versions won't be an issue for me. Since it seems to work for xcairo I don't think there should be a problem supporting it. We'll turn off the ps,pdf and svg drivers for those with older versions of libcairo. >>> (2) ./x08c -dev xcairo shows only the first page of that example. >> >> Hm. On OS-X I get a bus error. It is interesting that it works >> fine if you >> just type ./x08c and then choose the driver. > > ./x08c -dev xcairo now actually pretty much works for me. I > finally figured > out that you should hit CR in the xterm where that command-line is > typed and > not the GUI (at least when threading is not turned on). > > Now that I know how to run it, "./x08c -dev xcairo" shows some issues. > > (1) The 3D labelling needs work on the transformation to determine the > rotation and slew of each letter. I thought there was now standard > code > in the plplot library for that? Or is it a bug in that standard code? It also looks kind of funny on my machine. I'll have a look. There is a function for this now called plRotationShear(), perhaps it using the wrong coordinate system, i.e. device versus physical versus world? > (2) Memory management issues > > Here is the associated error message (after I hit one additional CR > after > the last page of example 8 is displayed) > > *** glibc detected *** double free or corruption (!prev): > 0x08050358 *** > > Unless there is some internal problem in the Ubuntu Dapper > libraries (this > is possible since these are old versions of each library) it sounds > like > your code might be trying to free something that has already been > freed. I'm not seeing this in OS-X. If you are so inclined, could you go to the sub-routine plD_tidy_xcairo(), line 783, in cairo.c and comment out the call to plD_tidy_cairo() and/or the call to free() on line 796 and let me know which one (if either) makes this message go away? thanks, -Hazen |
From: Alan W. I. <ir...@be...> - 2007-06-07 01:48:44
|
On 2007-06-06 20:26-0400 Hazen Babcock wrote: > > On Jun 4, 2007, at 10:17 PM, Alan W. Irwin wrote: >> (2) Memory management issues >> >> Here is the associated error message (after I hit one additional CR after >> the last page of example 8 is displayed) >> >> *** glibc detected *** double free or corruption (!prev): 0x08050358 *** >> >> Unless there is some internal problem in the Ubuntu Dapper libraries (this >> is possible since these are old versions of each library) it sounds like >> your code might be trying to free something that has already been freed. > > I'm not seeing this in OS-X. If you are so inclined, could you go to the > sub-routine plD_tidy_xcairo(), line 783, in cairo.c and comment out the call > to plD_tidy_cairo() and/or the call to free() on line 796 and let me know > which one (if either) makes this message go away? Commenting out just plD_tidy_cairo() on line 783 makes no obvious difference and I still get the above error message. Commenting out just free() on line 796 gets rid of the above error message. Commenting out both lines also seems to get rid of the above error message, but I assume that is not the correct fix since the free seems to be the culprit. 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2007-06-07 02:31:06
|
On 2007-06-06 18:48-0700 Alan W. Irwin wrote: > On 2007-06-06 20:26-0400 Hazen Babcock wrote: > >> >> On Jun 4, 2007, at 10:17 PM, Alan W. Irwin wrote: >>> (2) Memory management issues >>> >>> Here is the associated error message (after I hit one additional CR after >>> the last page of example 8 is displayed) >>> >>> *** glibc detected *** double free or corruption (!prev): 0x08050358 *** >>> >>> Unless there is some internal problem in the Ubuntu Dapper libraries (this >>> is possible since these are old versions of each library) it sounds like >>> your code might be trying to free something that has already been freed. >> >> I'm not seeing this in OS-X. If you are so inclined, could you go to the >> sub-routine plD_tidy_xcairo(), line 783, in cairo.c and comment out the call >> to plD_tidy_cairo() and/or the call to free() on line 796 and let me know >> which one (if either) makes this message go away? > > Commenting out just plD_tidy_cairo() on line 783 makes no obvious difference > and I still get the above error message. > > Commenting out just free() on line 796 gets rid of the above error message. > > Commenting out both lines also seems to get rid of the above error message, > but I assume that is not the correct fix since the free seems to be the > culprit. BTW, we worked hard in the old days to get both the memory management and familying issues correct for gd.c. So if you follow that general pattern (albeit with libcairo specifics), you should be okay. 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2007-06-12 23:12:50
|
On 2007-06-10 00:43-0400 Hazen Babcock wrote: > > On Jun 4, 2007, at 9:17 PM, Hazen Babcock wrote: > >> On Jun 3, 2007, at 7:30 PM, Alan W. Irwin wrote: >>> >>> That is correct. The way this is taken care of for the png device >>> (as well >>> as jpeg and gif) for gd.c is to use the normal PLplot familying >>> facility >>> (see >>> http://plplot.sourceforge.net/docbook-manual/plplot-html-5.7.3/ >>> output-devices.html#familying). >>> It's a bit tricky to set up, but if you follow what is done for >>> gd.c, you >>> should be fine. I thought you might have inadvertently set up >>> familying >>> already simply by following what is done in gd.c, but apparently >>> not since >>> the -fam command-line option only gives the same last page of >>> example 8 that >>> you get without the option. >> >> Ok. I'll implement this approach. > > The -fam option should now work with pngcairo. Hi Hazen: Your latest svn commit has a syntax error (as well as additional warnings) in cairo.c on my Ubuntu Dapper system. /usr/bin/gcc -Dcairo_EXPORTS -fPIC -I/home/software/plplot_cvs/HEAD/plplot_cmake/include -I/home/software/plplot_cvs/HEAD/build_dir -I/home/software/plplot_cvs/HEAD/build_dir/include -DHAVE_CONFIG_H -I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include /usr/include /usr/include -o drivers/CMakeFiles/cairo.dir/cairo.o -c /home/software/plplot_cvs/HEAD/plplot_cmake/drivers/cairo.c /home/software/plplot_cvs/HEAD/plplot_cmake/drivers/cairo.c: In function = =E2 dy_xcairo=E2: /home/software/plplot_cvs/HEAD/plplot_cmake/drivers/cairo.c:796: error: syntax error before =E2 token /home/software/plplot_cvs/HEAD/plplot_cmake/drivers/cairo.c: In function = =E2 it_pdfcairo=E2: /home/software/plplot_cvs/HEAD/plplot_cmake/drivers/cairo.c:934: warning: assignment makes pointer from integer without a cast /home/software/plplot_cvs/HEAD/plplot_cmake/drivers/cairo.c: In function = =E2 it_pscairo=E2: /home/software/plplot_cvs/HEAD/plplot_cmake/drivers/cairo.c:1007: warning: assignment makes pointer from integer without a cast /home/software/plplot_cvs/HEAD/plplot_cmake/drivers/cairo.c: In function = =E2 it_svgcairo=E2: /home/software/plplot_cvs/HEAD/plplot_cmake/drivers/cairo.c:1083: warning: assignment makes pointer from integer without a cast The syntax error on line 796 is a showstopper. It is caused by a svn conflict that you have to resolve yourself. 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 __________________________ |
From: Hazen B. <hba...@ma...> - 2007-06-13 01:58:23
|
On Jun 12, 2007, at 7:12 PM, Alan W. Irwin wrote: > On 2007-06-10 00:43-0400 Hazen Babcock wrote: > >> The -fam option should now work with pngcairo. > > Hi Hazen: > > Your latest svn commit has a syntax error (as well as additional =20 > warnings) > in cairo.c on my Ubuntu Dapper system. > > /usr/bin/gcc -Dcairo_EXPORTS -fPIC > -I/home/software/plplot_cvs/HEAD/plplot_cmake/include > -I/home/software/plplot_cvs/HEAD/build_dir > -I/home/software/plplot_cvs/HEAD/build_dir/include -DHAVE_CONFIG_H > -I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -I/usr/include /usr/include /usr/=20 > include -o > drivers/CMakeFiles/cairo.dir/cairo.o -c > /home/software/plplot_cvs/HEAD/plplot_cmake/drivers/cairo.c > > /home/software/plplot_cvs/HEAD/plplot_cmake/drivers/cairo.c: In =20 > function =E2 > dy_xcairo=E2: > /home/software/plplot_cvs/HEAD/plplot_cmake/drivers/cairo.c:796: =20 > error: > syntax error before =E2 token > /home/software/plplot_cvs/HEAD/plplot_cmake/drivers/cairo.c: In =20 > function =E2 > it_pdfcairo=E2: > /home/software/plplot_cvs/HEAD/plplot_cmake/drivers/cairo.c:934: =20 > warning: > assignment makes pointer from integer without a cast > /home/software/plplot_cvs/HEAD/plplot_cmake/drivers/cairo.c: In =20 > function =E2 > it_pscairo=E2: > /home/software/plplot_cvs/HEAD/plplot_cmake/drivers/cairo.c:1007: =20 > warning: > assignment makes pointer from integer without a cast > /home/software/plplot_cvs/HEAD/plplot_cmake/drivers/cairo.c: In =20 > function =E2 > it_svgcairo=E2: > /home/software/plplot_cvs/HEAD/plplot_cmake/drivers/cairo.c:1083: =20 > warning: > assignment makes pointer from integer without a cast > > The syntax error on line 796 is a showstopper. It is caused by a svn > conflict that you have to resolve yourself. I'm puzzled. I don't have this problem on either my linux or OS-X =20 box. What do you mean by a svn conflict? -Hazen |
From: Alan W. I. <ir...@be...> - 2007-06-13 05:51:18
|
On 2007-06-12 21:56-0400 Hazen Babcock wrote: >> The syntax error on line 796 is a showstopper. It is caused by a svn >> conflict that you have to resolve yourself. > > I'm puzzled. I don't have this problem on either my linux or OS-X box. What > do you mean by a svn conflict? Never mind and sorry for the noise. I generated the conflict (which is only local to my own computer) myself because I forgot to delete a local change you asked me to make for a previous test before bringing in all your changes. The cure was simple; delete my local copy of cairo.c and svn update again to get exactly the source code you also have on your computer. After a build, install, and installed examples build, I tried "./x08c -dev pngcairo -o test.png -fam" and the results looked really sharp (aside from the 3D character problems I mentioned before). 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 __________________________ |
From: Hazen B. <hba...@ma...> - 2007-06-14 02:31:01
|
On Jun 13, 2007, at 1:49 AM, Alan W. Irwin wrote: > On 2007-06-12 21:56-0400 Hazen Babcock wrote: > >>> The syntax error on line 796 is a showstopper. It is caused by a >>> svn >>> conflict that you have to resolve yourself. >> >> I'm puzzled. I don't have this problem on either my linux or OS-X >> box. What do you mean by a svn conflict? > > After a build, install, and installed examples build, I tried "./ > x08c -dev > pngcairo -o test.png -fam" and the results looked really sharp > (aside from > the 3D character problems I mentioned before). Good to hear. I'm still puzzling over the 3D character problems. It looks like the characters are not being sheared the proper amount, but I have yet to find my math mistake in setting up the transformation matrix. -Hazen |
From: Hazen B. <hba...@ma...> - 2007-06-17 02:26:21
|
On Jun 13, 2007, at 10:28 PM, Hazen Babcock wrote: > > On Jun 13, 2007, at 1:49 AM, Alan W. Irwin wrote: > >> On 2007-06-12 21:56-0400 Hazen Babcock wrote: >> >>>> The syntax error on line 796 is a showstopper. It is caused by a >>>> svn >>>> conflict that you have to resolve yourself. >>> >>> I'm puzzled. I don't have this problem on either my linux or OS-X >>> box. What do you mean by a svn conflict? >> >> After a build, install, and installed examples build, I tried "./ >> x08c -dev >> pngcairo -o test.png -fam" and the results looked really sharp >> (aside from >> the 3D character problems I mentioned before). > > Good to hear. I'm still puzzling over the 3D character problems. It > looks like the characters are not being sheared the proper amount, > but I have yet to find my math mistake in setting up the > transformation matrix. I think I've figured out what the problem was with the transformation matrix and I've just committed the fix. -Hazen |
From: Alan W. I. <ir...@be...> - 2007-08-05 18:56:01
|
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: software@chickadee> 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 __________________________ |
From: Hazen B. <hba...@ma...> - 2007-08-06 01:54:07
|
On Aug 5, 2007, at 2:56 PM, Alan W. Irwin wrote: > On 2007-08-05 12:02-0400 Hazen Babcock wrote: >> >> 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. I was able to fix this, so you should now be able to write to stdout. The bounding box issue is going to take some more fiddling. I think I was misled by the default ps viewer on OS-X, "Preview", which seems to resize so that the plot is not clipped. I'll start testing using my linux box and ghostview instead. -Hazen |
From: Hazen B. <hba...@ma...> - 2007-08-07 04:30:42
|
On Aug 5, 2007, at 2:56 PM, Alan W. Irwin wrote: > 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. Ok, I may have fixed this, at least for linux users. It was pretty simple but also a bit puzzling. I don't really understand why Preview on OS-X was mangling the plots. To compensate I was setting the bounding box and then rotating the plot so that it would appear right side up and inside the bounding box in Preview. To get the right results with gv on linux I had to drop the rotation, but I still choose to flip the plot vertically so that it would appear right side up. Let me know if that was also a mistake. Anyway, I'll assume that the gv is correctly following the postscript standard and I will use it for future testing of this driver. -Hazen |
From: Alan W. I. <ir...@be...> - 2007-08-07 16:08:55
|
On 2007-08-07 00:28-0400 Hazen Babcock wrote: > > On Aug 5, 2007, at 2:56 PM, Alan W. Irwin wrote: > >> 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. > > Ok, I may have fixed this, at least for linux users. It was pretty simple but > also a bit puzzling. I don't really understand why Preview on OS-X was > mangling the plots. To compensate I was setting the bounding box and then > rotating the plot so that it would appear right side up and inside the > bounding box in Preview. To get the right results with gv on linux I had to > drop the rotation, but I still choose to flip the plot vertically so that it > would appear right side up. Let me know if that was also a mistake. Anyway, > I'll assume that the gv is correctly following the postscript standard and I > will use it for future testing of this driver. The orientation you had before was correct. i.e., the previous pscairo results and also ps and psttf view correctly under gv _only_ when you change its view to landscape. In the future, once you get the PLplot -portrait mode to work for pscairo, then those results (and also ps and psttf with -portrait mode) will view correctly under gv only when you use its (default) portrait mode. 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 __________________________ |
From: Hazen B. <hba...@ma...> - 2007-08-08 00:33:15
|
On Aug 7, 2007, at 12:08 PM, Alan W. Irwin wrote: > On 2007-08-07 00:28-0400 Hazen Babcock wrote: > >> >> On Aug 5, 2007, at 2:56 PM, Alan W. Irwin wrote: >> >> Ok, I may have fixed this, at least for linux users. It was pretty >> simple but >> also a bit puzzling. I don't really understand why Preview on OS-X >> was >> mangling the plots. To compensate I was setting the bounding box >> and then >> rotating the plot so that it would appear right side up and inside >> the >> bounding box in Preview. To get the right results with gv on linux >> I had to >> drop the rotation, but I still choose to flip the plot vertically >> so that it >> would appear right side up. Let me know if that was also a >> mistake. Anyway, >> I'll assume that the gv is correctly following the postscript >> standard and I >> will use it for future testing of this driver. > > The orientation you had before was correct. i.e., the previous > pscairo > results and also ps and psttf view correctly under gv _only_ when > you change > its view to landscape. I've changed the orientation back and the bounding box should now also be correct. The ability to change the plot orientation remains unimplemented. -Hazen |
From: Alan W. I. <ir...@be...> - 2007-08-08 21:27:38
|
Just to review the status here, Hazen has fixed the stdout issue (issue 2), and a resolution problem (issue 6 discussed off list with Hazen). Here are the remaining issues that I am aware of. (1) The bounding box is still not quite correct. Hazen has fixed the major problem (swapping of X and Y coordinates of the bounding box) so at least the bounding box is no longer smaller than the actual plot either coordinate. What remains to be done is to shrink the somewhat too large size of the current bounding box to the actual extent of the plotting data for each individual case. This is a standard postscript issue so libcairo may have a solution for it (i.e., returning the maximum x and y ranges of the plotting surface that was used), but what we have now is acceptable for most uses. (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 but their size is too large. To see this I suggest you visually compare with the same plot generated with -dev psc. (4) Text clipping has not yet been implemented. (The first page of example 9 shows this issue.) (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. Unlike what I said before, it turns out I do need the -portrait option for one of my research plots so that is a showstopper for my particular case. >From a general perspective, though, issues 3 (which by some chance does not affect me for the 3D angles I happen to be using for my research plots) and issues 4 are probably more important than the -portrait issue. Issue (1) should have a much lower priority since it is in the "would be nice" category. Thanks, Hazen, for your on-going efforts to improve the cairo device driver. 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 __________________________ |
From: Hazen B. <hba...@ma...> - 2007-08-12 01:07:49
|
On Aug 8, 2007, at 5:27 PM, Alan W. Irwin wrote: > Just to review the status here, Hazen has fixed the stdout issue > (issue 2), > and a resolution problem (issue 6 discussed off list with Hazen). > Here > are the remaining issues that I am aware of. > > (1) The bounding box is still not quite correct. Hazen has fixed > the major > problem (swapping of X and Y coordinates of the bounding box) so at > least > the bounding box is no longer smaller than the actual plot either > coordinate. What remains to be done is to shrink the somewhat too > large size > of the current bounding box to the actual extent of the plotting > data for > each individual case. This is a standard postscript issue so > libcairo may > have a solution for it (i.e., returning the maximum x and y ranges > of the > plotting surface that was used), but what we have now is acceptable > for most > uses. The cairo driver plots look the same across different types of output. I don't think this will be easy to change since this consistency is one of the goals of the cairo project. > (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 but their size is too large. To see this I > suggest you > visually compare with the same plot generated with -dev psc. > > (4) Text clipping has not yet been implemented. (The first page of > example 9 > shows this issue.) I'm pretty sure that none of the drivers I've nominally been responsible for (aqt, svg and cairo) implement text clipping. I'll see what I can do... > (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. The driver itself ignores both flags. > Unlike what I said before, it turns out I do need the -portrait > option for > one of my research plots so that is a showstopper for my particular > case. >> From a general perspective, though, issues 3 (which by some chance >> does not > affect me for the 3D angles I happen to be using for my research > plots) and > issues 4 are probably more important than the -portrait issue. > Issue (1) > should have a much lower priority since it is in the "would be nice" > category. Should I continue to address these issues rather than the next release? -Hazen |
From: Alan W. I. <ir...@be...> - 2007-08-12 04:48:57
|
On 2007-08-11 21:05-0400 Hazen Babcock wrote: > > On Aug 8, 2007, at 5:27 PM, Alan W. Irwin wrote: > >> Just to review the status here, Hazen has fixed the stdout issue (issue >> 2), >> and a resolution problem (issue 6 discussed off list with Hazen). Here >> are the remaining issues that I am aware of. >> >> (1) The bounding box is still not quite correct. Hazen has fixed the major >> problem (swapping of X and Y coordinates of the bounding box) so at least >> the bounding box is no longer smaller than the actual plot either >> coordinate. What remains to be done is to shrink the somewhat too large >> size >> of the current bounding box to the actual extent of the plotting data for >> each individual case. This is a standard postscript issue so libcairo may >> have a solution for it (i.e., returning the maximum x and y ranges of the >> plotting surface that was used), but what we have now is acceptable for >> most >> uses. > > The cairo driver plots look the same across different types of output. I > don't think this will be easy to change since this consistency is one of the > goals of the cairo project. OK. Good point. > >> (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 but their size is too large. To see this I suggest you >> visually compare with the same plot generated with -dev psc. >> >> (4) Text clipping has not yet been implemented. (The first page of example >> 9 >> shows this issue.) > > I'm pretty sure that none of the drivers I've nominally been responsible for > (aqt, svg and cairo) implement text clipping. I'll see what I can do... > >> (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. > > The driver itself ignores both flags. > >> Unlike what I said before, it turns out I do need the -portrait option for >> one of my research plots so that is a showstopper for my particular case. >>> From a general perspective, though, issues 3 (which by some chance does >>> not >> affect me for the 3D angles I happen to be using for my research plots) >> and >> issues 4 are probably more important than the -portrait issue. Issue (1) >> should have a much lower priority since it is in the "would be nice" >> category. > > Should I continue to address these issues rather than the next release? Whatever course is more efficient for you is probably the one you should follow. Whatever you decide is fine with me. 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 __________________________ |
From: Orion P. <or...@co...> - 2007-08-13 20:46:45
|
Alan W. Irwin wrote: > On 2007-08-11 21:05-0400 Hazen Babcock wrote: >> Should I continue to address these issues rather than the next release? > > Whatever course is more efficient for you is probably the one you should > follow. Whatever you decide is fine with me. > From my perspective, it would be nice if 5.7.4 (or even a release candidate) was ready by the August 28th feature freeze for Fedora 8. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane or...@co... Boulder, CO 80301 http://www.cora.nwra.com |