From: Alan W. I. <ir...@be...> - 2007-09-11 22:43:19
Attachments:
snapshot16.png
|
Hi Hazen: First I describe the tests I have made of plptex3 (see attached screenshot), then have a question for you at the end about a possible bug in this routine. I have just (Revision 7861) updated examples/c/x28c.c to do fairly extensive testing of the plmtex3 and plptex3 API programmed by you in March. As far as I can tell plmtex3 works fine. However, I am getting rather strange looking results for the shear testing of plptex3. I just don't get results that make sense (see the attached screenshot) according to the documentation which implies that the vertical axis of characters will be parallel to the (sx, sy, sz) vector. All this shear testing is for strings that are written in a direction parallel to the x axis with sy changing monotonically and either sx = 0.2 and sz = 0.0 or sx = 0. and sz = 0.2. (1) For the non-zero sx case (strings ending in "(a)") the described (sx, sy, sz) vectors are all in the XY plane (sz = 0.) so you would expect all the characters to be flat in that plane and rotate in that plane monotonically as sy was changed. Instead, the characters are upright and seem to rotate around an axis parallel with the X axis in a non-monotonic way! (For example, the rotations of "eight(a)" and "nine(a)" are either the same or maybe even in the wrong order.) (2) For the non-zero sz case (strings ending in "(b)") the described (sx, sy, sz) vectors are all in the YZ plane (sx = 0.) so you would expect the characters to rotate around an axis parallel with the X axis in a monotonic way. Instead, the characters are all rotated identically regardless of the sy value! I have also tried no shear ((sx, sy, sz) = (0., 0., 0.)) but that gives characters roughly rotated by 45 deg around the axis of the string rather than characters (for this example with the string oriented parallel to the X axis) whose vertical axis is parallel with the Z axis. Hazen, could you please compare the attached screenshot with results for x28c you get on your own platform? If you confirm these strange results do you think this is due to a bug? If so, the fix may be similar to the last shear fixup you did with the cairo device. 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-12 04:31:52
|
On Sep 11, 2007, at 6:42 PM, Alan W. Irwin wrote: > Hi Hazen: > > Hazen, could you please compare the attached screenshot with > results for > x28c you get on your own platform? If you confirm these strange > results do > you think this is due to a bug? If so, the fix may be similar to > the last > shear fixup you did with the cairo device. Yes, these strange results are due to a bug. I hope to be able to fix it in the next few days. -Hazen |
From: Hazen B. <hba...@ma...> - 2007-09-13 01:35:02
|
On Sep 12, 2007, at 12:29 AM, Hazen Babcock wrote: > > On Sep 11, 2007, at 6:42 PM, Alan W. Irwin wrote: > >> Hi Hazen: >> >> Hazen, could you please compare the attached screenshot with >> results for >> x28c you get on your own platform? If you confirm these strange >> results do >> you think this is due to a bug? If so, the fix may be similar to >> the last >> shear fixup you did with the cairo device. > > Yes, these strange results are due to a bug. I hope to be able to fix > it in the next few days. I think this should work now (v7863). However, the first test case in example 28, "seven(a)", is perhaps a bit too much of test. It asks for text that is drawn parallel to the x axis and also that the text itself is parallel to the x axis, this means that its shear angle is 90. The aqt driver just ignores such a large shear angle. The xcairo driver crashes, at least with my OS-X cairo stack. -Hazen |
From: Alan W. I. <ir...@be...> - 2007-09-13 17:03:24
|
On 2007-09-12 21:32-0400 Hazen Babcock wrote: > > On Sep 12, 2007, at 12:29 AM, Hazen Babcock wrote: > >> >> On Sep 11, 2007, at 6:42 PM, Alan W. Irwin wrote: >> >>> Hi Hazen: >>> >>> Hazen, could you please compare the attached screenshot with >>> results for >>> x28c you get on your own platform? If you confirm these strange >>> results do >>> you think this is due to a bug? If so, the fix may be similar to >>> the last >>> shear fixup you did with the cairo device. >> >> Yes, these strange results are due to a bug. I hope to be able to fix >> it in the next few days. > > I think this should work now (v7863). However, the first test case in > example 28, "seven(a)", is perhaps a bit too much of test. It asks > for text that is drawn parallel to the x axis and also that the text > itself is parallel to the x axis, this means that its shear angle is > 90. The aqt driver just ignores such a large shear angle. The xcairo > driver crashes, at least with my OS-X cairo stack. I think those bad results indicate there is at least one bug remaining. This is confirmed by results for your changed example (revision 7864) where although you avoid that extreme case, there are still problems with the results. The "b" series and "seven(a)" look fine, but the rest of the "a" series does not look the way it should. The "b" series has the s vector in the YZ plane with constant Z component. That is sx = 0., sz = 0.2, with varying sy starting at 0. So you start out the present "b" series with the vertical axis of the characters alligned with the Z axis with the rest of the series gradually introducing more and more Y component until at the end of the series ("eleven(b)') the vertical axis of the characters is almost aligned perfectly with the pure Y direction. The present "a" series has the s vector in the XY plane with constant Y component. That is sy = 0.2, sz = 0. with increasingly negative sx values starting at sx = 0. Thus, the vertical axis of each character in the "a" series should be parallel to the XY plane with the first one ("seven(a)") aligned with the pure Y direction. That is exactly what is displayed for "seven(a)", but for the remaining examples in the "a" series the vertical axes of the characters are not parallel with the XY plane. The problem is even more obvious if you change the example so that the various sx values are positive rather than negative; all the results do lie parallel with the XY plane, but the varying sx values are completely ignored so all the "a" series has the vertical axis of their characters parallel to the pure Y position with no X component. In sum, the present example 28c or a modified form of it with all the negative sx values turned positive for the "a" series shows there is at least one remaining bug to be fixed in plptex3. 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-14 00:21:03
|
On Sep 13, 2007, at 1:03 PM, Alan W. Irwin wrote: > On 2007-09-12 21:32-0400 Hazen Babcock wrote: > >> >> On Sep 12, 2007, at 12:29 AM, Hazen Babcock wrote: >> >> I think this should work now (v7863). However, the first test case in >> example 28, "seven(a)", is perhaps a bit too much of test. It asks >> for text that is drawn parallel to the x axis and also that the text >> itself is parallel to the x axis, this means that its shear angle is >> 90. The aqt driver just ignores such a large shear angle. The xcairo >> driver crashes, at least with my OS-X cairo stack. > > The present "a" series has the s vector in the XY plane with > constant Y > component. That is sy = 0.2, sz = 0. with increasingly negative sx > values > starting at sx = 0. Thus, the vertical axis of each character in > the "a" > series should be parallel to the XY plane with the first one ("seven > (a)") > aligned with the pure Y direction. That is exactly what is > displayed for > "seven(a)", but for the remaining examples in the "a" series the > vertical > axes of the characters are not parallel with the XY plane. The > problem is > even more obvious if you change the example so that the various sx > values > are positive rather than negative; all the results do lie parallel > with the > XY plane, but the varying sx values are completely ignored so all > the "a" > series has the vertical axis of their characters parallel to the > pure Y > position with no X component. Are you saying that all of the "a" series with sx >= 0.0 look the same? I don't see that. Also I think it is pretty hard to tell from a 2D plot whether or not text lies in a particular plane, so it also is not obvious to me that the sx <= 0.0 examples are in fact incorrect. I drew the lines on the plot that the "a" series text (positive or negative) was supposed to be parallel to and it looked like the text was indeed parallel. -Hazen |
From: Alan W. I. <ir...@be...> - 2007-09-14 02:14:23
Attachments:
snapshot17.png
snapshot18.png
|
Hi Hazen: I have just committed sx>= 0. change (Revision 7867) to the example since that seems to be a critical test case. On 2007-09-13 20:18-0400 Hazen Babcock wrote: > Are you saying that all of the "a" series with sx >= 0.0 look the same? Yes. -dev psc (with and without -drvopt text=0) and -dev psttfc show no change with Revision 7867. See screenshot 1. I also confirmed this result with the xwin, tk, svg, png (and the rest of the gd family), wxwidgets, gcw, pbm, and xfig devices. (It's been a long time since I have run some of those.) Now for the bad news (and the reason I did so much testing of all accessible devices). The cairo devices I looked at and also -dev pdf (written by Werner) produce a different result (sigh). (See screenshot 2.) Is -dev aqt (which I don't have access to) in this second group or the first? Now I would argue that the screenshot 2 results look like a rotation around the axis of the string in the sense opposite to the "b" series, but not the expected rotation of the vertical axis of the characters in a plane parallel to the XY plane. So I still think screenshot 2 is an incorrect result, but we can argue that one later after the screenshot 1 results are sorted out. Also notice, there is a slight problem with the "four" label in screenshot 1 that is produced by plmtex3. It looks slightly rotated around the axis of the string compared to the numerical labels for the same axis. The "four" label in screenshot 2 does not have this problem. I don't know whether this is an additional issue or part of the same mess. I think the emphasis for now should be on debugging why the first large set of all traditional PLplot devices and some PLplot non-traditional devices is interpreting the PLplot core drawing commands as if there were a constant sx component when that component in fact is changing for the sx>=0 case. Once that bug is solved, the problem with the cairo devices and pdf device (and possibly the aqt device) might disappear or become a lot clearer. BTW, although many of the devices I mentioned may be difficult for you to build on Mac OS X, you should have access to "screenshot 1" results with device psc (with text=0 or 1). Solve the series "a" issue and the four" issue for that one, and you probably have all the other "screenshot 1" devices solved as well. If you produce anything other than screenshot 1 or 2 on any of the devices accessible to you on your Mac OS X and Linux platforms, I would be interested in seeing the screenshot. 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-14 04:51:31
|
On Sep 13, 2007, at 10:13 PM, Alan W. Irwin wrote: > Hi Hazen: > > I have just committed sx>= 0. change (Revision 7867) to the example > since > that seems to be a critical test case. Indeed. > On 2007-09-13 20:18-0400 Hazen Babcock wrote: > >> Are you saying that all of the "a" series with sx >= 0.0 look the >> same? > > Yes. -dev psc (with and without -drvopt text=0) and -dev psttfc > show no > change with Revision 7867. See screenshot 1. I also confirmed this > result > with the xwin, tk, svg, png (and the rest of the gd family), > wxwidgets, gcw, > pbm, and xfig devices. (It's been a long time since I have run some of > those.) Fun. The svg and cairo (and aqt) drivers all use the plRotationShear function that I added to PLplot core. It is nice that the svg driver interprets the same angles in a very different way, clearly it has a bug in its text shearing. > Now for the bad news (and the reason I did so much testing of all > accessible > devices). The cairo devices I looked at and also -dev pdf (written by > Werner) produce a different result (sigh). (See screenshot 2.) Is - > dev aqt > (which I don't have access to) in this second group or the first? aqt is in the second group. > Now I would argue that the screenshot 2 results look like a > rotation around > the axis of the string in the sense opposite to the "b" series, but > not the > expected rotation of the vertical axis of the characters in a plane > parallel > to the XY plane. So I still think screenshot 2 is an incorrect > result, but > we can argue that one later after the screenshot 1 results are > sorted out. There isn't much to argue about here, draw the appropriate lines on the plot and tell me whether you think the text is parallel to these lines or not. > Also notice, there is a slight problem with the "four" label in > screenshot 1 that is produced by plmtex3. It looks slightly > rotated around > the axis of the string compared to the numerical labels for the > same axis. > The "four" label in screenshot 2 does not have this problem. I > don't know > whether this is an additional issue or part of the same mess. A mess indeed... > I think the emphasis for now should be on debugging why the first > large set > of all traditional PLplot devices and some PLplot non-traditional > devices is > interpreting the PLplot core drawing commands as if there were a > constant sx > component when that component in fact is changing for the sx>=0 > case. Once > that bug is solved, the problem with the cairo devices and pdf > device (and > possibly the aqt device) might disappear or become a lot clearer. It looks to me like the drivers in the first large set are assuming that the transform matrix will only contain values consistent with the text being either (1) rotated but sheared to vertical as in the x- y axises of a 3D plot, or (2) vertically oriented and sheared as in the z axis of a 3D plot. Fixing this issue will involve updating all the drivers in the first large set and also PLplot core as xwin, for example, does not render its own text. This could be a pretty major undertaking. -Hazen |
From: Alan W. I. <ir...@be...> - 2007-09-14 07:10:11
|
On 2007-09-14 00:48-0400 Hazen Babcock wrote: > On Sep 13, 2007, at 10:13 PM, Alan W. Irwin wrote: >> Now I would argue that the screenshot 2 results look like a rotation >> around >> the axis of the string in the sense opposite to the "b" series, but not >> the >> expected rotation of the vertical axis of the characters in a plane >> parallel >> to the XY plane. So I still think screenshot 2 is an incorrect result, >> but >> we can argue that one later after the screenshot 1 results are sorted out. > > There isn't much to argue about here, draw the appropriate lines on the plot > and tell me whether you think the text is parallel to these lines or not. Sorry about the noise. Devices that give Screenshot 2 are giving the correct results. I figured this out with another method; I viewed pscairo results at alt=5, az = 355 which showed I was misinterpreting the results before as a rotation rather than a skew that indeed keeps the "a" series letters confined to a plane parallel to the XY axis. The "b" series is the expected rotation around the axis of the string. As far as I can tell now, all is right with screenshot 2 and the cairo and aqt worlds. It is nice to know we have at least one foot on dry land... :-) (Also note my previous tests of "-dev pdf" silently got switched to -dev pdfcairo because I had not built Werner's pdf device driver. So probably that device produces screenshot 1, but I don't know that for a fact.) > >> Also notice, there is a slight problem with the "four" label in >> screenshot 1 that is produced by plmtex3. It looks slightly rotated >> around >> the axis of the string compared to the numerical labels for the same axis. >> The "four" label in screenshot 2 does not have this problem. I don't know >> whether this is an additional issue or part of the same mess. > > A mess indeed... > > It looks to me like the drivers in the first large set are assuming that the > transform matrix will only contain values consistent with the text being > either (1) rotated but sheared to vertical as in the x-y axises of a 3D plot, > or (2) vertically oriented and sheared as in the z axis of a 3D plot. Fixing > this issue will involve updating all the drivers in the first large set and > also PLplot core as xwin, for example, does not render its own text. This > could be a pretty major undertaking. The device list that needs fixing is the following: psc, psttfc, svg, png (and the rest of the gd family), wxwidgets (and probably pdf), gcw, xwin, tk, pbm, and xfig. Could somebody check wingcc as well? The three devices after xwin are like xwin and do not render their own text. They simply let the PLplot core send drawing commands using the Hershey fonts. This is also true (just checked) for all the devices before xwin when the -drvopt text=0 option is used. So the fixes can be separated into a fix for the rendering of the core Hershey fonts (which should correct text=0 results for the seven drivers that have that driver option and also correct xwin, tk, pbm, and xfig) and individual fixes for the seven device drivers listed above with the text=1 driver option. So the work naturally divides itself into relatively small individual tasks. Thanks, Hazen, for leading the way and providing examples of rendering 3D strings correctly with the cairo and aqt 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: Alan W. I. <ir...@be...> - 2007-09-14 16:32:36
|
On 2007-09-14 00:10-0700 Alan W. Irwin wrote: > So the fixes can be separated into a fix for the rendering of the core > Hershey fonts (which should correct text=0 results for the seven drivers > that have that driver option and also correct xwin, tk, pbm, and xfig) and > individual fixes for the seven device drivers listed above with the text=1 > driver option. So the work naturally divides itself into relatively small > individual tasks. > > Thanks, Hazen, for leading the way and providing examples of rendering 3D > strings correctly with the cairo and aqt devices. Having slept on this, I have a few more points this morning. * As always, I would be happy to do testing of the above fixes (especially the Hershey one where I have a fully loaded system that can test most Hershey-only devices and the many devices that have the Hershey text=0 option). Also, my coding time is limited due to my current research effort, and my understanding of device drivers is limited as well, but if somebody shows the way for what changes to make in the text=1 case for one device driver, I probably have enough driver skills to help out by propagating those change to one or more of the other text=1 devices. * If the above issues are not mostly sorted out by 5.8.0-RC1, we should mark both plmtex3 and plptex3 experimental (in the release notes and documentation). * We should not propagate x28c.c (yet) to other front-end languages. I want to leave it as is until all the device issues get sorted, but then after that I will probably want to change it all out of recognition to add a lot more 3D text possibilities. 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-17 04:20:03
|
On Sep 14, 2007, at 11:19 AM, Alan W. Irwin wrote: > Having slept on this, I have a few more points this morning. > > * As always, I would be happy to do testing of the above fixes > (especially > the Hershey one where I have a fully loaded system that can test most > Hershey-only devices and the many devices that have the Hershey text=0 > option). Also, my coding time is limited due to my current > research effort, > and my understanding of device drivers is limited as well, but if > somebody > shows the way for what changes to make in the text=1 case for one > device > driver, I probably have enough driver skills to help out by > propagating > those change to one or more of the other text=1 devices. > > * If the above issues are not mostly sorted out by 5.8.0-RC1, we > should mark > both plmtex3 and plptex3 experimental (in the release notes and > documentation). > > * We should not propagate x28c.c (yet) to other front-end > languages. I want > to leave it as is until all the device issues get sorted, but then > after > that I will probably want to change it all out of recognition to > add a lot > more 3D text possibilities. Now it is my turn to apologize for all the noise. As you originally suspected, I was not calculating the transformation matrix correctly in plptex3 and in plmtex3. This should be fixed now in v7869 and was tested with the xwin and xcairo drivers. -Hazen |
From: Alan W. I. <ir...@be...> - 2007-09-17 07:11:28
|
On 2007-09-17 00:17-0400 Hazen Babcock wrote: > Now it is my turn to apologize for all the noise. As you originally > suspected, I was not calculating the transformation matrix correctly in > plptex3 and in plmtex3. This should be fixed now in v7869 and was tested with > the xwin and xcairo drivers. Hi Hazen: Revision 7869 is much better. I was particularly gratified that your core fixes seemed to uniformly improve the results for all the non-cairo devices. With this revision I noticed there are still two issues for -dev psc and one issue (newly introduced?) for -dev pscairo. I prefer PostScript comparisons because the better fonts for -dev psc compared to -dev xwin make comparisons with -dev psc results much clearer. However, I confirmed the problems below also for -dev xwin (two issues like for -dev psc) and -dev xcairo (one issue like for -dev pscairo). (1) The size of the "a" series as the series progresses becomes much too large for -dev psc but looks reasonable for -dev pscairo. (This reminds me of the pscairo issue we used to have with size for the 3D numerical tick mark labels.) (2) The size of the "six" and "four" become too large as the azimuth approaches 90+270 (e.g., try it for 80+270) for -dev psc but not -dev pscairo. (Again, this reminds me of the pscairo issue we used to have with size for the 3D numerical tick mark labels.) (3) The angle of the numerical labels for the tick marks for the right-hand Z axis and the Y axis appear to be twisted from being parallel with the Z axis for -dev pscairo but not for -dev psc. This effect is small but probably most obvious for an azimuth of 80+270. I believe this effect used to be in -dev psc, but now due to your core changes it has been "moved" to -dev pscairo. I suspect this is due to some minor inconsistency in interpretation between core and the traditional devices that was removed by your last core change but also introduced to the cairo devices by that same core change. Let me know if you need screenshots of these three issues. 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-18 01:04:03
|
On Sep 17, 2007, at 3:09 AM, Alan W. Irwin wrote: > On 2007-09-17 00:17-0400 Hazen Babcock wrote: > >> Now it is my turn to apologize for all the noise. As you originally >> suspected, I was not calculating the transformation matrix >> correctly in >> plptex3 and in plmtex3. This should be fixed now in v7869 and was >> tested with >> the xwin and xcairo drivers. > > With this revision I noticed there are still two issues for -dev > psc and one > issue (newly introduced?) for -dev pscairo. > > (1) The size of the "a" series as the series progresses becomes > much too > large for -dev psc but looks reasonable for -dev pscairo. (This > reminds me > of the pscairo issue we used to have with size for the 3D numerical > tick > mark labels.) > > (2) The size of the "six" and "four" become too large as the azimuth > approaches 90+270 (e.g., try it for 80+270) for -dev psc but not - > dev pscairo. > (Again, this reminds me of the pscairo issue we used to have with > size for the > 3D numerical tick mark labels.) It was the same issue. I was using the shear matrix: [ 1 tan(phi) ] [ 0 1 ] You favor (and the other PLplot core functions use): [ 1 sin(phi) ] [ 0 cos(phi) ] Anyway, this should be fixed in v7870. > (3) The angle of the numerical labels for the tick marks for the > right-hand > Z axis and the Y axis appear to be twisted from being parallel with > the Z > axis for -dev pscairo but not for -dev psc. This effect is small but > probably most obvious for an azimuth of 80+270. I believe this > effect used > to be in -dev psc, but now due to your core changes it has been > "moved" to > -dev pscairo. I suspect this is due to some minor inconsistency in > interpretation between core and the traditional devices that was > removed by > your last core change but also introduced to the cairo devices by > that same > core change. Do you still see this? -Hazen |
From: Alan W. I. <ir...@be...> - 2007-09-18 19:45:13
|
Hi Hazen: Good news! As of revision 7874 (which includes my recent fix to the svg device driver interpretation of rotation and shear angles as well as all your recent plmtex3 and plptex3 fixes) all issues that I had found with plmtex3 and plptex3 with example 28 are now fixed for all the devices that I tested before. N.B. example 28 should not (yet) be propagated to additional languages because there are a lot of additional changes I would like to make. 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-19 02:38:22
Attachments:
snapshot110.png
snapshot111.png
|
On 2007-09-18 12:43-0700 Alan W. Irwin wrote: > Hi Hazen: > > Good news! > > As of revision 7874 (which includes my recent fix to the svg device driver > interpretation of rotation and shear angles as well as all your recent > plmtex3 and plptex3 fixes) all issues that I had found with plmtex3 and > plptex3 with example 28 are now fixed for all the devices that I tested > before. > > N.B. example 28 should not (yet) be propagated to additional languages because > there are a lot of additional changes I would like to make. Hi Hazen: I hoped we were done with plptex3, but we are not. The next round of changes (Revision 7875) in example 28 exposed two additional bugs which I will call the "rotation sign" bug and the "just = 0.5 sign" bug. There is also a character size issue shown by the "revolution" pattern (effective 3D character size depends on inclination and viewing angle) which I will discuss at the end. The first attached screenshot gives the gv result for ./x28c -dev pscairo -o test.ps If you look at the "rotation" series of 8 different shear angles in x28c.c, the shear vector is supposed to rotate through a total range in angle of 2 PI in a plane parallel to the YZ plane. The first four angles (0, PI/4, PI/2, 3PI/4) are fine, but the next four angles act as if PI had been subtracted from the rotation angle. I think this issue must be due to a sign bug in the way quadrant 3 and 4 (with shear angle from PI to 2PI) are handled. ./x28c -dev psc -o test.ps (note the default text=1) gives a virtually identical result (which is not attached) indicating this "rotation sign" bug must be in the PLplot core rather than in device interpretation of core results. The second attached screenshot gives the gv result for ./x28c -dev psc -o test.ps -drvopt text=0 i.e., for Hershey fonts. This shows the same "rotation sign" bug as above (this consistency is actually pretty gratifying since you have worked hard to make the extremely different Hershey font code path give consistent 3D inclination and shear results with the modern font code path). This screenshot also shows an additional "just=0.5" sign bug that displaces the "rotation" strings in the direction of increasing X. I can make the Hershey result agree with the modern font result if I specify just = -0.5 (!) for the plptex3 call so I assume this bug is due to some quadrant sign error in how just is interpreted for this particular inclination in the Hershey code path (but the first screenshot shows this bug does not occur in the modern font code path). Hazen, in principle, quadrant sign errors should be easy to fix so I tried to dig into the code to find the fix to the above two issues, but I soon got lost in the maze. Will you please give it a go when you have further time for PLplot? I presume these sign issues are active issues you want to clean up before 5.8.0-RC1. One final issue is the "revolution" pattern shown by both screen shots is in the form of a 3D ellipse (which projects to a 2D circle). It appears from this evidence that the overall 2D font size (both height and width of characters) appears not to be adjusted to account for the various inclinations as transformed to 2D via the 3D perspective plot transformation. As a result, the "revolution" pattern looks like a circle in 2D, but in 3D perspective you would interpret that 2D circle as an ellipse in 3D space (i.e., the effective 3D character size depends on inclination and viewing angle). Since plptex3 is supposed to be in (3D) world coordinates, I suspect it will be used by users to identify specific areas of 3D surfaces, and it will be an annoyance to have the effective 3D character size on that surface change with inclination and viewing angle. Hazen, it would be great if you could deal with this issue before the stable release, but if you prefer to put it off until post 5.8.0, that is fine as far as I am concerned. 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-19 04:06:59
|
On Sep 18, 2007, at 10:38 PM, Alan W. Irwin wrote: > On 2007-09-18 12:43-0700 Alan W. Irwin wrote: > > The next round of changes (Revision 7875) in example 28 exposed two > additional bugs which I will call the "rotation sign" bug and the > "just = > 0.5 sign" bug. There is also a character size issue shown by the > "revolution" pattern (effective 3D character size depends on > inclination and > viewing angle) which I will discuss at the end. > > The first attached screenshot gives the gv result for > > ./x28c -dev pscairo -o test.ps > > If you look at the "rotation" series of 8 different shear angles in > x28c.c, > the shear vector is supposed to rotate through a total range in > angle of 2 > PI in a plane parallel to the YZ plane. The first four angles (0, > PI/4, > PI/2, 3PI/4) are fine, but the next four angles act as if PI had been > subtracted from the rotation angle. I think this issue must be due > to a > sign bug in the way quadrant 3 and 4 (with shear angle from PI to > 2PI) are > handled. Er, not a bug, a feature... I did this deliberately because I did not think it made sense to be able to shear the text so that it was drawn "below" the baseline. Also, in the documentation we say that the text will be drawn parallel to the shear line, but don't mention anything about directionality. It isn't hard to change though if you think this approach is incorrect. > i.e., for Hershey fonts. This shows the same "rotation sign" bug > as above > (this consistency is actually pretty gratifying since you have > worked hard > to make the extremely different Hershey font code path give > consistent 3D > inclination and shear results with the modern font code path). This > screenshot also shows an additional "just=0.5" sign bug that > displaces the > "rotation" strings in the direction of increasing X. I can make > the Hershey > result agree with the modern font result if I specify just = -0.5 > (!) for > the plptex3 call so I assume this bug is due to some quadrant sign > error in > how just is interpreted for this particular inclination in the > Hershey code > path (but the first screenshot shows this bug does not occur in the > modern > font code path). I'll have a look, but plptex3 does not change the just parameter, it simply passes it through to the core PLplot text drawing routine plP_text. > One final issue is the "revolution" pattern shown by both screen > shots is in the form of a 3D ellipse (which projects to a 2D > circle). It appears > from this evidence that the overall 2D font size (both height and > width of > characters) appears not to be adjusted to account for the various > inclinations as transformed to 2D via the 3D perspective plot > transformation. As a result, the "revolution" pattern looks like a > circle > in 2D, but in 3D perspective you would interpret that 2D circle as an > ellipse in 3D space (i.e., the effective 3D character size depends on > inclination and viewing angle). Since plptex3 is supposed to be in > (3D) > world coordinates, I suspect it will be used by users to identify > specific > areas of 3D surfaces, and it will be an annoyance to have the > effective 3D > character size on that surface change with inclination and viewing > angle. > Hazen, it would be great if you could deal with this issue before > the stable > release, but if you prefer to put it off until post 5.8.0, that is > fine as > far as I am concerned. I'm not sure I understand. If the text is drawn in a plane then wouldn't you expect it's size to depend on the angle at which you viewed the plane? Perhaps we a need another text routine thats lets you specify the 3D location of the text, but then simply draws it in 2D (assuming this doesn't already exist)? -Hazen |
From: Alan W. I. <ir...@be...> - 2007-09-19 05:27:08
|
On 2007-09-19 00:04-0400 Hazen Babcock wrote: > Er, not a bug, a feature... I did this deliberately because I did not think > it made sense to be able to shear the text so that it was drawn "below" the > baseline. Also, in the documentation we say that the text will be drawn > parallel to the shear line, but don't mention anything about directionality. > It isn't hard to change though if you think this approach is incorrect. Yes, please. >> [...]I can make the >> Hershey >> result agree with the modern font result if I specify just = -0.5 (!) for >> the plptex3 call so I assume this bug is due to some quadrant sign error >> in >> how just is interpreted for this particular inclination in the Hershey >> code >> path (but the first screenshot shows this bug does not occur in the modern >> font code path). > > I'll have a look, but plptex3 does not change the just parameter, it simply > passes it through to the core PLplot text drawing routine plP_text. Thanks. I assume the Hershey code path is making some incorrect assumption about the X, Y, Z inclination of the text that is being justified while the modern font code path handles the issue correctly. > >> One final issue is the "revolution" pattern shown by both screen shots is >> in the form of a 3D ellipse (which projects to a 2D circle). It appears >> from this evidence that the overall 2D font size (both height and width of >> characters) appears not to be adjusted to account for the various >> inclinations as transformed to 2D via the 3D perspective plot >> transformation. As a result, the "revolution" pattern looks like a circle >> in 2D, but in 3D perspective you would interpret that 2D circle as an >> ellipse in 3D space (i.e., the effective 3D character size depends on >> inclination and viewing angle). Since plptex3 is supposed to be in (3D) >> world coordinates, I suspect it will be used by users to identify specific >> areas of 3D surfaces, and it will be an annoyance to have the effective 3D >> character size on that surface change with inclination and viewing angle. >> Hazen, it would be great if you could deal with this issue before the >> stable >> release, but if you prefer to put it off until post 5.8.0, that is fine as >> far as I am concerned. > > I'm not sure I understand. If the text is drawn in a plane then wouldn't you > expect it's size to depend on the angle at which you viewed the plane? My point is the inferred 3D size of characters should stay the same regardless of viewing angle. According to that criterion, the end of the "revolution" pattern should form a circle in the Z=0 plane, but inspection of the screenshots shows it doesn't. For example, in the second screen shot (Hershey fonts) compare the omega = -PI/4 result with the omega = PI/4 result. The first one reaches half way to the corner while the second one reaches all the way to the corner. Instead, they should both reach a consistent fraction of the way to the corner. The first screen shot has exactly the same issue, but the fonts are systematically smaller so the -PI/4 result reaches 1/3 of the way to the corner while the PI/4 result reaches 2/3 of the way to the corner. 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-20 01:59:10
|
On Sep 19, 2007, at 1:25 AM, Alan W. Irwin wrote: > On 2007-09-19 00:04-0400 Hazen Babcock wrote: > >> Er, not a bug, a feature... I did this deliberately because I did >> not think >> it made sense to be able to shear the text so that it was drawn >> "below" the >> baseline. Also, in the documentation we say that the text will be >> drawn >> parallel to the shear line, but don't mention anything about >> directionality. >> It isn't hard to change though if you think this approach is >> incorrect. > > Yes, please. Hopefully I've fixed this in v7876. >> I'm not sure I understand. If the text is drawn in a plane then >> wouldn't you >> expect it's size to depend on the angle at which you viewed the >> plane? > > My point is the inferred 3D size of characters should stay the same > regardless of viewing angle. According to that criterion, the end > of the > "revolution" pattern should form a circle in the Z=0 plane, but > inspection > of the screenshots shows it doesn't. For example, in the second > screen shot > (Hershey fonts) compare the omega = -PI/4 result with the omega = PI/4 > result. The first one reaches half way to the corner while the > second one > reaches all the way to the corner. Instead, they should both reach a > consistent fraction of the way to the corner. The first screen > shot has > exactly the same issue, but the fonts are systematically smaller so > the > -PI/4 result reaches 1/3 of the way to the corner while the PI/4 > result > reaches 2/3 of the way to the corner. Ok, I see what you mean now. Since the characters are the same size the only way I can see to fix this is to change the spacing. -Hazen |
From: Alan W. I. <ir...@be...> - 2007-09-23 19:37:05
|
On 2007-09-19 21:56-0400 Hazen Babcock wrote: > Hopefully I've fixed this (shear allowed below the baseline) in v7876. Yes, and thanks. Note, that the png and X backends of cairo (pngcairo and xcairo) have trouble with a shear aligned exactly with the baseline so the updated x28c.c (revision 7883) offsets the angle by domega = 0.05 radians to avoid that situation without noticeably affecting what the plot looks like. I am not going to put in a bug report for the cairo backends because this case is too complicated. However, I am sure I am right that it is a problem specific to the png and X back-ends for cairo because the Postscript back end of cairo (pscairo) and the PLplot core (Hershey fonts and/or non-cairo device drivers with non-Hershey fonts) did not have any trouble with domega = 0. > Ok, I see what you mean now (about character size problem for the "revolution" case) . Since the characters are the same size the only > way I can see to fix this is to change the spacing. Actually, it is not simply spacing. If you look at the first attached screenshot for the latest x28c.c, the disparity of length of string for the z=zmin case for omega = -Pi/4 (the string only goes ~ 40% to the corner) and omega = Pi/4 (the string goes well beyond the corner) is increased for this more extreme viewing angle but basically confirms the previous results. However, please also look at the shape of the "o" characters in those two strings. They are almost perfectly round (as directly viewed) which means their inferred 3D shape is strongly elliptical. Of course, the inferred 3D shape should be circular. To solve this issue the -Pi/4 (short) string needs all its characters stretched out along the axis of the string while the Pi/4 (long) string needs all its characters compressed along the axis of the string. The size of those characters perpendicular to the string axis look pretty good in both cases. Note, the screenshot also has similar rotation results for x=xmax, and y = ymax. The errors are much more subtle for those cases, but they are there as well. Also, you can make the errors for those cases arbitrarily large by picking extreme viewing angles (such as azimuth = 85 or so). Note the first attached screen shot was produced by viewing with gv the first page of results from ./x28c -dev psc -o test.ps --drvopt text=0 You can also get very similar results by running ./x28c -dev xwin The second screenshot displays the second page of the above results which shows that (a) rotation is working fine, but (b) it also shows the justification problem for Hershey fonts (as before). Those results are properly centred on the x=xmax, y = ymax, and z=zmin planes for non-Hershey fonts. Alternatively, I can get the same results for the Hershey case by negating the justification specified for plptex3. The third page of the example (not attached) shows shear in the direction of the baseline of the string) is working fine (but also illustrates the Hershey justification problem), and the fourth page of the example (not attached) shows various 3D axis titles done using plmtex3 are working fine. I am tentatively thinking of a cool-looking fifth page for x28c.c which will show a 3D character string following a complex path in 3D space with the appropately changing inclinations and shears for each character position of the string, but I am afraid it would look pretty crummy until the above "revolution" issue is sorted out. 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-25 01:23:52
|
On Sep 23, 2007, at 3:37 PM, Alan W. Irwin wrote: > Actually, it is not simply spacing. If you look at the first attached > screenshot for the latest x28c.c, the disparity of length of string > for the > z=zmin case for omega = -Pi/4 (the string only goes ~ 40% to the > corner) and > omega = Pi/4 (the string goes well beyond the corner) is increased > for this > more extreme viewing angle but basically confirms the previous > results. > However, please also look at the shape of the "o" characters in > those two > strings. They are almost perfectly round (as directly viewed) > which means > their inferred 3D shape is strongly elliptical. Of course, the > inferred 3D > shape should be circular. To solve this issue the -Pi/4 (short) > string > needs all its characters stretched out along the axis of the string > while > the Pi/4 (long) string needs all its characters compressed along > the axis of > the string. The size of those characters perpendicular to the > string axis > look pretty good in both cases. Note, the screenshot also has similar > rotation results for x=xmax, and y = ymax. The errors are much > more subtle > for those cases, but they are there as well. Also, you can make > the errors > for those cases arbitrarily large by picking extreme viewing angles > (such as > azimuth = 85 or so). Ok, but the ability to arbitrarily transform characters is not supported by some of the drivers, like aqt. In theory the cairo drivers could support this, but as currently written they also do not. When I was writing plptex3 I was thinking more faux 3D rather than true 3D character rendering, but it does seem reasonable that we should strive for the true 3D case. I believe that this will be a bit complicated however so I propose waiting until the after the next release. -Hazen |
From: Alan W. I. <ir...@be...> - 2007-09-23 19:40:04
Attachments:
snapshot112.png
snapshot113.png
|
This time (sigh) I have really attached the screenshots. 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-25 04:39:28
|
On 2007-09-24 21:21-0400 Hazen Babcock wrote: > When I was writing plptex3 I was thinking more faux 3D rather than true 3D > character rendering, but it does seem reasonable that we should strive for > the true 3D case. I believe that this will be a bit complicated however so I > propose waiting until the after the next release. That plan to put off the plptex3 changes sounds fine. After all you will soon have plenty on your plate as release manager. Furthermore, once we hear from Andrew Ross about whether he wants to do anything with octave before the release, and we have made our own arrangments for the changes and testing of the script that does the website example plot generation, we should be in a good position to nail down the release date. 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 __________________________ |