Re: [Plplot-devel] Example 28 testing of the new plptex3 and plmtex3 API
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 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Example 28 testing of the new plptex3 and plmtex3 API
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 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Example 28 testing of the new plptex3 and plmtex3 API
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 __ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Example 28 testing of the new plptex3 and plmtex3 API
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 __ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Example 28 testing of the new plptex3 and plmtex3 API
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 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Example 28 testing of the new plptex3 and plmtex3 API
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 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
