From: <jc...@fe...> - 2002-09-16 13:03:42
|
Hi, In the current cvs I can't use the png driver: [jcard@feup] ./x01c -dev png -o po.png -debug Plplot library version: 5.1.0 plLoadDriver: Device not loaded! plLoadDriver: tag=3Dpng, drvidx=3D4 plLoadDriver: Trying to load gdd_drv.so on ./drivers/gdd_drv.so plLoadDriver: Trying to load at=20 /usr/local/lib/plplot5.1.0/data/../drivers/gdd_drv.so Unable to load driver: gdd_drv.so. Reason: /usr/local/lib/plplot5.1.0/data/../drivers/gdd_drv.so: cannot=20 open shared object file: No such file or directory Segmentation fault Notice that I'm runing from the build tmp directory, that=20 drivers/gdd_drv.so exists, there is no installed plplot, this also=20 happens with the single precision driver, it does not happens with any=20 other drivers, this happens in a freshly installed suse-8.0. If I change in plcore.c, line 1855, RTLD_NOW to RTLD_LAZY, it works: [jcard@feup] ./x01c -dev png -o po.png -debug Plplot library version: 5.1.0 plLoadDriver: Device not loaded! plLoadDriver: tag=3Dpng, drvidx=3D4 plLoadDriver: Trying to load gdd_drv.so on ./drivers/gdd_drv.so Opened po.png Segmentation fault Oops... at home it worked (exactly same environement). Nevertheless, now=20 the driver is opened and the output file created and partly filled, so=20 there is some problem here. Of course using LAZY instead of NOW would fix the problem (and I don't=20 understand why would anyone make it NOW instead of LATTER, if he can=20 :-) Joao |
From: Alan W. I. <ir...@be...> - 2002-09-16 17:45:21
|
On Mon, 16 Sep 2002, [iso-8859-1] Jo=E3o Cardoso wrote: > > Hi, > > In the current cvs I can't use the png driver: > > [jcard@feup] ./x01c -dev png -o po.png -debug > Plplot library version: 5.1.0 > plLoadDriver: Device not loaded! > plLoadDriver: tag=3Dpng, drvidx=3D4 > plLoadDriver: Trying to load gdd_drv.so on ./drivers/gdd_drv.so > plLoadDriver: Trying to load at > /usr/local/lib/plplot5.1.0/data/../drivers/gdd_drv.so > Unable to load driver: gdd_drv.so. > Reason: /usr/local/lib/plplot5.1.0/data/../drivers/gdd_drv.so: cannot > open shared object file: No such file or directory This misleading error message from the wrong (second) dlerror has been annoying me for a while so I just fixed it in CVS. Could you please try this again after cvs update? That should give you both the first and secon= d dlerror error messages with the -debug option (and no dlerror error message= s if you don't specify -debug). Once the first dlerror message is output, I suspect you will get an error message about no access to a symbol in one of our libraries. If so, could you try to fix it by setting LD_LIBRARY_PATH to point to the directory (./ in this case) where our libraries have been built? > If I change in plcore.c, line 1855, RTLD_NOW to RTLD_LAZY, it works: > > [jcard@feup] ./x01c -dev png -o po.png -debug > Plplot library version: 5.1.0 > plLoadDriver: Device not loaded! > plLoadDriver: tag=3Dpng, drvidx=3D4 > plLoadDriver: Trying to load gdd_drv.so on ./drivers/gdd_drv.so > Opened po.png > Segmentation fault > > Oops... at home it worked (exactly same environement). Nevertheless, now > the driver is opened and the output file created and partly filled, so > there is some problem here. I don't need the RTLD_LAZY (or LD_LIBRARY_PATH under Debian), but I do confirm the second error you have just found. Something is now wrong with the gd device driver if you don't specify -drvopt text. I will look into i= t further. From=20the Linux dlopen man page at http://nodevice.com/sections/ManIndex/man0254.html, I don't see how RTLD_LAZY will fix the problem. It will, however, delay the problem until you actually try to use the symbols, and you may have encountered the secon= d error (see above) before that happened. Once you re-run with the proper dlerror message and RTLD_NOW, we will know more. Alan |
From: <jc...@fe...> - 2002-09-16 18:21:21
|
On Monday 16 September 2002 18:45, Alan W. Irwin wrote: | On Mon, 16 Sep 2002, [iso-8859-1] Jo=E3o Cardoso wrote: | > Hi, | > | > In the current cvs I can't use the png driver: | > | > [jcard@feup] ./x01c -dev png -o po.png -debug | > Plplot library version: 5.1.0 | > plLoadDriver: Device not loaded! | > plLoadDriver: tag=3Dpng, drvidx=3D4 | > plLoadDriver: Trying to load gdd_drv.so on ./drivers/gdd_drv.so | > plLoadDriver: Trying to load at | > /usr/local/lib/plplot5.1.0/data/../drivers/gdd_drv.so | > Unable to load driver: gdd_drv.so. | > Reason: /usr/local/lib/plplot5.1.0/data/../drivers/gdd_drv.so: | > cannot open shared object file: No such file or directory | | This misleading error message from the wrong (second) dlerror has | been annoying me for a while so I just fixed it in CVS. Could you | please try this again after cvs update? That should give you both | the first and second dlerror error messages with the -debug option | (and no dlerror error messages if you don't specify -debug). | | Once the first dlerror message is output, I suspect you will get an | error message about no access to a symbol in one of our libraries.=20 | If so, could you try to fix it by setting LD_LIBRARY_PATH to point to | the directory (./ in this case) where our libraries have been built? | | > If I change in plcore.c, line 1855, RTLD_NOW to RTLD_LAZY, it | > works: | > | > [jcard@feup] ./x01c -dev png -o po.png -debug | > Plplot library version: 5.1.0 | > plLoadDriver: Device not loaded! | > plLoadDriver: tag=3Dpng, drvidx=3D4 | > plLoadDriver: Trying to load gdd_drv.so on ./drivers/gdd_drv.so | > Opened po.png | > Segmentation fault | > | > Oops... at home it worked (exactly same environement). | > Nevertheless, now the driver is opened and the output file created | > and partly filled, so there is some problem here. | | I don't need the RTLD_LAZY (or LD_LIBRARY_PATH under Debian), but I | do confirm the second error you have just found. Something is now | wrong with the gd device driver if you don't specify -drvopt text. I | will look into it further. | | From the Linux dlopen man page at | http://nodevice.com/sections/ManIndex/man0254.html, I don't see how | RTLD_LAZY will fix the problem. It will, however, delay the problem | until you actually try to use the symbols, and you may have | encountered the second error (see above) before that happened. Once | you re-run with the proper dlerror message and RTLD_NOW, we will know | more. | | Alan [jcard@feup] make x01c && LD_LIBRARY_PATH=3D. ./x01c -dev png -o po.png=20 -debug make: `x01c' is up to date. Plplot library version: 5.1.0 plLoadDriver: Device not loaded! plLoadDriver: tag=3Dpng, drvidx=3D4 plLoadDriver: Trying to load gdd_drv.so on ./drivers/gdd_drv.so plLoadDriver: Local dlopen failed because of the following reason: =2E/drivers/gdd_drv.so: undefined symbol: gdImagePalettePixel plLoadDriver: Trying to load at=20 /usr/local/lib/plplot5.1.0/data/../drivers/gdd_drv.so plLoadDriver: Global dlopen failed because of the following reason: /usr/local/lib/plplot5.1.0/data/../drivers/gdd_drv.so: cannot open=20 shared object file: No such file or directory Unable to load driver: gdd_drv.so. Segmentation fault [jcard@feup] rpm -q gd gd-1.8.4-238 And gdImagePalettePixel() does not exists in the gd library. Joao | | | | ------------------------------------------------------- | This sf.net email is sponsored by:ThinkGeek | Welcome to geek heaven. | http://thinkgeek.com/sf | _______________________________________________ | Plplot-devel mailing list | Plp...@li... | https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: <jc...@fe...> - 2002-09-16 19:06:35
|
On Monday 16 September 2002 19:21, Jo=E3o Cardoso wrote: | On Monday 16 September 2002 18:45, Alan W. Irwin wrote: | | On Mon, 16 Sep 2002, [iso-8859-1] Jo=E3o Cardoso wrote: | | > Hi, | | > | | > In the current cvs I can't use the png driver: =2E.. | [jcard@feup] make x01c && LD_LIBRARY_PATH=3D. ./x01c -dev png -o po.png | -debug | make: `x01c' is up to date. | Plplot library version: 5.1.0 | plLoadDriver: Device not loaded! | plLoadDriver: tag=3Dpng, drvidx=3D4 | plLoadDriver: Trying to load gdd_drv.so on ./drivers/gdd_drv.so | plLoadDriver: Local dlopen failed because of the following reason: | ./drivers/gdd_drv.so: undefined symbol: gdImagePalettePixel | plLoadDriver: Trying to load at | /usr/local/lib/plplot5.1.0/data/../drivers/gdd_drv.so | plLoadDriver: Global dlopen failed because of the following reason: | /usr/local/lib/plplot5.1.0/data/../drivers/gdd_drv.so: cannot open | shared object file: No such file or directory | Unable to load driver: gdd_drv.so. | Segmentation fault | | [jcard@feup] rpm -q gd | gd-1.8.4-238 | | And gdImagePalettePixel() does not exists in the gd library. I found that gdImagePalettePixel() is really a macro: #define gdImagePalettePixel( im, x, y ) (im)->pixels[(y)][(x)] So, putting it above gd.c:plD_gd_optimise(), makes the unknown symbol=20 error to disappear, but the seg fault still happens: [jcard@feup] ./x01c -dev png -o po.png Plplot library version: 5.1.0 Opened po.png Segmentation fault [jcard@feup] ./x01c -dev png -o po.png -debug Plplot library version: 5.1.0 plLoadDriver: Device not loaded! plLoadDriver: tag=3Dpng, drvidx=3D4 plLoadDriver: Trying to load gdd_drv.so on ./drivers/gdd_drv.so Opened po.png Segmentation fault [jcard@feup] ls -l po.png -rw-r--r-- 1 jcard users 8192 Sep 16 20:01 po.png Notice that the file is written to some extent. Joao |
From: Alan W. I. <ir...@be...> - 2002-09-16 20:20:58
|
On Mon, 16 Sep 2002, [iso-8859-1] Jo=E3o Cardoso wrote: > I found that gdImagePalettePixel() is really a macro: > > #define gdImagePalettePixel( im, x, y ) (im)->pixels[(y)][(x)] > > So, putting it above gd.c:plD_gd_optimise(), makes the unknown symbol > error to disappear, but the seg fault still happens: > > [jcard@feup] ./x01c -dev png -o po.png > Plplot library version: 5.1.0 > Opened po.png > Segmentation fault I have now fixed this problem (but not the macro problem which I am leaving to Andrew for final decision since I don't know whether or not that macro would actually work with libgd 1.8.4 with -drvopt optimise). But if you cv= s update and work around the gdImagePalettePixel problem by adding the macro, I think you will find the above problem will be gone. BTW, Andrew, I have just checked your recent changes, and eveything seems to be fine; x08c gives good results with no drvopt and with -drvopt text,smooth,24bit and -drvopt text,smooth. Alan |
From: Joao C. <jc...@fe...> - 2002-09-17 00:15:03
|
On Monday 16 September 2002 21:20, Alan W. Irwin wrote: > On Mon, 16 Sep 2002, [iso-8859-1] Jo=E3o Cardoso wrote: > > I found that gdImagePalettePixel() is really a macro: > > > > #define gdImagePalettePixel( im, x, y ) (im)->pixels[(y)][(x)] > > > > So, putting it above gd.c:plD_gd_optimise(), makes the unknown symbo= l > > error to disappear, but the seg fault still happens: > > > > [jcard@feup] ./x01c -dev png -o po.png > > Plplot library version: 5.1.0 > > Opened po.png > > Segmentation fault > > I have now fixed this problem (but not the macro problem which I am lea= ving > to Andrew for final decision since I don't know whether or not that mac= ro > would actually work with libgd 1.8.4 with -drvopt optimise). There is something strange with the last x08c.c that I have just cvs comm= ited;=20 colors look strange under the png driver, either with -drvopt optimize or= =20 not. But I thing that it has nothing to do with the macro definition. > But if you > cvs update and work around the gdImagePalettePixel problem by adding th= e > macro, I think you will find the above problem will be gone. Yes, its gone. But I get warnings from freetype: #:~/plplot/tmp> ./x01c -dev png -o po.png -drvopt text,smooth Plplot library version: 5.1.0 Opened po.png *** PLPLOT WARNING *** Possible error defining one of the freetype compatible fonts. *** PLPLOT WARNING *** Possible error defining one of the freetype compatible fonts. *** PLPLOT WARNING *** Possible error defining one of the freetype compatible fonts. *** PLPLOT WARNING *** Possible error defining one of the freetype compatible fonts. *** PLPLOT WARNING *** Possible error defining one of the freetype compatible fonts. *** PLPLOT ERROR *** Loading a font in freetype Program aborted It looks like freetype does not find the specifyed fonts. Can anyone give= me a=20 hint? I have the standard X11 fonts, including type1 and trutype fonts: #: xset q =2E.. Font Path:=20 =2E..,/usr/X11R6/lib/X11/fonts/TTF,/usr/X11R6/lib/X11/fonts/truetype,/usr= /X11R6/lib/X11/fonts/Type1,/usr/X11R6/lib/X11/fonts/URW,... By the way, does anybody knows the (linux/X11) name of the standard 35=20 postcript fonts, the ones that *postscript* printers have by default? Joao > > BTW, Andrew, I have just checked your recent changes, and eveything see= ms > to be fine; x08c gives good results with > no drvopt and with > -drvopt text,smooth,24bit and > -drvopt text,smooth. > > Alan > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Alan W. I. <ir...@be...> - 2002-09-17 02:36:04
|
On Tue, 17 Sep 2002, Joao Cardoso wrote: > There is something strange with the last x08c.c that I have just cvs commited; > colors look strange under the png driver, either with -drvopt optimize or > not. But I thing that it has nothing to do with the macro definition. I will look at this. > It looks like freetype does not find the specifyed fonts. Can anyone give me a > hint? You have to set some environment variables to inform plfreetype where the fonts are; I know it is clumsy, but it should work for now until we can get better PLplot freetype font finding under Linux (perhaps with Keith Packard's fontconfig if/when it becomes standard part of distros?). The environment variables are mentioned in plfreetype.c. The relevant names are largely self-documenting and are PLPLOT_FREETYPE_FONT_PATH (trailing slash required) PLPLOT_NORMAL_FONT PLPLOT_ROMAN_FONT PLPLOT_ITALIC_FONT PLPLOT_SCRIPT_FONT PLPLOT_SYMBOL_FONT I have the standard X11 fonts, including type1 and trutype fonts: > > #: xset q > ... > Font Path: > ...,/usr/X11R6/lib/X11/fonts/TTF,/usr/X11R6/lib/X11/fonts/truetype,/usr/X11R6/lib/X11/fonts/Type1,/usr/X11R6/lib/X11/fonts/URW,... So I believe you could set PLPLOT_FREETYPE_FONT_PATH to /usr/X11R6/lib/X11/fonts/ and then set the other names to TTF/Arial.ttf (or whatever is appropriate for your system for normal, roman, italic, script, and symbol fonts). Please let us know if that works for your situation. Alan |
From: Joao C. <jc...@fe...> - 2002-09-17 17:07:45
|
On Tuesday 17 September 2002 03:35, Alan W. Irwin wrote: > On Tue, 17 Sep 2002, Joao Cardoso wrote: > > There is something strange with the last x08c.c that I have just cvs > > commited; colors look strange under the png driver, either with -drvo= pt > > optimize or not. But I thing that it has nothing to do with the macro > > definition. > > I will look at this. > > > It looks like freetype does not find the specifyed fonts. Can anyone = give > > me a hint? > > You have to set some environment variables to inform plfreetype where t= he > fonts are; I know it is clumsy, but it should work for now until we can= get > better PLplot freetype font finding under Linux (perhaps with Keith > Packard's fontconfig if/when it becomes standard part of distros?). > > The environment variables are mentioned in plfreetype.c. The relevant > names are largely self-documenting and are > > PLPLOT_FREETYPE_FONT_PATH (trailing slash required) > PLPLOT_NORMAL_FONT > PLPLOT_ROMAN_FONT > PLPLOT_ITALIC_FONT > PLPLOT_SCRIPT_FONT > PLPLOT_SYMBOL_FONT > > I have the standard X11 fonts, including type1 and trutype fonts: > > #: xset q > > ... > > Font Path: > > ...,/usr/X11R6/lib/X11/fonts/TTF,/usr/X11R6/lib/X11/fonts/truetype,/u= sr/X > >11R6/lib/X11/fonts/Type1,/usr/X11R6/lib/X11/fonts/URW,... > > So I believe you could set PLPLOT_FREETYPE_FONT_PATH to > /usr/X11R6/lib/X11/fonts/ and then set the other names to TTF/Arial.ttf= (or > whatever is appropriate for your system for normal, roman, italic, scri= pt, > and symbol fonts). Please let us know if that works for your situation= =2E Thanks, it works (after I changed in plfreetype.c, around line 518 #elif MSDOS if (strchr(FT->font_name[i],'\\')) #else =09 //if (strchr(FT->font_name[i],'/')) ??? jc: what ??? =09 if (!strchr(a,'/')) #endif I have set=20 echo $PLPLOT_FREETYPE_FONT_PATH $PLPLOT_NORMAL_FONT $PLPLOT_ROMAN_FONT $PLPLOT_ITALIC_FONT $PLPLOT_SCRIPT_FONT $PLPLOT_SYMBOL_FONT /usr/X11/lib/X11/fonts/TTF/ arial.ttf times.ttf timesi.ttf comic.ttf symbol.ttf Now, with this techology in plplot, we need to discuss how we are going t= o use=20 it. The text/font treatment must be discussed before we all start adding=20 truetype rendering to our prefered drivers :! Joao > > Alan > > > > ------------------------------------------------------- > Sponsored by: AMD - Your access to the experts on Hammer Technology! > Open Source & Linux Developers, register now for the AMD Developer > Symposium. Code: EX8664 http://www.developwithamd.com/developerlab > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Alan W. I. <ir...@be...> - 2002-09-17 03:46:18
|
On Tue, 17 Sep 2002, Joao Cardoso wrote: > There is something strange with the last x08c.c that I have just cvs commited; > colors look strange under the png driver, either with -drvopt optimize or > not. I confirm there is a colour problem for the first gray scale (plotsh3d) plot, but then after that as it cycles through the remaining plotfc3d, plotsh3d, and plot3d plots, everything is fine. I have given more details to Andrew, and I hope he will be able to solve this colour problem for the png device. BTW, that pltfc3d demo is really quite impressive. I am looking forward to putting it up on the website once the png driver problems are straightened out. Yes, I like all these examples of various plots of the same 3D function collected together in x08c. But now there are 4 different ways to plot each view, you might want to experiment with plssub to see if those 4 ways (mesh plot, plotsh3d, plotfc3d, plotfc3d with mesh) could be put on 4 subpages (plssub(2,2)) within each page. But we could also stick with the 16 pages we have at the moment. It is up to you. I will follow whatever further changes you decide to make to x08c with the other (tcl, python, java) interfaces to plplot when I have time. Alan |
From: Maurice L. <mj...@ga...> - 2002-09-17 07:41:09
|
Alan W. Irwin writes: > On Tue, 17 Sep 2002, Joao Cardoso wrote: > > > There is something strange with the last x08c.c that I have just cvs commited; > > colors look strange under the png driver, either with -drvopt optimize or > > not. > > I confirm there is a colour problem for the first gray scale (plotsh3d) > plot, but then after that as it cycles through the remaining plotfc3d, > plotsh3d, and plot3d plots, everything is fine. I have given more details > to Andrew, and I hope he will be able to solve this colour problem for the > png device. Hey, how does one view multiple-page png files under Linux? Neither xv nor gqview seem to support it. -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
From: Alan W. I. <ir...@be...> - 2002-09-17 17:10:13
|
On Tue, 17 Sep 2002, Maurice LeBrun wrote: > Alan W. Irwin writes: > > I confirm there is a colour problem ... > > Hey, how does one view multiple-page png files under Linux? Neither xv nor > gqview seem to support it. png is only a single-page format as far as I have ever been able to determine from the documentation of the standard. Thus, you have to use familied files to see all the PLplot pages associated with a given example, e.g., ./x08c -dev png -fam -fflen 2 -o test.png (no -fsiz is necessary). kview definitely supports viewing multiple files, e.g., kview test.png.?? and I presume the same command-line syntax would work for xv and gqview. Alan |
From: Maurice L. <mj...@ga...> - 2002-09-17 07:06:35
|
Alan W. Irwin writes: > The environment variables are mentioned in plfreetype.c. The relevant names > are largely self-documenting and are > > PLPLOT_FREETYPE_FONT_PATH (trailing slash required) > PLPLOT_NORMAL_FONT > PLPLOT_ROMAN_FONT > PLPLOT_ITALIC_FONT > PLPLOT_SCRIPT_FONT > PLPLOT_SYMBOL_FONT > ... > So I believe you could set PLPLOT_FREETYPE_FONT_PATH to > /usr/X11R6/lib/X11/fonts/ and then set the other names to TTF/Arial.ttf (or > whatever is appropriate for your system for normal, roman, italic, script, > and symbol fonts). Please let us know if that works for your situation. Actually the logic is bogus wrt this, the sense is reversed. I now have this working as expected under RH7.3 and am committing my fixes. Pretty cool stuff. -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
From: Maurice L. <mj...@ga...> - 2002-09-17 07:25:43
|
OK, to play with this under RH7.3, assuming you've got the png driver built and ttfonts-1.0-9.noarch.rpm installed: - copy the following script to ~/bin/pl_fontsetup - uncomment the line for FONT_TEST you want to see in action - run: source ~/bin/pl_fontsetup; ./x01c -dev png -drvopt text,smooth -o test.png; xv test.png (sh/bash syntax) The last set of variable def's below (commented out) are needed before my fixes to plfreetype.c. #!/bin/sh export PLPLOT_FREETYPE_FONT_PATH=/usr/share/fonts/default/TrueType/ #FONT_TEST=arib____.ttf #FONT_TEST=arir____.ttf #FONT_TEST=chvor___.ttf #FONT_TEST=chvr____.ttf #FONT_TEST=cogb____.ttf #FONT_TEST=cogr____.ttf #FONT_TEST=helb____.ttf #FONT_TEST=helbi___.ttf #FONT_TEST=helcb___.ttf #FONT_TEST=helcbi__.ttf #FONT_TEST=helci___.ttf #FONT_TEST=helcr___.ttf #FONT_TEST=heli____.ttf #FONT_TEST=helr____.ttf #FONT_TEST=starbats.ttf #FONT_TEST=starmath.ttf #FONT_TEST=timb____.ttf #FONT_TEST=timbi___.ttf #FONT_TEST=timi____.ttf #FONT_TEST=timr____.ttf export PLPLOT_NORMAL_FONT=$FONT_TEST export PLPLOT_ROMAN_FONT=$FONT_TEST export PLPLOT_ITALIC_FONT=$FONT_TEST export PLPLOT_SYMBOL_FONT=$FONT_TEST export PLPLOT_SCRIPT_FONT=$FONT_TEST #export PLPLOT_NORMAL_FONT=${PLPLOT_FREETYPE_FONT_PATH}$FONT_TEST #export PLPLOT_ROMAN_FONT=${PLPLOT_FREETYPE_FONT_PATH}$FONT_TEST #export PLPLOT_ITALIC_FONT=${PLPLOT_FREETYPE_FONT_PATH}$FONT_TEST #export PLPLOT_SYMBOL_FONT=${PLPLOT_FREETYPE_FONT_PATH}$FONT_TEST #export PLPLOT_SCRIPT_FONT=${PLPLOT_FREETYPE_FONT_PATH}$FONT_TEST -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
From: Maurice L. <mj...@ga...> - 2002-09-17 07:38:02
|
Maurice LeBrun writes: > #FONT_TEST=arib____.ttf > #FONT_TEST=arir____.ttf > #FONT_TEST=chvor___.ttf > #FONT_TEST=chvr____.ttf > #FONT_TEST=cogb____.ttf > #FONT_TEST=cogr____.ttf > #FONT_TEST=helb____.ttf > #FONT_TEST=helbi___.ttf > #FONT_TEST=helcb___.ttf > #FONT_TEST=helcbi__.ttf > #FONT_TEST=helci___.ttf > #FONT_TEST=helcr___.ttf > #FONT_TEST=heli____.ttf > #FONT_TEST=helr____.ttf > #FONT_TEST=starbats.ttf > #FONT_TEST=starmath.ttf > #FONT_TEST=timb____.ttf > #FONT_TEST=timbi___.ttf > #FONT_TEST=timi____.ttf > #FONT_TEST=timr____.ttf Here's the list with descriptions after I tried them all, sorry for any inaccuracies, I'm not a typographer. :) #FONT_TEST=arib____.ttf # bold script #FONT_TEST=arir____.ttf # roman script #FONT_TEST=chvor___.ttf # double-stroked #FONT_TEST=chvr____.ttf # bold roman #FONT_TEST=cogb____.ttf # bold sans serif small caps #FONT_TEST=cogr____.ttf # sans serif small caps #FONT_TEST=helb____.ttf # bold sans serif #FONT_TEST=helbi___.ttf # bold italic sans serif #FONT_TEST=helcb___.ttf # bold compact sans serif #FONT_TEST=helcbi__.ttf # bold compact italic sans serif #FONT_TEST=helci___.ttf # italic compact sans serif #FONT_TEST=helcr___.ttf # roman compact sans serif #FONT_TEST=heli____.ttf # italic sans serif #FONT_TEST=helr____.ttf # roman sans serif #FONT_TEST=starbats.ttf # bogus #FONT_TEST=starmath.ttf # bogus #FONT_TEST=timb____.ttf # roman bold #FONT_TEST=timbi___.ttf # italic bold #FONT_TEST=timi____.ttf # italic #FONT_TEST=timr____.ttf # roman I'm providing this info here since RH 7.3 will probably be a good "reference" system for at least the next year or so. -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
From: Alan W. I. <ir...@be...> - 2002-09-17 19:24:48
|
On Tue, 17 Sep 2002, Maurice LeBrun wrote: > Here's the list with descriptions after I tried them all, sorry for any > inaccuracies, I'm not a typographer. :) > > #FONT_TEST=arib____.ttf # bold script > #FONT_TEST=arir____.ttf # roman script > #FONT_TEST=chvor___.ttf # double-stroked > #FONT_TEST=chvr____.ttf # bold roman > #FONT_TEST=cogb____.ttf # bold sans serif small caps > #FONT_TEST=cogr____.ttf # sans serif small caps > #FONT_TEST=helb____.ttf # bold sans serif > #FONT_TEST=helbi___.ttf # bold italic sans serif > #FONT_TEST=helcb___.ttf # bold compact sans serif > #FONT_TEST=helcbi__.ttf # bold compact italic sans serif > #FONT_TEST=helci___.ttf # italic compact sans serif > #FONT_TEST=helcr___.ttf # roman compact sans serif > #FONT_TEST=heli____.ttf # italic sans serif > #FONT_TEST=helr____.ttf # roman sans serif > #FONT_TEST=starbats.ttf # bogus > #FONT_TEST=starmath.ttf # bogus > #FONT_TEST=timb____.ttf # roman bold > #FONT_TEST=timbi___.ttf # italic bold > #FONT_TEST=timi____.ttf # italic > #FONT_TEST=timr____.ttf # roman > > I'm providing this info here since RH 7.3 will probably be a good "reference" > system for at least the next year or so. Thanks, Maurice, for this additional information and for your changes to gd.c and plfreetype.c. Here are some additional comments/questions. (1) My apologies for not looking at the font logic more thoroughly. When I first tested this I just set up the defaults for my Debian system (first-tester perquisite, ;-)) and it worked immediately (much to my amazement since I know very little about freetype or fonts), and I never actually tried the environment variable approach. (2) Now that I have looked at the logic, I believe it needs changing some more. I think Joao's system may be typical; a "parent" path to get to the area where fonts occur with subdirectories/font files you would like to try. The current logic (once some additional bogus logic is fixed) says if there is a slash *anywhere* in the font file environment variable than treat it as a complete path plus file name and ignore the font path altogether. Instead, at least for the Unix side of things I would prefer to concatanate the font path and font name string *always* except for the one narrow exception where there is a *leading* slash on the font name. This way you can comfortably and flexibly deal with subdirectories in the font name, but if you really want to specify absolute path+font file name, you are allowed to do so. Does everybody here thinks this is a good idea for the Unix/Linux side of things? Andrew, would you chip in here with what you would like to do on the DJGPP/ MSDOS side of things? Also, Andrew, your code commentary suggested you could specify font names from the command line. Would you confirm that is no longer the case (which I think is a good thing since font names are so long)? Assuming we are in agreement on conditions for concatanation with the path (at least on the Unix/Linux side) the code commentary should be appropriately changed. Furthermore, I think the current Unix + DJGPP + MSDOS logic is still completely bogus since FT->font_name[i] doesn't have an assigned value when it is checked! So I would like to replace #ifdef DJGPP if ((strchr(FT->font_name[i],'/')) || (strchr(FT->font_name[i],'\\')) ) #elif MSDOS if (strchr(FT->font_name[i],'\\')) #else if (strchr(FT->font_name[i],'/')) #endif strcpy(FT->font_name[i],a); by #ifdef DJGPP if ((strchr(a,'/')) || (strchr(a,'\\')) ) #elif MSDOS if (strchr(a,'\\')) #else if (strchr(a,'/')!=NULL && *strchr(a==0) #endif strcpy(FT->font_name[i],a); Note, I am right at the bleeding edge of my C skills here about dealing with pointers for the if (strchr(a,'/')!=NULL && *strchr(a,'/')==0) statement so please correct that if wrong. The point is that test should succeed only if there is a leading "/" for the environment variable string, a. The only thing I have done to the DJGPP and MSDOS logic is replace the FT->font_name[i] which has not been assigned a value, yet with the environment variable string, a. (3) What is the Unix standard for file name length when you are potentially dealing with the complete path + file name? I am uncomfortable with the small (80-character) size of FT->font_name at the moment, and would like to change it to something much larger and preferably the standard if somebody could tell me what that is. (4) It is probably obvious to everybody at this point, but Maurice's script was just to test fonts. For production use, the various font-name variables would normally point to *different* fonts to define a mapping between the five PLplot font slots and any particular TrueType font you choose. Here is Andrew's code commentary on this as well as a comparison with what is currently done with ps.c. * Next we go through and fill out the FT->font_name entries with * values for the four possible "cfont" settings. The plplot documentation * defines these a little differently from the PS.C driver: * Font Plplot name ps.c name plfreetype ms-dos/unix * ---- ----------- --------- ----------------- * 1 normal "Times-Roman" arial * 2 roman "Times-Roman" times * 3 italic "Times-Italic" times-italic * 4 script "Helvetica" comic * 5 greek symbol * * Under plplot, the "normal" font is actually a sans-serifed font, while * ps.c defines it as times-roman, a serifed font. For the freetype * implementation I will define sans-serifed font, arial. Here is the list of truetype fonts on my Debian system. These were picked up automatically from the MS font site (before it shut down, although there is a replacement now at http://corefonts.sourceforge.net/) Andale_Mono.ttf Impact.ttf Arial.ttf Times_New_Roman.ttf Arial_Black.ttf Times_New_Roman_Bold.ttf Arial_Bold.ttf Times_New_Roman_Bold_Italic.ttf Arial_Bold_Italic.ttf Times_New_Roman_Italic.ttf Arial_Italic.ttf Trebuchet_MS.ttf Comic_Sans_MS.ttf Trebuchet_MS_Bold.ttf Comic_Sans_MS_Bold.ttf Trebuchet_MS_Bold_Italic.ttf Courier_New.ttf Trebuchet_MS_Italic.ttf Courier_New_Bold.ttf Verdana.ttf Courier_New_Bold_Italic.ttf Verdana_Bold.ttf Courier_New_Italic.ttf Verdana_Bold_Italic.ttf Georgia.ttf Verdana_Italic.ttf Georgia_Bold.ttf Webdings.ttf Georgia_Bold_Italic.ttf ms-fonts Georgia_Italic.ttf Some of those obviously have RH7.3 counterparts, but for some reason there doesn't seem to be a one-to-one mapping between the two. (I don't understand this since the source, the free MS core fonts, should presumably be the same in both cases.) For example, RH7.3 has Helvetica, but I don't, and I have some comic fonts, but RH 7.3 does not. Are they equivalent? I also notice that neither my system nor RH 7.3 have symbol fonts so that leaves the question of the best font to plug into the PLplot greek font slot. Any ideas? Maurice, I was glad to see your enthusiasm for the PLplot freetype interface to fonts. There are still some obvious problem areas that need to be worked out (e.g., the font selection code problems discussed above as well as the current inability to rotate the fonts (try the -ori 0.2 argument to get a spectacularly wrong-looking example). Nevertheless, I am equally enthusiastic about the potential of this code and would like to see its use spread from gd.c to other bitmap drivers. For instructions on how to make the appropriate driver changes, see http://plplot.sourceforge.net/resources/docbook-manual/plplotdoc-html-0.4.3/freetype-notes.html. Alan |
From: Maurice L. <mj...@ga...> - 2002-09-18 00:34:02
|
Alan W. Irwin writes: > (2) Now that I have looked at the logic, I believe it needs changing some > more. I think Joao's system may be typical; a "parent" path to get to the > area where fonts occur with subdirectories/font files you would like to try. > The current logic (once some additional bogus logic is fixed) says if there > is a slash *anywhere* in the font file environment variable than treat it as > a complete path plus file name and ignore the font path altogether. Instead, > at least for the Unix side of things I would prefer to concatanate the font > path and font name string *always* except for the one narrow exception where > there is a *leading* slash on the font name. This way you can comfortably > and flexibly deal with subdirectories in the font name, but if you really > want to specify absolute path+font file name, you are allowed to do so. Agreed. I vaguely noted that the current solution wasn't optimal, but like you was trying to just get it working so I could play with it. Having access to an alternate font rendering engine is really nice, and is helping me debug something I've been wanting to add for a long time -- storing strings as strings in the metafile. Then in principle you can do all kinds of cool things with them in the renderer. > Note, I am right at the bleeding edge of my C skills here about dealing > with pointers for the > > if (strchr(a,'/')!=NULL && *strchr(a,'/')==0) > > statement so please correct that if wrong. The point is that test should > succeed only if there is a leading "/" for the environment variable string, > a. The only thing I have done to the DJGPP and MSDOS logic is replace the > FT->font_name[i] which has not been assigned a value, yet with the > environment variable string, a. The second test won't ever succeed since the pointer value can't be zero. But you could do pointer arithmetic: if ( strchr(a,'/') && ( (strchr(a,'/') - a) == 0 ) ) (subtracting pointers is safe). Also note it's good style (arguable but most agree) to omit the test against NULL in the first expression. But even simpler would be: if (a[0] == '/') :) > (3) What is the Unix standard for file name length when you are potentially > dealing with the complete path + file name? I am uncomfortable with the > small (80-character) size of FT->font_name at the moment, and would like to > change it to something much larger and preferably the standard if somebody > could tell me what that is. 80 chars is way too short. A limit like 1024 chars is much more appropriate. -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
From: Alan W. I. <ir...@be...> - 2002-09-18 19:28:59
|
On Tue, 17 Sep 2002, Maurice LeBrun wrote: > But even simpler would be: > > if (a[0] == '/') > > :) That's too easy; C is supposed to be hard....;-) Andrew has already made this change (plus looking for "~" at the head of the string which I think is a good idea as well). > 80 chars is way too short. A limit like 1024 chars is much more appropriate. Done. Alan |
From: Andrew R. <aro...@ya...> - 2002-09-18 05:33:56
|
At 12:24 PM 17/09/02 -0700, Alan W. Irwin wrote: >(2) Now that I have looked at the logic, I believe it needs changing some >more. I think Joao's system may be typical; a "parent" path to get to the >area where fonts occur with subdirectories/font files you would like to try. >The current logic (once some additional bogus logic is fixed) says if there >is a slash *anywhere* in the font file environment variable than treat it as >a complete path plus file name and ignore the font path altogether. Instead, >at least for the Unix side of things I would prefer to concatanate the font >path and font name string *always* except for the one narrow exception where >there is a *leading* slash on the font name. This way you can comfortably >and flexibly deal with subdirectories in the font name, but if you really >want to specify absolute path+font file name, you are allowed to do so. > >Does everybody here thinks this is a good idea for the Unix/Linux side of >things? Andrew, would you chip in here with what you would like to do on the >DJGPP/ MSDOS side of things? The combination of enviro-variables, and concatenation of paths and file names, together with the logic of deciding if you had an absolute path or not, was just *really* quick coding to get it "out the door" and into testing - I always envisaged that it would change once people started experimenting with it. I was more surprised than Alan when the original code worked first go, considering I wrote it in a total unix-vacuum ! The way I originally saw things *ultimately* heading, and it can still be subject to change/debate, was to have the font path "searchable", so multiple directories could be specified with the standard path separator, whatever that might be. For example, under DOS it's ';', so the path searched for include files on my machine looks like: /;CPLUS_INCLUDE_PATH%%DJDIR%/lang/cxx;%DJDIR%/include;%GRX20%/include;%PLPLO T_HOME%/include;%FREETYPE_INC% Is it ':' in unix ? >Also, Andrew, your code commentary suggested >you could specify font names from the command line. Would you confirm >that is no longer the case (which I think is a good thing since font names >are so long)? It would make life a lot easier, which is why I didn't do it originally, and had not gotten around to doing it yet. I just thought it might be a little quicker/easier for the end-user for making changes to the fonts than messing around with the environmental variables all the time. I have no attachment to it, so wont miss it if it goes. >Some of those obviously have RH7.3 counterparts, but for some reason there >doesn't seem to be a one-to-one mapping between the two. (I don't >understand this since the source, the free MS core fonts, should presumably >be the same in both cases.) For example, RH7.3 has Helvetica, but I don't, >and I have some comic fonts, but RH 7.3 does not. Are they equivalent? I >also notice that neither my system nor RH 7.3 have symbol fonts so that >leaves the question of the best font to plug into the PLplot greek font >slot. Any ideas? It's very unfortunate that micro$oft took their core fonts of the web, and even more disappointing that there isn't a standard symbol font on linux. But don't forget, freetype reads a lot more than just truetype fonts - it also does type1, type42 etc... and I think a free type1 symbol font is included by adobe in acrobat, so that might be a potential source perhaps ? >Maurice, I was glad to see your enthusiasm for the PLplot freetype interface >to fonts. There are still some obvious problem areas that need to be worked >out (e.g., the font selection code problems discussed above as well as the >current inability to rotate the fonts (try the -ori 0.2 argument to get a >spectacularly wrong-looking example). Nevertheless, I am equally >enthusiastic about the potential of this code and would like to see its use >spread from gd.c to other bitmap drivers. For instructions on how to make >the appropriate driver changes, see >http://plplot.sourceforge.net/resources/docbook-manual/plplotdoc-html-0.4.3 /freetype-notes.html. Just a real brief comment here so as to encourage people adding freetype support. Some of the current problems with the GD driver appeared as a result of the palette manipulations to get the anti-aliased freetype fonts working. If you could "make do" with non-anti-aliased freetype fonts, adding freetype support to drivers is *much* simpler, if not trivial. -Andrew |
From: Alan W. I. <ir...@be...> - 2002-09-18 17:37:41
|
On Wed, 18 Sep 2002, Andrew Roach wrote: > The way I originally saw things *ultimately* heading, and it can still be > subject to change/debate, was to have the font path "searchable" , so > multiple directories could be specified with the standard path separator[..] > Is it ':' in unix ? I think that is an excellent idea so please just go ahead. In Unix/Linux it is standard to have colon-separated paths. Meanwhile, I have good news: your overnight (for me) change to gd.c solved the colour problem completely. Also, I have just made a subsequent change so the path+fontfile name can be 1024 characters as Maurice suggested. So the only outstanding issue I am aware of is -ori 0.1 (say) works fine for the Hershey fonts, but does not work for freetype, yet. > [...]It's very unfortunate that micro$oft took their core fonts of the web[...] It does seem to be a somewhat poorly thought-out move by MS. It hurts their users, and at the same time doesn't hurt Linux very much at all. The fonts were licensed in such a way that anybody could redistribute them freely in unchanged form so there is at least one project at http://corefonts.sourceforge.net/ that is doing exactly that. I suppose there is a bit of a transition pain for Linux MS font packages to move from using the MS web server to the new corefonts site, but such package updates can be done pretty automatically for most distributions. > [...] > even more disappointing that there isn't a standard symbol font on linux. > But don't forget, freetype reads a lot more than just truetype fonts - it > also does type1, type42 etc... and I think a free type1 symbol font is > included by adobe in acrobat, so that might be a potential source perhaps ? No question that fonts on Linux currently have few standards for paths or file names. Nevertheless, suitable fonts are available on Linux; it is just a matter of finding them. From http://freetype.sourceforge.net/freetype2/index.html freetype apparently supports the following font formats: TrueType fonts (and collections) Type 1 fonts CID-keyed Type 1 fonts CFF fonts OpenType fonts (both TrueType and CFF variants) SFNT-based bitmap fonts X11 PCF fonts Windows FNT fonts BDF fonts (including anti-aliased ones) PFR fonts Type42 fonts (limited support) I had never heard of "X11 PCF" before, but from http://pfaedit.sourceforge.net/pcf-format.html we have the following definition: "The pcf (portable compiled format) file format is a binary representation of a bitmap font used by the XServer." So I think that means freetype has access to *all* bitmap X fonts. For example my /usr/X11R6/lib/X11/fonts/100dpi/ directory is filled with pcf files including what looks like symbol files. So I forsee lots of interesting PLplot experimentation with trying out an enormous variety of fonts going far beyond just the truetype fonts. Thanks, Andrew, for making this all possible. Alan |
From: Alan W. I. <ir...@be...> - 2002-09-16 19:26:51
|
On Mon, 16 Sep 2002, [iso-8859-1] Jo=E3o Cardoso wrote: > Plplot library version: 5.1.0 > plLoadDriver: Device not loaded! > plLoadDriver: tag=3Dpng, drvidx=3D4 > plLoadDriver: Trying to load gdd_drv.so on ./drivers/gdd_drv.so > plLoadDriver: Local dlopen failed because of the following reason: > ./drivers/gdd_drv.so: undefined symbol: gdImagePalettePixel I am so glad to see this error message finally deliver something meaningful= ! > [jcard@feup] rpm -q gd > gd-1.8.4-238 > > And gdImagePalettePixel() does not exists in the gd library. I have investigated further, and it is an undocumented but small macro in version 2.0.1 of libgd which I presume is not in 1.8.4 since Joao's compiler didn't find it. #define gdImagePalettePixel(im, x, y) (im)->pixels[(y)][(x)] Andrew, I am not sufficiently familiar with libgd to know whether this macr= o would work for version 1.84. If you know it would work, we could put this macro definition into gd.c. Alternatively, we could just drop plD_gd_optimise with #ifdefine if the GD version is not greater than 2. Please make whichever change you feel is appropriate. Alan |