Re: [Plplot-devel] Font problem with plplotcanvas
On 2008-07-21 08:47+0200 Martin Sarajervi wrote: > I run the latest release-version on Linux. > > >> There are a multitude of configuration options to choose your font files >> for >> drivers like gcw that use plfreetype. >> >> I was just going to refer you to >> >> http://plplot.sourceforge.net/docbook-manual/plplot-html-5.9.0/characters.html >> for documentation, but it needs updating. For example, I noticed it refers >> to ./configure --help which is a historical artifact that is no longer >> valid >> for our CMake-based build system. Instead, look at the results in >> CMakeCache.txt in your build tree for the relevant information. >> >> Here is just the start of those results on my system: >> >> [EMAIL PROTECTED]> grep PL_FREE CMakeCache.txt |head -10 >> PL_FREETYPE_FONT_PATH:PATH=/usr/share/fonts/truetype/freefont >> //Font file for PL_FREETYPE_MONO >> PL_FREETYPE_MONO:FILEPATH=FreeMono.ttf >> //Font file for PL_FREETYPE_MONO_BOLD >> PL_FREETYPE_MONO_BOLD:FILEPATH=FreeMonoBold.ttf >> //Font file for PL_FREETYPE_MONO_BOLD_ITALIC >> PL_FREETYPE_MONO_BOLD_ITALIC:FILEPATH=FreeMonoBoldOblique.ttf >> //Font file for PL_FREETYPE_MONO_BOLD_OBLIQUE >> PL_FREETYPE_MONO_BOLD_OBLIQUE:FILEPATH=FreeMonoBoldOblique.ttf >> //Font file for PL_FREETYPE_MONO_ITALIC > > > The thing is, the truetypefonts works fine when I do normal plots (not using > the gnome2 canvas). > I have the same result from the grep (only with another PATH that I have > specified). In that dir I have placed fonts > FreeMono*, FreeSans*, FreeSerif*. I did download these manually and place > them there, but again, it works fine when plutting without gcw (I get smooth > truetype/"freetype" fonts on the labels). Just to confirm you have set up your fonts correctly, please give the exact results of the above command on your system, and also the results of ls on the absolute path directory pointed to by PL_FREETYPE_FONT_PATH. IOW, do not cd to the directory, simply execute ls /usr/share/fonts/truetype/freefont or whatever your exact PL_FREETYPE_FONT_PATH is. > This is the main reason for me suspecting something gcw specific, does gcw > expect some different fonts or odoes it have any other compile parameters > that I may have missed? Which device gives you good-looking fonts? The point is some of the devices use fontconfig (where system fonts are found automatically) and some use plfreetype (like gcw where you may have to go to some trouble to access your fonts). In particular, do you get good-looking results for -dev png (which also uses plfreetype)? I just tried -dev gcw for myself using both examples/c/x01c -dev gcw and examples/c/plplotcanvas_animation _in the install_ directory, and the fonts looked good. I frankly cannot remember whether there were any bugs in gcw or plfreetype in our latest release that have been fixed in the svn trunk version, but that version (which is what I use) is pretty stable at the moment so you might want to try that following the directions at http://sourceforge.net/svn/?group_id=118417 Also, could you give your Linux distribution name and version and libfreetype version? I am grasping at straws here, but it is possible your problems may have to do with the particular version of libfreetype that you have and nothing to do with PLplot. 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 the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] plimagefr coordinate transform support, now with example
Andrew, Thank you for applying these changes! Other comment/answers below. On Sat, Jul 19, 2008 at 5:43 PM, Andrew Ross <[EMAIL PROTECTED]> wrote: > 1) Rather than changing comments to // to nest them inside /* ... */ I > would suggest just using > #if 0 > ... > #endif > around the code block. (I've implemented this.) We try to avoid C++ > style comments in C code. Thank you for this tip. Using "#if 0 .. #endif" had not occurred to me. > 2) I notice you commented out the call to plP_image in rdbug_image since > the API has changed. Yes, from what I can tell these functions are only important for the fast_img rendering path because the "slow" rendering path effectively treats each pixel as a polygon to be individually plotted so no special handling is required. I think something like a fast_img rendering path may be more useful for Postscript, PDF and similar vector-based output targets because, at least for untransformed images, it could greatly reduce the output size of plots if a plotted image were represented as a blob of binary image data rather than a large set of individual polygons. I don't know enough about Postscript, PDF, Cairo or the related PLplot output drivers to be sure how to address this though. > 3) Your patch breaks various other language bindings. For now I have > disabled plimagefr support in f77 / f95. These require a bit of work to > support pltr and I've not had time today. If someone else would like to > take this on it would be great. Hez, you might like to look at how > plcont and plvect work (with internal plfcont and plfvect functions) to > aid the f77 / f95 bindings. Best to make the plimagefr consistent. This > will be an internal change for the C API though so I've gone ahead and > commited your existing version for now. It will probably take me some time to address this, but I can certainly take a stab at it. > 4) Other languages will need plimagefr support adding once we've > finalised the API. Also all (non-C) versions of example 20 will need > updating. I tried to keep the interface to the function as similar to the plimage and plshade* routines as possible. The argument list is quite long, but I don't know if there is any reasonable way around that. > 5) You example transformation in example 20 is quite subtle. Perhaps > something like a shear would be more obvious and generally useful > example? I like your new transformation in example 20 much more than the one I had initially included. It should be much more generally useful. Thanks to both you and Alan for taking the time to review and apply my recent string of patches. Hez -- Hezekiah M. Carty Graduate Research Assistant University of Maryland Department of Atmospheric and Oceanic Science - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Font problem with plplotcanvas
On 7/21/08, Alan W. Irwin <[EMAIL PROTECTED]> wrote: > > On 2008-07-21 08:47+0200 Martin Sarajervi wrote: > > I run the latest release-version on Linux. >> >> >> There are a multitude of configuration options to choose your font files >>> for >>> drivers like gcw that use plfreetype. >>> >>> I was just going to refer you to >>> >>> >>> http://plplot.sourceforge.net/docbook-manual/plplot-html-5.9.0/characters.html >>> for documentation, but it needs updating. For example, I noticed it >>> refers >>> to ./configure --help which is a historical artifact that is no longer >>> valid >>> for our CMake-based build system. Instead, look at the results in >>> CMakeCache.txt in your build tree for the relevant information. >>> >>> Here is just the start of those results on my system: >>> >>> [EMAIL PROTECTED]> grep PL_FREE CMakeCache.txt |head -10 >>> PL_FREETYPE_FONT_PATH:PATH=/usr/share/fonts/truetype/freefont >>> //Font file for PL_FREETYPE_MONO >>> PL_FREETYPE_MONO:FILEPATH=FreeMono.ttf >>> //Font file for PL_FREETYPE_MONO_BOLD >>> PL_FREETYPE_MONO_BOLD:FILEPATH=FreeMonoBold.ttf >>> //Font file for PL_FREETYPE_MONO_BOLD_ITALIC >>> PL_FREETYPE_MONO_BOLD_ITALIC:FILEPATH=FreeMonoBoldOblique.ttf >>> //Font file for PL_FREETYPE_MONO_BOLD_OBLIQUE >>> PL_FREETYPE_MONO_BOLD_OBLIQUE:FILEPATH=FreeMonoBoldOblique.ttf >>> //Font file for PL_FREETYPE_MONO_ITALIC >>> >> >> >> The thing is, the truetypefonts works fine when I do normal plots (not >> using >> the gnome2 canvas). >> I have the same result from the grep (only with another PATH that I have >> specified). In that dir I have placed fonts >> FreeMono*, FreeSans*, FreeSerif*. I did download these manually and place >> them there, but again, it works fine when plutting without gcw (I get >> smooth >> truetype/"freetype" fonts on the labels). >> > > Just to confirm you have set up your fonts correctly, please give the exact > results of the above command on your system, and also the results of ls on > the absolute path directory pointed to by PL_FREETYPE_FONT_PATH. IOW, do > not cd to the directory, simply execute > > ls /usr/share/fonts/truetype/freefont > > or whatever your exact PL_FREETYPE_FONT_PATH is. > > This is the main reason for me suspecting something gcw specific, does gcw >> expect some different fonts or odoes it have any other compile parameters >> that I may have missed? >> > > Which device gives you good-looking fonts? The point is some of the > devices > use fontconfig (where system fonts are found automatically) and some use > plfreetype (like gcw where you may have to go to some trouble to access > your > fonts). In particular, do you get good-looking results for -dev png (which > also uses plfreetype)? > > I just tried -dev gcw for myself using both examples/c/x01c -dev gcw and > examples/c/plplotcanvas_animation _in the install_ directory, and the fonts > looked good. > > I frankly cannot remember whether there were any bugs in gcw or plfreetype > in our latest release that have been fixed in the svn trunk version, but > that version (which is what I use) is pretty stable at the moment so you > might want to try that following the directions at > http://sourceforge.net/svn/?group_id=118417 > > Also, could you give your Linux distribution name and version and > libfreetype version? I am grasping at straws here, but it is possible your > problems may have to do with the particular version of libfreetype that you > have and nothing to do with PLplot. Ok, here we go with some debugging information: [EMAIL PROTECTED] /h/masar/plplot-5.9.0/Compilation> grep PL_FREE CMakeCache.txt | head -10 PL_FREETYPE_FONT_PATH:PATH=/h/masar/sfd //Font file for PL_FREETYPE_MONO PL_FREETYPE_MONO:FILEPATH=FreeMono.ttf //Font file for PL_FREETYPE_MONO_BOLD PL_FREETYPE_MONO_BOLD:FILEPATH=FreeMonoBold.ttf //Font file for PL_FREETYPE_MONO_BOLD_ITALIC PL_FREETYPE_MONO_BOLD_ITALIC:FILEPATH=FreeMonoBoldOblique.ttf //Font file for PL_FREETYPE_MONO_BOLD_OBLIQUE PL_FREETYPE_MONO_BOLD_OBLIQUE:FILEPATH=FreeMonoBoldOblique.ttf //Font file for PL_FREETYPE_MONO_ITALIC [EMAIL PROTECTED] /h/masar/plplot-5.9.0/Compilation> ls -l /h/masar/sfd total 3536 -rw-rw-r-- 1 masar masar 128384 Oct 8 2003 FreeMonoBoldOblique.ttf -rw-rw-r-- 1 masar masar 175016 Oct 8 2003 FreeMonoBold.ttf -rw-rw-r-- 1 masar masar 175484 Oct 8 2003 FreeMonoOblique.ttf -rw-rw-r-- 1 masar masar 293572 Oct 8 2003 FreeMono.ttf -rw-rw-r-- 1 masar masar 95508 Oct 8 2003 FreeSansBoldOblique.ttf -rw-rw-r-- 1 masar masar 91432 Oct 8 2003 FreeSansBold.ttf -rw-rw-r-- 1 masar masar 110740 Oct 8 2003 FreeSansOblique.ttf -rw-rw-r-- 1 masar masar 264072 Oct 8 2003 FreeSans.ttf -rw-rw-r-- 1 masar masar 126456 Oct 8 2003 FreeSerifBoldItalic.ttf -rw-rw-r-- 1 masar masar 198992 Oct 8 2003 FreeSerifBold.ttf -rw-rw-r-- 1 masar masar 154900 Oct 8 2003 FreeSerifItalic.ttf -rw-rw-r-- 1 masar masar 621136 Oct 8 2003 FreeSerif.ttf I now tried the following: ./x01c -dev png this one outputs just
