From: Hazen B. <hba...@ma...> - 2007-08-16 01:43:37
|
On Aug 8, 2007, at 5:27 PM, Alan W. Irwin wrote: > (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. It looks like the ps driver supports this option but the xwin driver does not. Should all of the cairo drivers have a portrait option? Or is this only considered useful for file devices? When you create a plot in portrait mode with the ps driver the x and y pages sizes are not interchanged so the plot comes out looking a little strange, i.e. somewhat tall and narrow. Is this the "Right Thing To Do"? Or should portrait mode simply be a 90 degree rotation of the plot? thanks, -Hazen |
From: Hazen B. <hba...@ma...> - 2007-08-16 03:27:04
|
On Aug 8, 2007, at 5:27 PM, Alan W. Irwin wrote: > (4) Text clipping has not yet been implemented. (The first page of > example 9 > shows this issue.) I've committed a version that implements text clipping. I understand that it isn't quite correct since it does not use difilt() to adjust the coordinates, however it should work for example 9. That said, it makes plotting using Cairo a lot slower on my linux box (10-100X?), so I'm wondering whether this should be optional. best, -Hazen |
From: Alan W. I. <ir...@be...> - 2007-08-16 03:16:32
|
On 2007-08-15 21:41-0400 Hazen Babcock wrote: > > On Aug 8, 2007, at 5:27 PM, Alan W. Irwin wrote: > >> (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. > > It looks like the ps driver supports this option but the xwin driver does > not. Should all of the cairo drivers have a portrait option? Or is this only > considered useful for file devices? Actually, I think it is only relevant to devices such as pscairo (and possibly pdfcairo?) which are historically related to paper output. I guess some LCD display devices have a portrait mode as well (where the whole LCD is twisted by 90 degrees to make it tall and skinny). > > When you create a plot in portrait mode with the ps driver the x and y pages > sizes are not interchanged so the plot comes out looking a little strange, > i.e. somewhat tall and narrow. Is this the "Right Thing To Do"? Yes, that is the whole point. The usual postscript landscape mode that PLplot produces is good for plots which need more space in the X direction, and all our examples are designed with that constraint in mind. But suppose you reorganize example 1 (say) so that the four subplots are stacked in a vertical column so you need more Y space than X space. (For my research plot that needs portrait mode, my subplots on the page are stacked in just such a vertical column.) Then portrait mode (by definition tall and narrow) gives best results for that tall and narrow case. But I do agree that our landscape examples do look badly proportioned (just as expected) in portrait mode. > Or should > portrait mode simply be a 90 degree rotation of the plot? That is part of it as you can see from ps.c, but you also need to set pls->freeaspect = 1; which acts the same as if the user had specified -freeaspect on the command line. I suggest you get the -ori option working first (so plotted results rotate properly). Once -ori 0, -ori 1, -ori 2, etc., work, then for fun try -ori 0.3 (i.e., non-integer -ori values). You will find a long-standing PLplot bug for that case which doesn't give correct plotted results (the rectangular viewport gets sheared into a parallogram) for non-integer -ori values if the aspect ratio is different from unity. Since the problem disappears for a unity aspect ratio, I think the x length is being taken rather then the appropriate y length or vice versa somewhere deep in the rotation code. But nobody has ever been able to track down the incorrect logic (which is, of course, a very low priority since integer -ori values are the ones that tend to be used). Once -ori works for integer values, then you should confirm that the -a option works as well. In other words, your device should give correct results for different aspect ratios passed to the device from the core PLplot library. After that confirmation, portrait mode should be a snap since pls->freeaspect = 1 tells the PLplot core library to adjust the aspect ratio appropriately (i.e., tall and skinny) for portrait mode. I hope I have clarified things for you. 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-16 03:54:00
|
On Aug 15, 2007, at 11:16 PM, Alan W. Irwin wrote: > On 2007-08-15 21:41-0400 Hazen Babcock wrote: > >> Or should portrait mode simply be a 90 degree rotation of the plot? > > That is part of it as you can see from ps.c, but you also need to > set pls->freeaspect = 1; which acts the same as if the user had > specified > -freeaspect on the command line. > > I suggest you get the -ori option working first (so plotted results > rotate > properly). > > Once -ori 0, -ori 1, -ori 2, etc., work, then for fun try -ori 0.3 > (i.e., > non-integer -ori values). You will find a long-standing PLplot bug > for that > case which doesn't give correct plotted results (the rectangular > viewport > gets sheared into a parallogram) for non-integer -ori values if the > aspect > ratio is different from unity. Since the problem disappears for a > unity > aspect ratio, I think the x length is being taken rather then the > appropriate y length or vice versa somewhere deep in the rotation > code. But > nobody has ever been able to track down the incorrect logic (which > is, of > course, a very low priority since integer -ori values are the ones > that tend > to be used). > > Once -ori works for integer values, then you should confirm that > the -a > option works as well. In other words, your device should give correct > results for different aspect ratios passed to the device from the core > PLplot library. After that confirmation, portrait mode should be a > snap > since pls->freeaspect = 1 tells the PLplot core library to adjust > the aspect > ratio appropriately (i.e., tall and skinny) for portrait mode. > > I hope I have clarified things for you. Ok. My latest commit may have gotten this all sorted out. I'm a little puzzled why the PLplot library doesn't just pass the driver the right transform matrix for the new orientation since it is going to the effort of rotating everything else. -Hazen |
From: Maurice L. <mj...@br...> - 2007-08-21 03:46:05
|
(trying to catch up on email) Alan W. Irwin writes: > Once -ori 0, -ori 1, -ori 2, etc., work, then for fun try -ori 0.3 (i.e., > non-integer -ori values). You will find a long-standing PLplot bug for that > case which doesn't give correct plotted results (the rectangular viewport > gets sheared into a parallogram) for non-integer -ori values if the aspect > ratio is different from unity. Since the problem disappears for a unity > aspect ratio, I think the x length is being taken rather then the > appropriate y length or vice versa somewhere deep in the rotation code. But > nobody has ever been able to track down the incorrect logic (which is, of > course, a very low priority since integer -ori values are the ones that tend > to be used). Right. When I wrote the driver interface orientation code, I originally held orientation to integer values. But then I realized, why not have some fun and make it more general. The shear problem showed up right away, and having (over) filled my capacity for "fun" projects at the time :), I left it at that. -- Maurice LeBrun |
From: Alan W. I. <ir...@be...> - 2007-08-16 05:09:11
|
On 2007-08-15 23:24-0400 Hazen Babcock wrote: > > On Aug 8, 2007, at 5:27 PM, Alan W. Irwin wrote: > >> (4) Text clipping has not yet been implemented. (The first page of example >> 9 >> shows this issue.) > > I've committed a version that implements text clipping. I understand that it > isn't quite correct since it does not use difilt() to adjust the coordinates, > however it should work for example 9. That said, it makes plotting using > Cairo a lot slower on my linux box (10-100X?), so I'm wondering whether this > should be optional. For now with those sort of speeds, it sounds like this should be a driver option. But I sure don't understand why cairo takes so long to render clipped text, and I wonder if a question about that to the appropriate cairo-related list might give you a faster alternative for clipping text or they might find the efficiency bottleneck in their code for this case. 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-16 06:04:46
|
On 2007-08-15 23:51-0400 Hazen Babcock wrote: > > On Aug 15, 2007, at 11:16 PM, Alan W. Irwin wrote: >> Once -ori works for integer values, then you should confirm that the -a >> option works as well. In other words, your device should give correct >> results for different aspect ratios passed to the device from the core >> PLplot library. After that confirmation, portrait mode should be a snap >> since pls->freeaspect = 1 tells the PLplot core library to adjust the >> aspect >> ratio appropriately (i.e., tall and skinny) for portrait mode. >> >> I hope I have clarified things for you. > > Ok. My latest commit may have gotten this all sorted out. I'm a little > puzzled why the PLplot library doesn't just pass the driver the right > transform matrix for the new orientation since it is going to the effort of > rotating everything else. The aspect ratio of the letters and symbols is incorrect with -portrait mode. To see this look at example 1 where the circular symbols have been turned into ellipses. If you compare the results of ./x01c -a .75 -ori 1 -dev pscairo -o test2.ps and ./x01c -portrait -dev pscairo -o test3.ps they should be closely similar, but they are not. test2.ps is very similar to what you get with ./x01c -portrait -dev psc -o test1.ps or ./x01c -freeaspect -ori 1 -dev psc -o test0.ps (which produces an identical plot to test1.ps). In other words, it appears the -a and -ori options are working fine for pscairo, but -portrait is not for some reason. If you do the further command ./x01c -freeaspect -ori 1 -dev pscairo -o test4.ps you will find the result is correct (i.e., virtually identical to test2.ps above). Thus, pscairo is really close, and the issue simply boils down to why does -portrait not produce identical results to -freeaspect -ori 1 for the pscairo driver? I just now had a look at cairo.c, and the naive answer is you forgot to set pls->freeaspect = 1; in that driver for the -portrait case (at least for revision 7806 which is what "svn update" gives me for trunk at the moment). I tried setting that myself locally in the if(pls->portrait){ block, but it made no difference (which I frankly don't understand since that logic followed what works in the ps.c case.) Anyhow, with "-freeaspect -ori 1" giving correct results for pscairo, I hope it is easy for you to figure out what the problem is with the -portrait option for pscairo. 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-17 00:47:17
|
On Aug 16, 2007, at 2:04 AM, Alan W. Irwin wrote: >> Ok. My latest commit may have gotten this all sorted out. I'm a >> little puzzled why the PLplot library doesn't just pass the driver >> the right transform matrix for the new orientation since it is >> going to the effort of rotating everything else. > > The aspect ratio of the letters and symbols is incorrect with - > portrait mode. > To see this look at example 1 where the circular symbols have been > turned > into ellipses. > > If you compare the results of > > ./x01c -a .75 -ori 1 -dev pscairo -o test2.ps > > and > > ./x01c -portrait -dev pscairo -o test3.ps > > they should be closely similar, but they are not. test2.ps is very > similar > to what you get with > > ./x01c -portrait -dev psc -o test1.ps > > or > > ./x01c -freeaspect -ori 1 -dev psc -o test0.ps > > (which produces an identical plot to test1.ps). > > In other words, it appears the -a and -ori options are working fine > for > pscairo, but -portrait is not for some reason. If you do the further > command > > ./x01c -freeaspect -ori 1 -dev pscairo -o test4.ps > > you will find the result is correct (i.e., virtually identical to > test2.ps > above). Thus, pscairo is really close, and the issue simply boils > down to > why does -portrait not produce identical results to -freeaspect - > ori 1 for > the pscairo driver? I just now had a look at cairo.c, and the > naive answer > is you forgot to set pls->freeaspect = 1; in that driver for the - > portrait > case (at least for revision 7806 which is what "svn update" gives > me for > trunk at the moment). I tried setting that myself locally in the > if(pls->portrait){ block, but it made no difference (which I > frankly don't > understand since that logic followed what works in the ps.c case.) > > Anyhow, with "-freeaspect -ori 1" giving correct results for > pscairo, I hope > it is easy for you to figure out what the problem is with the - > portrait > option for pscairo. I tried to follow ps.c more closely. Does pscairo (i.e. version 7808 +) work correctly now? -Hazen |
From: Alan W. I. <ir...@be...> - 2007-08-17 01:05:17
|
On 2007-08-16 20:44-0400 Hazen Babcock wrote: > I tried to follow ps.c more closely. Does pscairo (i.e. version 7808+) work > correctly now (with -portrait mode)? Yes! Thanks, Hazen. 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-17 01:41:22
|
On 2007-08-08 14:27-0700 Alan W. Irwin wrote: Just to review the status here of Hazen's work on dealing with the various cairo issues I brought up... (1) The PostScript bounding box seems of adequate size now for all cases. It is somewhat bigger than what is needed for certain plots, but in the interests of uniform plots for all cairo-related devices, Hazen has decided to leave it as is, and I agree with this resolution of the issue. (2) stdout issue has been fixed. (3) There are 3D plot labelling problems. For example, if you look at example 8, the y-axis labels and the left-hand z-axis labels are oriented properly but their size is too large. The x-axis labels and the right-hand z-axis labels are fine. To verify this bug try the combination of alt=20, az=10. The wrong size for the labels knocks your eye out. The equivalent test for -dev psc gives reasonable looking results. (4) Text clipping. Hazen's fix ended up costing huge amounts of computer time (10x - 100x) for his software stack so he commented it out. I would like to verify the computer time problem for my own software stack so I suggest this fix should be implemented as a driver option. My software stack is the latest/greatest cairo and pango. From the release notes there have been a number of efficiency improvements in the latest releases so I may find that pscairo does fast text clipping for my software stack. Or it may not.... (5) The -portrait flag (and -ori, -a, and -freeaspect flags) now work for pscairo. (6) Resolution issue fixed. In sum, (3) still requires programming work and (4) requires a small amount of programming work and further investigation of why the speeds are so slow when text clipping is enabled, but all other issues that I am aware of have been resolved thanks to Hazen's hard work maturing the 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-08-18 00:12:33
|
On Aug 16, 2007, at 9:41 PM, Alan W. Irwin wrote: > On 2007-08-08 14:27-0700 Alan W. Irwin wrote: > > (4) Text clipping. Hazen's fix ended up costing huge amounts of > computer > time (10x - 100x) for his software stack so he commented it out. I > would > like to verify the computer time problem for my own software stack > so I > suggest this fix should be implemented as a driver option. My > software > stack is the latest/greatest cairo and pango. From the release > notes there > have been a number of efficiency improvements in the latest > releases so I > may find that pscairo does fast text clipping for my software > stack. Or it > may not.... Revision 7812 contains a text clipping option for the cairo drivers, called text_clipping. Off, the default, is text_clipping=0, On is text_clipping=1. I was measuring the time by looking at how long it took xcairo to render a complicated plot like example 9 page 1. It behaves a little unexpectedly in that you get the message "Key <Return> to finish" and a blank window almost immediately. Then if you wait a few (10s?) of seconds the plot is finally rendered. -Hazen |
From: Hazen B. <hba...@ma...> - 2007-08-18 18:14:21
|
On Aug 16, 2007, at 9:41 PM, Alan W. Irwin wrote: > On 2007-08-08 14:27-0700 Alan W. Irwin wrote: > > Just to review the status here of Hazen's work on dealing with the > various > cairo issues I brought up... > > (3) There are 3D plot labelling problems. For example, if you > look at example 8, the y-axis labels and the left-hand z-axis > labels are > oriented properly but their size is too large. The x-axis labels > and the > right-hand z-axis labels are fine. To verify this bug try the > combination > of alt=20, az=10. The wrong size for the labels knocks your eye out. > The equivalent test for -dev psc gives reasonable looking results. This one is really puzzling to me. I'm doing what I thought was correct, i.e. the text transform matrix is the product of a rotation (r) and shear (s) matrix. [xf] = [ c(r) s(r)][1 t(s)][xo] [yf] [-s(r) c(r)][0 1][yo] This does not change the height of the characters as measured perpendicular to the text baseline. I also tried using a transform that would preserve the height as measured parallel to the vertical axis of the characters after shearing, but that definitely looks wrong. -Hazen |
From: Alan W. I. <ir...@be...> - 2007-08-18 01:51:36
|
On 2007-08-17 20:10-0400 Hazen Babcock wrote: > > On Aug 16, 2007, at 9:41 PM, Alan W. Irwin wrote: > >> On 2007-08-08 14:27-0700 Alan W. Irwin wrote: >> >> (4) Text clipping. Hazen's fix ended up costing huge amounts of computer >> time (10x - 100x) for his software stack so he commented it out. I would >> like to verify the computer time problem for my own software stack so I >> suggest this fix should be implemented as a driver option. My software >> stack is the latest/greatest cairo and pango. From the release notes >> there >> have been a number of efficiency improvements in the latest releases so I >> may find that pscairo does fast text clipping for my software stack. Or >> it >> may not.... > > Revision 7812 contains a text clipping option for the cairo drivers, called > text_clipping. Off, the default, is text_clipping=0, On is text_clipping=1. I > was measuring the time by looking at how long it took xcairo to render a > complicated plot like example 9 page 1. It behaves a little unexpectedly in > that you get the message "Key <Return> to finish" and a blank window almost > immediately. Then if you wait a few (10s?) of seconds the plot is finally > rendered. For Revision 7812 built for the latest pango/cairo stacks, clipping slows down pscairo by a factor of 4.3. software@chickadee> time ./x09c -dev pscairo -o test.ps real 0m0.491s user 0m0.435s sys 0m0.029s software@chickadee> time ./x09c -dev pscairo -o test.ps -drvopt text_clipping=1 real 0m2.120s user 0m1.889s sys 0m0.196s The factor of 4.3 does seem to be excessive for the relatively small (at least compared to a normal printed page) amount of text we have for example 9. So this inefficiency may be worth reporting to the cairo developers to see if they would like to address the issue. (I imagine text clipping is not used very often for normal printed results so they may not have worried about this inefficiency up to now.) Considering the current inefficiency of text clipping for the cairo library, I think the way you have dealt with this issue is the best compromise. So that only leaves the 3D labelling issue (issue 3) to be dealt with to achieve what I consider to be maturity for this driver. At that point I would recommend building the cairo devices by default and putting a pscairo test stanza into ctest. 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-18 19:56:34
|
On 2007-08-18 14:12-0400 Hazen Babcock wrote: > > On Aug 16, 2007, at 9:41 PM, Alan W. Irwin wrote: > >> On 2007-08-08 14:27-0700 Alan W. Irwin wrote: >> >> Just to review the status here of Hazen's work on dealing with the various >> cairo issues I brought up... >> >> (3) There are 3D plot labelling problems. For example, if you >> look at example 8, the y-axis labels and the left-hand z-axis labels are >> oriented properly but their size is too large. The x-axis labels and the >> right-hand z-axis labels are fine. To verify this bug try the combination >> of alt=20, az=10. The wrong size for the labels knocks your eye out. >> The equivalent test for -dev psc gives reasonable looking results. > > This one is really puzzling to me. I'm doing what I thought was correct, i.e. > the text transform matrix is the product of a rotation (r) and shear (s) > matrix. > > [xf] = [ c(r) s(r)][1 t(s)][xo] > [yf] [-s(r) c(r)][0 1][yo] I am not that familiar with shear transformations, but I tried to follow what you did using the Wikipedia articles http://en.wikipedia.org/wiki/Rotation_(mathematics) and http://en.wikipedia.org/wiki/Shear_(mathematics). They appear to be reasonably consistent with your equation above. Multiplying out the matrices gives the transformation matrix xf c(r) c(r)*t(s) + s(r) xo = * yf -s(r) -s(r)*t(s) + c(r) yo and this appears (see http://cairographics.org/manual/cairo-cairo-matrix-t.html) to be what you implemented by the following code in cairo.c: cairo_matrix_init(cairoTransformMatrix, cos_rot, -sin_rot, cos_rot * tan_shear + sin_rot, -sin_rot * tan_shear + cos_rot, 0,0); I would double-check your definition of the rotation angle to make sure the rotation matrix should not be replaced by its transpose and similarly for the shear matrix. But such considerations should affect only the amount of rotation and shear applied (which are correct), and should not affect the size of the character (which is the issue here). What decides the size of the sheared and rotated character that is rendered by cairo? I think it is that cairo (and equivalent ps.c) logic that you should review. There may be some character scaling done by the PLplot core that has to be compensated by each device for the rotated and sheared characters appearing in 3D 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: Alan W. I. <ir...@be...> - 2007-09-03 03:05:05
|
Hazen seems reluctant to praise his cairo device driver so I will do it for him. :-) All issues I recently identified with the pscairo device have now been fixed by Hazen, and in addition he has added driver options to allow control of antialiasing for either/both text and graphics using the 4 levels of antialiasing hints allowed by libcairo. I have recently been using pngcairo and pscairo in my research work, and I think they have now reached the stage where they are our premier PostScript and PNG devices. Furthermore, xcairo gives (IMO) the best-looking immediate display of PLplot results (although Hazen has planned a lot more work for this device to give it interactive capability). I urge you to try these devices to see if you agree with my assessment about how good-looking the results are. pdfcairo seems to work reasonably well, but it appears not to be as mature as the three other Cairo devices mentioned above. For example, the background colour does not appear for the xpdf viewer (although it does appear for the gv viewer and the ImageMagick display command), and antialiasing does not appear to work for any viewer. All these pdfcairo issues may be libcairo issues. I don't know even how to try to use memcairo, but according to the release notes it does not work. I have just verified svgcairo does not render text (as also mentioned in the release notes). Therefore, I have kept these two cairo devices disabled by default. However, I have recently enabled the remaining cairo devices (pdfcairo, pngcairo, pscairo, and xcairo) by default. 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-09-03 15:43:07
|
On Sep 2, 2007, at 11:04 PM, Alan W. Irwin wrote: > Hazen seems reluctant to praise his cairo device driver so I will > do it for > him. :-) > > All issues I recently identified with the pscairo device have now > been fixed > by Hazen, and in addition he has added driver options to allow > control of > antialiasing for either/both text and graphics using the 4 levels of > antialiasing hints allowed by libcairo. I have recently been using > pngcairo > and pscairo in my research work, and I think they have now reached > the stage > where they are our premier PostScript and PNG devices. > Furthermore, xcairo > gives (IMO) the best-looking immediate display of PLplot results > (although > Hazen has planned a lot more work for this device to give it > interactive > capability). Er, well, I actually didn't have any real plans for further xcairo interactivity. Suggestions however are welcome. -Hazen |
From: Alan W. I. <ir...@be...> - 2007-09-03 17:55:08
|
On 2007-09-03 11:33-0400 Hazen Babcock wrote: > Er, well, I actually didn't have any real plans for further xcairo > interactivity. Suggestions however are welcome. I was referring to the extensive thread we had before about this subject where I believe you concluded that the ability (shown in example 1 if you use the -locate option) of -dev xwin and -dev tk to deliver back the key that was struck as well as the world coordinates of the cursor when that key was struck should be implemented for -dev xcairo when you had a chance. So long as a device has at least this interactive capability then PLplot application developers could write their own command line interface using such devices. For example, there was a very nice CLI I used in the early 90's for analyzing stellar spectra, and I think I still have access to the source code for that. I recall there were something like 30 different commands you could run based on what key was struck and the position of the key at the time of the key strike. You could fit the continuum (based on the points you clicked on), calculate equivalent widths of absorption or emission lines, calculate line positions, calculate the dispersion relation, etc., etc. I am tied up with a different research topic at the moment, but at some point I hope to revive that CLI using -dev xwin (and eventually -dev xcairo when you have implemented the interactive capability referred to above) as the back end. Beyond that fundamental interactive capability, there are all sorts of things you could do to follow what is possible for the -dev tk GUI. (Use that device and click on the Plot button to see what is possible in terms of zooming, scrolling, and colour palettes.) However, turning xcairo into a full-blown GUI is a lot of work and may not be the direction you want to take. Personally, I would be satisfied with just the limited interactive capability that -dev xwin currently has (as compared to the extensive interactive capability of -dev tk) since that limited capability is sufficient to support CLI's. 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-09-07 04:00:18
|
On Sep 3, 2007, at 1:55 PM, Alan W. Irwin wrote: > On 2007-09-03 11:33-0400 Hazen Babcock wrote: > >> Er, well, I actually didn't have any real plans for further xcairo >> interactivity. Suggestions however are welcome. > > I was referring to the extensive thread we had before about this > subject > where I believe you concluded that the ability (shown in example 1 > if you > use the -locate option) of -dev xwin and -dev tk to deliver back > the key > that was struck as well as the world coordinates of the cursor when > that key > was struck should be implemented for -dev xcairo when you had a > chance. As a first step, I've added a simple event loop to xcairo. Among other things it should now handle expose/redraw events properly, so if you move or resize the screen the plot should no longer disappear. Since this works by redrawing the plot from scratch each time and since a simple resizing of the screen can generate a surprising number of expose events this might be a little slow. The advance to next page / quit has also been changed, like the xwin driver you now need to select the plotting window and press return. -Hazen |
From: Alan W. I. <ir...@be...> - 2007-09-07 18:06:54
|
On 2007-09-06 23:57-0400 Hazen Babcock wrote: > As a first step, I've added a simple event loop to xcairo. Among other things > it should now handle expose/redraw events properly, so if you move or resize > the screen the plot should no longer disappear. Since this works by redrawing > the plot from scratch each time and since a simple resizing of the screen can > generate a surprising number of expose events this might be a little slow. > The advance to next page / quit has also been changed, like the xwin driver > you now need to select the plotting window and press return. A necessary (at least on Linux) #include was missing in what you committed, but I have fixed that now. When I hit return for a multi-page plot all pages get dumped in sequence to the screen. So this is a start, but you might want to emulate xwin a bit more closely and implement a pause for each page until return is hit again. 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-09-07 23:10:49
|
On Sep 7, 2007, at 2:06 PM, Alan W. Irwin wrote: > On 2007-09-06 23:57-0400 Hazen Babcock wrote: > >> As a first step, I've added a simple event loop to xcairo. Among >> other things >> it should now handle expose/redraw events properly, so if you move >> or resize >> the screen the plot should no longer disappear. Since this works >> by redrawing >> the plot from scratch each time and since a simple resizing of the >> screen can >> generate a surprising number of expose events this might be a >> little slow. >> The advance to next page / quit has also been changed, like the >> xwin driver >> you now need to select the plotting window and press return. > > A necessary (at least on Linux) #include was missing in what you > committed, > but I have fixed that now. When I hit return for a multi-page plot > all pages > get dumped in sequence to the screen. So this is a start, but you > might want > to emulate xwin a bit more closely and implement a pause for each > page until > return is hit again. Thanks. This was another simple mistake on my part. Xcairo should now (v7845) wait between plots until the return key is pressed again. -Hazen |