From: David M. <da...@as...> - 2010-01-04 22:24:40
|
I've been playing with the x01c example and have noticed that the postscript output obtained by using the "-save" option depends on the device chosen. Am I doing something wrong or (more likely) not understanding what plcpstrm does? Without attaching the actual files, here's an indication of what happens... $ ./x01c -dev xwin -save xwin.ps PLplot library version: 5.9.5 The current plot was saved in color Postscript under the name `xwin.ps'. $ ./x01c -dev xcairo -save xcairo.ps PLplot library version: 5.9.5 The current plot was saved in color Postscript under the name `xcairo.ps'. $ sum *ps 42669 29 xcairo.ps 42340 80 xwin.ps I was expecting them to be independent of the driver chosen, but now I'm starting to think that maybe some device info is getting copied to the "cps" stream during "plcpstrm(cur_stream, 0);". Even if that is the case, I still have a problem. The on-screen output from both the xwin and xcairo devices looks fine, but neither of the postscript files looks as expected. xwin.ps looks OK except that the lower right plot (from plot3()) is "dim" compared to the other three. xcairo.ps has no text and the edges of the "page" are flush with the "outer" edges of the four plots. FWIW, I am using PLplot version 5.9.5 (the tarball release) installed on a Mac (OS X 10.4.11) via MacPorts. Actual files are available at... http://astro.berkeley.edu/~davidm/xwin.ps http://astro.berkeley.edu/~davidm/xcairo.ps Thanks, Dave |
From: Alan W. I. <ir...@be...> - 2010-01-04 23:55:03
|
On 2010-01-04 14:24-0800 David MacMahon wrote: > I've been playing with the x01c example and have noticed that the > postscript output obtained by using the "-save" option depends on the > device chosen. >[...] > $ ./x01c -dev xwin -save xwin.ps > PLplot library version: 5.9.5 > The current plot was saved in color Postscript under the name `xwin.ps'. > > $ ./x01c -dev xcairo -save xcairo.ps > PLplot library version: 5.9.5 > The current plot was saved in color Postscript under the name > `xcairo.ps'. > > $ sum *ps > 42669 29 xcairo.ps > 42340 80 xwin.ps > [...] The on-screen > output from both the xwin and xcairo devices looks fine, but neither > of the postscript files looks as expected. xwin.ps looks OK except > that the lower right plot (from plot3()) is "dim" compared to the > other three. xcairo.ps has no text and the edges of the "page" are > flush with the "outer" edges of the four plots. Hi David: Thanks for your -save report. For your xwin.ps result (and also my own as viewed with gv) I don't believe plot 3 is any dimmer than the rest. That plot does have green labels which may give a dimmer appearance than the yellow labels on the other plots, but the red lines and red text labelling the axes look the same as for the other plots to my eyes. If after looking at it again you still feel there is a brightness difference, please send (or put up on a website) screenshots which show the brightness difference for plot 3 for the direct -dev xwin result versus the -saveD PostScript result. IIRC, there was a text issue for -save with -dev xcairo for 5.9.5 which has been fixed since. Anyhow, I just tried the svn trunk version, and xcairo.ps does have text. There is still an issue with superscripts, however. The rest of this is addressed to Hazen who is the principal developer for the cairo device driver. Please verify for yourself the superscript issue for -saveD results for -dev xcairo. Also, if you think it will take a while to fix this issue, let me know, and I will put it in the bug tracker. 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: David M. <da...@as...> - 2010-01-05 01:10:48
|
Hi, Alan, On Jan 4, 2010, at 16:52 , David MacMahon wrote: > On Jan 4, 2010, at 15:54 , Alan W. Irwin wrote: > >> On 2010-01-04 14:24-0800 David MacMahon wrote: >> >> For your xwin.ps result (and also my own as viewed with gv) I >> don't believe >> plot 3 is any dimmer than the rest. > > Thanks for your reply, Alan. I tried viewing xwin.ps on Linux > using "gv" and it looks fine. I guess there is something in the > PostScript that the Apple viewer does not like. I've attached a > (hopefully small) screen shot showing the appearance in both gv > (running on Linux) and Safari (Apple's browser running on MacOSX). I think the plwid(1) call in plot2() results in the line widths being thinner in the final plot than in the other three plots. If you zoom in using gv, you will see that the text has an outline appearance and that the lines are thinner than on the previous plots. If I disable the Apple viewer's "Anti-alias text and line art" option, then it looks the same as in gv. Also, if I comment out the plwid() calls in plot2() (in x01c.c), the - saveD postscript looks OK even with the viewer's anti-alias option on. Is the "plwid(1)" call in plot2() using an incorrect value to restore the line width? Thanks, Dave |
From: David M. <da...@as...> - 2010-01-05 06:15:50
Attachments:
pastedGraphic.png
pastedGraphic.png
|
Sorry for responding to my own posts so much, but... On Jan 4, 2010, at 17:10 , David MacMahon wrote: > Is the "plwid(1)" call in plot2() using an incorrect value to restore > the line width? If I change that call in x01c.c to "plwid(0)", then the final plot in the -saveD postscript file has thicker lines than I got with the original "plwid(1)" call. Zooming in 10x on the -saveD postscript output (using gv on Linux with no anti-aliasing), I get this 'P' in the caption of the final plot (using xwin driver) after plwid(1)... |
From: Hazen B. <hba...@ma...> - 2010-01-05 19:33:58
|
Alan W. Irwin wrote: > On 2010-01-04 14:24-0800 David MacMahon wrote: > >> I've been playing with the x01c example and have noticed that the >> postscript output obtained by using the "-save" option depends on the >> device chosen. >> [...] >> $ ./x01c -dev xwin -save xwin.ps >> PLplot library version: 5.9.5 >> The current plot was saved in color Postscript under the name `xwin.ps'. >> >> $ ./x01c -dev xcairo -save xcairo.ps >> PLplot library version: 5.9.5 >> The current plot was saved in color Postscript under the name >> `xcairo.ps'. >> >> $ sum *ps >> 42669 29 xcairo.ps >> 42340 80 xwin.ps >> [...] The on-screen >> output from both the xwin and xcairo devices looks fine, but neither >> of the postscript files looks as expected. xwin.ps looks OK except >> that the lower right plot (from plot3()) is "dim" compared to the >> other three. xcairo.ps has no text and the edges of the "page" are >> flush with the "outer" edges of the four plots. > > Hi David: > > Thanks for your -save report. > > For your xwin.ps result (and also my own as viewed with gv) I don't believe > plot 3 is any dimmer than the rest. That plot does have green labels which > may give a dimmer appearance than the yellow labels on the other plots, but > the red lines and red text labelling the axes look the same as for the other > plots to my eyes. If after looking at it again you still feel there is a > brightness difference, please send (or put up on a website) screenshots > which show the brightness difference for plot 3 for the direct -dev xwin > result versus the -saveD PostScript result. > > IIRC, there was a text issue for -save with -dev xcairo for 5.9.5 which has > been fixed since. Anyhow, I just tried the svn trunk version, and xcairo.ps > does have text. There is still an issue with superscripts, however. > > The rest of this is addressed to Hazen who is the principal developer for > the cairo device driver. Please verify for yourself the superscript issue > for -saveD results for -dev xcairo. Also, if you think it will take a while > to fix this issue, let me know, and I will put it in the bug tracker. I'd almost forgotten about this issue. It will take me a while so I'd put it in the tracker. As we discussed in the past it is most likely related to the cairo drivers using the new text rendering path instead of the old. Perhaps it is some sort of memory corruption issue, however, I really don't understand how this could specifically strip the text formatting without otherwise corrupting the string. -Hazen |
From: Hazen B. <hba...@ma...> - 2010-01-06 21:38:37
|
Hazen Babcock wrote: > Alan W. Irwin wrote: >> On 2010-01-04 14:24-0800 David MacMahon wrote: >> >>> I've been playing with the x01c example and have noticed that the >>> postscript output obtained by using the "-save" option depends on the >>> device chosen. >>> [...] >>> $ ./x01c -dev xwin -save xwin.ps >>> PLplot library version: 5.9.5 >>> The current plot was saved in color Postscript under the name `xwin.ps'. >>> >>> $ ./x01c -dev xcairo -save xcairo.ps >>> PLplot library version: 5.9.5 >>> The current plot was saved in color Postscript under the name >>> `xcairo.ps'. >>> >>> $ sum *ps >>> 42669 29 xcairo.ps >>> 42340 80 xwin.ps >>> [...] The on-screen >>> output from both the xwin and xcairo devices looks fine, but neither >>> of the postscript files looks as expected. xwin.ps looks OK except >>> that the lower right plot (from plot3()) is "dim" compared to the >>> other three. xcairo.ps has no text and the edges of the "page" are >>> flush with the "outer" edges of the four plots. >> Hi David: >> >> Thanks for your -save report. >> >> For your xwin.ps result (and also my own as viewed with gv) I don't believe >> plot 3 is any dimmer than the rest. That plot does have green labels which >> may give a dimmer appearance than the yellow labels on the other plots, but >> the red lines and red text labelling the axes look the same as for the other >> plots to my eyes. If after looking at it again you still feel there is a >> brightness difference, please send (or put up on a website) screenshots >> which show the brightness difference for plot 3 for the direct -dev xwin >> result versus the -saveD PostScript result. >> >> IIRC, there was a text issue for -save with -dev xcairo for 5.9.5 which has >> been fixed since. Anyhow, I just tried the svn trunk version, and xcairo.ps >> does have text. There is still an issue with superscripts, however. >> >> The rest of this is addressed to Hazen who is the principal developer for >> the cairo device driver. Please verify for yourself the superscript issue >> for -saveD results for -dev xcairo. Also, if you think it will take a while >> to fix this issue, let me know, and I will put it in the bug tracker. > > I'd almost forgotten about this issue. It will take me a while so I'd > put it in the tracker. As we discussed in the past it is most likely > related to the cairo drivers using the new text rendering path instead > of the old. Perhaps it is some sort of memory corruption issue, however, > I really don't understand how this could specifically strip the text > formatting without otherwise corrupting the string. Hopefully I've managed to fix this in v10738. I also ran uncrustify on the file since we seem to be using a tab spacing that is not the emacs default. Unfortunately this seems to have introduced a lot of other changes unrelated to the changes that I actually made, which were only to the plP_text function. -Hazen |
From: Alan W. I. <ir...@be...> - 2010-01-06 23:27:43
|
On 2010-01-06 16:38-0500 Hazen Babcock wrote: > [...]I also ran uncrustify on the > file since we seem to be using a tab spacing that is not the emacs default. > Unfortunately this seems to have introduced a lot of other changes unrelated > to the changes that I actually made, which were only to the plP_text > function. Were you using "scripts/style_source.sh --apply"? That script should style all our files with uncrustify in the proper way including no tabs anywhere. When I ran "scripts/style_source.sh --diff -au |less" here I found there were some incorrect whitespace changes introduced by your commit which I fixed by running "scripts/style_source.sh --apply" (revision 10739). If you want to find out more about that script, please run "scripts/style_source.sh --help". As a check please run "scripts/style_source.sh" now with no options for revision 10739. Assuming nothing is wrong with your version of uncrustify, it should give no result at all indicating all our C, C++, D, and Java source files have the correct style as specified by uncrustify.cfg in the top-level source tree directory. Do you obtain that good null result? 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...> - 2010-01-06 23:49:24
|
On 2010-01-06 16:38-0500 Hazen Babcock wrote: > Hazen Babcock wrote: >> Alan W. Irwin wrote: >>> The rest of this is addressed to Hazen who is the principal developer for >>> the cairo device driver. Please verify for yourself the superscript issue >>> for -saveD results for -dev xcairo. Also, if you think it will take a >>> while >>> to fix this issue, let me know, and I will put it in the bug tracker. >> >> I'd almost forgotten about this issue. It will take me a while so I'd put >> it in the tracker. As we discussed in the past it is most likely related to >> the cairo drivers using the new text rendering path instead of the old. >> Perhaps it is some sort of memory corruption issue, however, I really don't >> understand how this could specifically strip the text formatting without >> otherwise corrupting the string. > > Hopefully I've managed to fix this in v10738. Thanks for this. The PostScript save result with xcairo certainly looks good here so I think you should go ahead and close bug 2926482. I noticed your changes nicely separated out the code for the plsc->alt_unicode true case into its own independent loop in plP_text starting at line 889 of plcore.c. However, as a matter of efficiency can't all/most of the code in the remaining loop in plP_text starting at line 653 of plcore.c be skipped when plsc->alt_unicode is true? 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...> - 2010-01-06 23:55:19
|
Alan W. Irwin wrote: > On 2010-01-06 16:38-0500 Hazen Babcock wrote: > >> Hazen Babcock wrote: >>> Alan W. Irwin wrote: >>>> The rest of this is addressed to Hazen who is the principal developer for >>>> the cairo device driver. Please verify for yourself the superscript issue >>>> for -saveD results for -dev xcairo. Also, if you think it will take a >>>> while >>>> to fix this issue, let me know, and I will put it in the bug tracker. >>> I'd almost forgotten about this issue. It will take me a while so I'd put >>> it in the tracker. As we discussed in the past it is most likely related to >>> the cairo drivers using the new text rendering path instead of the old. >>> Perhaps it is some sort of memory corruption issue, however, I really don't >>> understand how this could specifically strip the text formatting without >>> otherwise corrupting the string. >> Hopefully I've managed to fix this in v10738. > > Thanks for this. The PostScript save result with xcairo certainly looks > good here so I think you should go ahead and close bug 2926482. > > I noticed your changes nicely separated out the code for the > plsc->alt_unicode true case into its own independent loop in plP_text > starting at line 889 of plcore.c. However, as a matter of efficiency can't > all/most of the code in the remaining loop in plP_text starting at line 653 > of plcore.c be skipped when plsc->alt_unicode is true? Unfortunately not if we want the postscript save feature to work. -Hazen |
From: Alan W. I. <ir...@be...> - 2010-01-07 01:52:26
|
On 2010-01-06 18:55-0500 Hazen Babcock wrote: >> I noticed your changes nicely separated out the code for the >> plsc->alt_unicode true case into its own independent loop in plP_text >> starting at line 889 of plcore.c. However, as a matter of efficiency can't >> all/most of the code in the remaining loop in plP_text starting at line 653 >> of plcore.c be skipped when plsc->alt_unicode is true? > > Unfortunately not if we want the postscript save feature to work. Hi Hazen (off list): Could you explain further, please? My problem is I don't have a clear overview of what exactly is going on with the plreplot call used by the -save feature so if you could give me that overview, it would be much appreciated. Assuming you are willing to put together such an overview, I would be happy to make it the basis of much better documentation for plreplot. 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...> - 2010-01-20 03:31:45
|
Alan W. Irwin wrote: > On 2010-01-06 16:38-0500 Hazen Babcock wrote: > >> [...]I also ran uncrustify on the >> file since we seem to be using a tab spacing that is not the emacs default. >> Unfortunately this seems to have introduced a lot of other changes unrelated >> to the changes that I actually made, which were only to the plP_text >> function. > > Were you using "scripts/style_source.sh --apply"? That script should style > all our files with uncrustify in the proper way including no tabs anywhere. > When I ran "scripts/style_source.sh --diff -au |less" here I found there > were some incorrect whitespace changes introduced by your commit which I > fixed by running "scripts/style_source.sh --apply" (revision 10739). > > If you want to find out more about that script, please run > "scripts/style_source.sh --help". How hard is it to make it so that you specify that it just run on one particular file. Maybe something like? ./scripts/style_source.sh --file ./drivers/cairo.c --apply -Hazen |
From: Alan W. I. <ir...@be...> - 2010-01-20 06:44:31
|
On 2010-01-19 22:31-0500 Hazen Babcock wrote: > How hard is it to make it so that you specify that it just run on one > particular file. Maybe something like? > > ./scripts/style_source.sh --file ./drivers/cairo.c --apply Hi Hazen: I am going to shift this development discussion to plplot-devel for obvious reasons. 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 __________________________ |