From: Thomas J. D. <to...@fi...> - 2005-04-27 19:32:46
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I have noticed that some of the examples seem to be broken: x22c - the last page has the viewport filled in with a solid colour (tested psc, gcw) x24c - produces FCI errors on drivers with unicode (tested psc, png, gcw) Can somebody please confirm these problems? Note that everything seems fine for the xwin driver. Thanks, Tom - -- Thomas J. Duck <to...@fi...> Department of Physics and Atmospheric Science, Dalhousie University, Halifax, Nova Scotia, Canada, B3H 3J5. Tel: (902)494-1456 | Fax: (902)494-5191 | Lab: (902)494-3813 Web: http://aolab.phys.dal.ca/~tomduck/ Public key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x17D965DB -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCb+bAndxDHhfZZdsRAjPhAJoD6edQy2aEE0J9fHLCN+aYnJ1S+ACgyuaQ 8zkbodHPOpm91IngphzrSAI= =dQ4D -----END PGP SIGNATURE----- |
From: Rafael L. <rla...@us...> - 2005-04-27 22:53:18
|
* Thomas J. Duck <to...@fi...> [2005-04-27 16:23]: > I have noticed that some of the examples seem to be broken: > > x24c - produces FCI errors on drivers with unicode (tested psc, png, gcw) The following command works fine here in HEAD: PLPLOT_FREETYPE_SANS_FONT=/usr/share/fonts/truetype/arphic/bkai00mp.ttf \ PLPLOT_FREETYPE_SERIF_FONT=/usr/share/fonts/truetype/freefont/FreeSerif.ttf \ PLPLOT_FREETYPE_MONO_FONT=/usr/share/fonts/truetype/ttf-indic-fonts/lohit_hi.ttf \ PLPLOT_FREETYPE_SCRIPT_FONT=/usr/share/fonts/truetype/unfonts/UnBatang.ttf \ PLPLOT_FREETYPE_SYMBOL_FONT=/usr/share/fonts/truetype/ttf-bangla-fonts/JamrulNormal.ttf \ ./x24c -dev png -drvopt text,smooth=0 -o x24c.png Does it work for you? -- Rafael |
From: Arjen M. <arj...@wl...> - 2005-04-28 06:52:37
|
Rafael Laboissiere wrote: > > * Thomas J. Duck <to...@fi...> [2005-04-27 16:23]: > > > I have noticed that some of the examples seem to be broken: > > > > x24c - produces FCI errors on drivers with unicode (tested psc, png, gcw) > > The following command works fine here in HEAD: > > PLPLOT_FREETYPE_SANS_FONT=/usr/share/fonts/truetype/arphic/bkai00mp.ttf \ > PLPLOT_FREETYPE_SERIF_FONT=/usr/share/fonts/truetype/freefont/FreeSerif.ttf \ > PLPLOT_FREETYPE_MONO_FONT=/usr/share/fonts/truetype/ttf-indic-fonts/lohit_hi.ttf \ > PLPLOT_FREETYPE_SCRIPT_FONT=/usr/share/fonts/truetype/unfonts/UnBatang.ttf \ > PLPLOT_FREETYPE_SYMBOL_FONT=/usr/share/fonts/truetype/ttf-bangla-fonts/JamrulNormal.ttf \ > ./x24c -dev png -drvopt text,smooth=0 -o x24c.png > > Does it work for you? > Quite apart from that, the examples can not be compiled and linked right now using Windows/MSVC - this is due to the changes in the names of several functions (plParseOpts() -> plparseopts() etc.). I have not had time to correct this yet - some other (for me) more pressing matters (filling clipped polygons still does not work satisfactorily) have gotten in the way. (I did try to solve it, but I did not realise that the names in the C code had changed too. The whole thing is rather complex, unfortunately) Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2005-04-28 01:39:06
|
On 2005-04-27 16:23-0300 Thomas J. Duck wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > I have noticed that some of the examples seem to be broken: > > x22c - the last page has the viewport filled in with a solid colour > (tested psc, gcw) For fresh checkout from CVS HEAD.... I verify this bug for python front end and -dev psc and xwin. If you set fill to 0, the problem goes away so it is fill=1 that is triggering the bug. Also, if you look at how psc "paints" the last page, all but the perimeter of the plot is layed down okay, then a solid blue square filling the entire viewport overlays that, then the perimeter overlays that. If you got rid of that blue square I think everything would be okay. Just to confuse issues, for the C version of the example, there is no problem for -dev xwin, but -dev psc does have the bug. Anyhow, there is clearly a bug with vector plotting now. > > x24c - produces FCI errors on drivers with unicode (tested psc, png, gcw) I cannot confirm this bug for fresh checkout from CVS head. Are you running this example according to instructions inside x24c.c? It only works properly for devices with truetype fonts (so that lets out psc), and devices where you can change the font name at run time with environment variables (that applies to png, but I am not sure that applies to gcw or not). Anyhow, if I follow the instructions inside the current example for changing font environment variables I get good results for -dev png. (Note, I just updated those instructions to replace one font location with another that is suitable for Debian testing.) If I use default fonts (ie don't set the environment variables), then -dev psc, png, and xwin all produce incorrect or incomplete (psc) results as expected, but no FCI errors. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 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 Yorick front-end to PLplot (yplot.sf.net); 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...> - 2005-04-28 04:02:44
|
On 2005-04-27 18:39-0700 Alan W. Irwin wrote: > > For fresh checkout from CVS HEAD.... > > ... if you look at how psc "paints" the last page, all but the perimeter > of the plot is layed down okay, then a solid blue square filling the entire > viewport overlays that... Just had a quick thought. I bet this be related to the change that Arjen recently made for clipping. If you had a blue filled arrow intersecting the viewport clipping limit, and the clipping limit went the incorrect "long" way around the viewport boundaries you would get a blue square. And the results could well depend on front end like I observed since there are small floating-point inconsistencies between front ends. Arjen, could you please (a) confirm the problem, and (b) try privately reverting your change to see if this blue square problem for example 22 goes away? For complicated fill shapes this is obviously (as Maurice also stated) a difficult piece of logic to get right. Think of a fractal shape that you want to fill and also clip arbitrarily. :-) If your change to that logic is the culprit, then it is "back to the drawing board" to figure out general clipping logic that works in all cases no matter how complicated the fill shape. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 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 Yorick front-end to PLplot (yplot.sf.net); 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...> - 2005-04-28 04:19:38
|
On 2005-04-28 00:53+0200 Rafael Laboissiere wrote: > * Thomas J. Duck <to...@fi...> [2005-04-27 16:23]: > >> I have noticed that some of the examples seem to be broken: >> >> x24c - produces FCI errors on drivers with unicode (tested psc, png, gcw) > > The following command works fine here in HEAD: > > PLPLOT_FREETYPE_SANS_FONT=/usr/share/fonts/truetype/arphic/bkai00mp.ttf \ > PLPLOT_FREETYPE_SERIF_FONT=/usr/share/fonts/truetype/freefont/FreeSerif.ttf \ > PLPLOT_FREETYPE_MONO_FONT=/usr/share/fonts/truetype/ttf-indic-fonts/lohit_hi.ttf \ > PLPLOT_FREETYPE_SCRIPT_FONT=/usr/share/fonts/truetype/unfonts/UnBatang.ttf \ > PLPLOT_FREETYPE_SYMBOL_FONT=/usr/share/fonts/truetype/ttf-bangla-fonts/JamrulNormal.ttf \ > ./x24c -dev png -drvopt text,smooth=0 -o x24c.png > > Does it work for you? Actually, I don't think the above command will work for you (at least if you have updated your system). In the above instructions you should change ttf-indic-fonts ==> ttf-devanagari-fonts as in the changed instructions that I just committed. Recently, the ttf-indic-fonts directory seems to have emptied (except for an empty fonts.cache-1 file) in Debian testing. I think that is because ttf-indic-fonts is now simply a convenience package (both in testing and unstable) that depends on other separate fonts packages such as ttf-devanagari-fonts. Anyhow, because of that Debian testing and Debian unstable change to ttf-indic-fonts, I believe you will have to follow the revised instructions. Rafael, please let me know if the new instructions fail to work for Debian unstable. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 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 Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Arjen M. <arj...@wl...> - 2005-04-28 07:37:53
|
"Alan W. Irwin" wrote: > > On 2005-04-27 18:39-0700 Alan W. Irwin wrote: > > > > > For fresh checkout from CVS HEAD.... > > > > ... if you look at how psc "paints" the last page, all but the perimeter > > of the plot is layed down okay, then a solid blue square filling the entire > > viewport overlays that... > > Just had a quick thought. I bet this be related to the change that Arjen > recently made for clipping. If you had a blue filled arrow intersecting the > viewport clipping limit, and the clipping limit went the incorrect "long" > way around the viewport boundaries you would get a blue square. And the > results could well depend on front end like I observed since there are small > floating-point inconsistencies between front ends. > > Arjen, could you please (a) confirm the problem, and (b) try privately > reverting your change to see if this blue square problem for example 22 goes > away? For complicated fill shapes this is obviously (as Maurice also > stated) a difficult piece of logic to get right. Think of a fractal shape > that you want to fill and also clip arbitrarily. :-) If your change to that > logic is the culprit, then it is "back to the drawing board" to figure out > general clipping logic that works in all cases no matter how complicated the > fill shape. > Alan, Example 22 is about arrows, I just checked it with the latest version of plline.c (there were indeed a couple bugs in there) and found no obvious problem. I will need to check further as for some reason one of the Windows-specific files will not compile in version 5.5.x - grrrr ... linkage specification problems. Regards, Arjen PS Example 22 by the way uses new C features that are not supported in Windows/MSVC 6.0 - I will commit a new version. |
From: Arjen M. <arj...@wl...> - 2005-04-28 08:00:43
|
Arjen Markus wrote: > > I will need to check further as for some reason one > of the Windows-specific files will not compile in version 5.5.x - grrrr > ... > linkage specification problems. > For reasons beyond my comprehension, the compiler now accepts the source code. So, continuing the check ... Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2005-04-28 08:21:55
|
"Alan W. Irwin" wrote: > > On 2005-04-27 18:39-0700 Alan W. Irwin wrote: > > > > > For fresh checkout from CVS HEAD.... > > > > ... if you look at how psc "paints" the last page, all but the perimeter > > of the plot is layed down okay, then a solid blue square filling the entire > > viewport overlays that... > > Just had a quick thought. I bet this be related to the change that Arjen > recently made for clipping. If you had a blue filled arrow intersecting the > viewport clipping limit, and the clipping limit went the incorrect "long" > way around the viewport boundaries you would get a blue square. And the > results could well depend on front end like I observed since there are small > floating-point inconsistencies between front ends. > > Arjen, could you please (a) confirm the problem, and (b) try privately > reverting your change to see if this blue square problem for example 22 goes > away? For complicated fill shapes this is obviously (as Maurice also > stated) a difficult piece of logic to get right. Think of a fractal shape > that you want to fill and also clip arbitrarily. :-) If your change to that > logic is the culprit, then it is "back to the drawing board" to figure out > general clipping logic that works in all cases no matter how complicated the > fill shape. > Alan, I just checked with the latest fresh CVS checkout: Example 22 looks just fine - I did run on Windows XP, rather than Linux and I know that plline.c contains a few bugs. I have just committed a new version. Please check if that solves the issue. (Right now I can not easily check this on Linux). The shapes I have to deal with by the way are land boundaries - not quite fractal but complicated and irregular ;). Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2005-04-28 13:17:59
|
Hello all, I currently have a problem with the interpolation methods GRID_CSA and GRID_NNLI on Windows (example 21): - GRID_CSA returns all NaNs - GRID_NNLI returns a uniform field of zeros it appears. I have informed Pavel Sakov about the first problem, but can anyone shed a light on the second problem? (I hope to be able to use the CSA method - but right now I am going to go for GRID_NNAIDW ...) Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2005-04-28 21:50:12
|
On 2005-04-28 10:21+0200 Arjen Markus wrote: > Alan, > > I just checked with the latest fresh CVS checkout: > Example 22 looks just fine - I did run on Windows XP, rather than Linux > and I know that plline.c contains a few bugs. I have just committed a > new version. Please check if that solves the issue. (Right now I can > not easily check this on Linux). > > The shapes I have to deal with by the way are land boundaries - not > quite > fractal but complicated and irregular ;). Arjen, I just tested your plline.c fix for Linux (Debian testing), and all is well for example 22 and also the rest of the examples (for the psc device driver and C examples). So I think you have cracked it. Congratulations! Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 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 Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Arjen M. <arj...@wl...> - 2005-05-03 06:43:15
|
"Alan W. Irwin" wrote: > > On 2005-04-28 10:21+0200 Arjen Markus wrote: > > > Alan, > > > > I just checked with the latest fresh CVS checkout: > > Example 22 looks just fine - I did run on Windows XP, rather than Linux > > and I know that plline.c contains a few bugs. I have just committed a > > new version. Please check if that solves the issue. (Right now I can > > not easily check this on Linux). > > > > The shapes I have to deal with by the way are land boundaries - not > > quite > > fractal but complicated and irregular ;). > > Arjen, I just tested your plline.c fix for Linux (Debian testing), and all > is well for example 22 and also the rest of the examples (for the psc device > driver and C examples). > > So I think you have cracked it. Congratulations! > Well, not quite, but I have found a way to get it done, I think ;). One of my previous polygons is disfigured now - this is due to the complicated business of making a subpolygon to see if the encircled corner is inside the polygon or not. There is actually no need to do it like that: just record which corners are inside at the beginning and reuse that information. This makes the logic a bit clearer too. Regards, Arjen |