From: <hba...@ma...> - 2006-11-12 18:13:19
|
Hello, I've added a SVG driver to PLplot (http://www.w3.org/Graphics/SVG/). SVG (Scalable Vector Graphics) is a XML graphical language that is supported natively or as a plug in most modern browsers. In theory it is anti-aliased and uses truetype fonts, but the reality will depend on the capabilities of your SVG renderer. Since this driver is still a bit rough, primarily with regard to text placement, it is off by default. If you choose to play with it, you should be aware of the following issues: (1) The S in SVG might also stand for "Simple". If the plot is at all complicated then you might find rendering to be painfully slow. I'd recommend starting with example 3 before jumping to something complicated like example 8. I'm not sure exactly why it is so slow. The generated files are similar in size to their postscript equivalents. Perhaps this is due to the fact that, at least in a browser, a DOM tree is being constructed during rendering so that you can manipulate every element with javascript? (2) As mentioned above, vertical text placement still leaves something to be desired. I think this is because SVG is scanning each text element and deciding based on the glyphs in that element what the baseline of the element should be. You can see this in example2 where the numbers are all centered slightly differently in their boxes. It would be preferable from our point of view if it always used the same baseline for a particular font. (3) On OS-X in Firefox and Camino the font-family "serif" comes out looking like the font-style "italic". I'm pretty puzzled by that one. Anyway, thanks to our CBS I was delighted to find that I only had to add one line to each of two files to build PLplot with this driver. -Hazen |
From: Alan W. I. <ir...@be...> - 2006-11-13 02:45:15
|
On 2006-11-12 13:11-0500 hba...@ma... wrote: > > Hello, > > I've added a SVG driver to PLplot [...]. I am glad you have made this promising start for -dev svg since SVG is an important web standard. This device builds fine on my Linux box (as a dynamic device). This is a very pleasant change from the old days when usually the person who made the new device needed help with the ABS configuration. CMake comes through again for us! > If you choose to play with it, you should be aware of the following > issues: > (1) If the plot is at all > complicated then you might find rendering to be painfully slow. [...] I confirm that on my 2.4GHz Linux box. It takes about 1 second to render example 1 (which is not too bad) and about 20 seconds (moderately bad) to render the first page of example 8 using the "display" application that is part of the suite of applications that come with the ImageMagick software package. OTOH, the antialiased plotting lines look outstanding. I recall that our other device driver with antialiased plotting lines on Linux, wxwidgets, used to be slow. However, some changes Werner did greatly speeded it up (try c/x08c -dev wxwidgets -drvopt smooth=1,text=1 to see these nice-looking results which are rendered in about a second per page on my box). Also, you might want to look at your area-fill functionality (which is used a lot for example 8). Area fills are not particularly well suited for vector operations so some optimization care may be needed for your area fills for this vector device. > (2) As mentioned above, vertical text placement still leaves > something to be desired. I think this is because SVG is scanning each > text element and deciding based on the glyphs in that element what > the baseline of the element should be. You can see this in example2 > where the numbers are all centered slightly differently in their > boxes. It would be preferable from our point of view if it always > used the same baseline for a particular font. We ran into this same issue for the gd family of devices, and it isn't completely straightened out yet. As I recall this was due to a difference between character origins between PLplot and various fonts. The PLplot character origin used for rendering is assumed to be right in the middle of the character while fonts use a variety of different origins. You need to transform between the two origins, and that transformation obviously depends on the size of the character, and the font origin. Other issues I noticed were the horizontal placement of exponents in example 1 and something screwball with the 3D transformation of the axis labels in example 8. Also, I could not get the -fam option to work so all I saw from example 8 was the first page. (The PLplot familying option generates a separate file for each page. Familying is well implemented for the gd-related devices if you want a template of how to do it. See also, http://plplot.sourceforge.net/docbook-manual/plplot-html-5.6.1/output-devices.html#familying OTOH, if the SVG standard allows multiple pages per file, then you should implement that standard and avoid familying.) Finally, I used the http://jiggles.w3.org/svgvalidator/ValidatorUpload.html SVG validator, and it reported a minor validation issue with the constant version number you have specified. This issue disappears if you remove the version="1.1" line from the <svg> element > Anyway, thanks to our CBS I was delighted to find that I only had to > add one line to each of two files to build PLplot with this driver. Hearing that makes me happy... :-) 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 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: <hba...@ma...> - 2006-11-14 06:23:01
|
On Nov 12, 2006, at 9:45 PM, Alan W. Irwin wrote: >> If you choose to play with it, you should be aware of the following >> issues: >> (1) If the plot is at all >> complicated then you might find rendering to be painfully slow. [...] > > I confirm that on my 2.4GHz Linux box. It takes about 1 second to > render > example 1 (which is not too bad) and about 20 seconds (moderately > bad) to > render the first page of example 8 using the "display" application > that is > part of the suite of applications that come with the ImageMagick > software > package. OTOH, the antialiased plotting lines look outstanding. I > recall > that our other device driver with antialiased plotting lines on Linux, > wxwidgets, used to be slow. However, some changes Werner did greatly I tried different anti-aliasing settings but they did not seem to make much difference to me (using the Firefox browser to display the plots). I believe the SVG specification says that these settings are only recommendations which the display program is free to ignore. > Other issues I noticed were the horizontal placement of exponents > in example > 1 and something screwball with the 3D transformation of the axis > labels in The exponents are too high? That is pretty easy to fix since I had to specify their relative placement. I'll have a look at the labels in example 8. I admit that I was not brave enough / patient enough to actually see how that example rendered. > example 8. Also, I could not get the -fam option to work so all I > saw from > example 8 was the first page. (The PLplot familying option > generates a > separate file for each page. Familying is well implemented for the > gd-related devices if you want a template of how to do it. See also, > http://plplot.sourceforge.net/docbook-manual/plplot-html-5.6.1/ > output-devices.html#familying > OTOH, if the SVG standard allows multiple pages per file, then you > should > implement that standard and avoid familying.) The generated svg file actually contains all of the graphs. If you open it you should see: <document> <svg ..> .. graph1 .. </svg> <svg> .. graph2 .. </svg> ... </document> And I see all the pages in Firefox, though some of the later pages are not displayed accurately. For example, the second page in example 2 only has the boxes and no text, even though the XML is there for the text. I'm not really sure what the correct tags are for multi- page svg documents, but I think that svg is typically used only for single page documents anyway. > Finally, I used the http://jiggles.w3.org/svgvalidator/ > ValidatorUpload.html > SVG validator, and it reported a minor validation > issue with the constant version number you have specified. This issue > disappears if you remove the > > version="1.1" Interesting. I copied that right out of an example on the specification website. -Hazen |
From: Andrew R. <aro...@ya...> - 2006-11-13 04:01:37
|
At 01:11 PM 12/11/2006 -0500, you wrote: >I've added a SVG driver to PLplot (http://www.w3.org/Graphics/SVG/). >SVG (Scalable Vector Graphics) Well done ! This was something that I was always going to do eventually,=20 but sadly never got around to=85 so happy to hear you did. >The generated files are similar in size to their postscript equivalents. I've only had a superficial look at it, and don't have the time for a=20 couple of days to look properly, but it seems like you are saving as an=20 uncompressed SVG stream. If you are compressing them, then ignore what I am= =20 about to say=85 As the libz library is usually present for the png driver,= if=20 you were not using compressed SVG files, it should be quite trivial to=20 support to a libz compressed SVG stream. They compress very well indeed. -Andrew |
From: Alan W. I. <ir...@be...> - 2006-11-13 05:27:36
|
On 2006-11-12 18:45-0800 Alan W. Irwin wrote: > [...]Also, you might want to look at your area-fill functionality > (which is used a lot for example 8). Area fills are not particularly well > suited for vector operations so some optimization care may be needed for > your area fills for this vector device. This probably isn't the reason why the rendering of example 8 is so much slower than example 1. I took a quick look at the code and the difference between unfilled and filled is apparently only a matter of setting the fill color. Thus, I guess the renderer is expected to do the filling with its own algorithm, and the svg.c device driver simply specifies the polygons that need to be filled by the renderer application. So I presume svg.c has no control over the efficiency of the renderer area filling algorithm unless the number of points describing the polygons are much higher than they really need to be. 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 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: Werner S. <sm...@ia...> - 2006-11-27 21:05:10
|
Hi Hazen, I tried to turn off the svg driver here in Windows with -DPLD_svg=ON. Cmake lists the drivers, it gets compiled, but doesn't show up in the driver list in the examples. Any ideas? Werner hba...@ma... wrote: > Hello, > > I've added a SVG driver to PLplot (http://www.w3.org/Graphics/SVG/). > SVG (Scalable Vector Graphics) is a XML graphical language that is > supported natively or as a plug in most modern browsers. In theory it > is anti-aliased and uses truetype fonts, but the reality will depend > on the capabilities of your SVG renderer. Since this driver is still > a bit rough, primarily with regard to text placement, it is off by > default. > > If you choose to play with it, you should be aware of the following > issues: > (1) The S in SVG might also stand for "Simple". If the plot is at all > complicated then you might find rendering to be painfully slow. I'd > recommend starting with example 3 before jumping to something > complicated like example 8. I'm not sure exactly why it is so slow. > The generated files are similar in size to their postscript > equivalents. Perhaps this is due to the fact that, at least in a > browser, a DOM tree is being constructed during rendering so that you > can manipulate every element with javascript? > > (2) As mentioned above, vertical text placement still leaves > something to be desired. I think this is because SVG is scanning each > text element and deciding based on the glyphs in that element what > the baseline of the element should be. You can see this in example2 > where the numbers are all centered slightly differently in their > boxes. It would be preferable from our point of view if it always > used the same baseline for a particular font. > > (3) On OS-X in Firefox and Camino the font-family "serif" comes out > looking like the font-style "italic". I'm pretty puzzled by that one. > > Anyway, thanks to our CBS I was delighted to find that I only had to > add one line to each of two files to build PLplot with this driver. > > -Hazen > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel -- Dipl. Ing. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Hazen B. <hba...@ma...> - 2006-11-28 03:24:54
|
On Nov 27, 2006, at 4:04 PM, Werner Smekal wrote: > Hi Hazen, > > I tried to turn off the svg driver here in Windows with - > DPLD_svg=ON. Cmake lists the drivers, it gets compiled, but doesn't > show up in the driver list in the examples. > > Any ideas? That is a bit puzzling. I used ccmake to enable the svg driver rather than the command line switch, but I don't think that that should make any difference. It doesn't have any dependencies so you can't be missing anything. Did you notice whether it got compiled at the make stage? -Hazen |
From: Werner S. <sm...@ia...> - 2006-11-28 12:50:45
|
Hi Hazen, I found out what the problem was. Together with the old information README.drivers and where I found "wxwidgets" in the plplot code I made changes to include files and the svg driver works now for the ENABLE_DYNDRIVER off case. Please check if the changes are appropriate. I also made some notes about all the changes needed for new drivers - we should update the README.drivers file: * add to cmake/modules/drivers-init.cmake "svg:svg:OFF" * add to config.h.cmake #cmakedefine PLD_svg * add to include/drivers.h void plD_dispatch_init_svg ( PLDispatchTable *pdt ); * add to include/plDevs.h.cmake #cmakedefine PLD_svg * add to include/plcore.h #if defined(PLD_svg) && !defined(ENABLE_DYNDRIVERS) plD_dispatch_init_svg, #endif The driver works fine in Windows environment with very good results! Good job! Regards, Werner Hazen Babcock wrote: > On Nov 27, 2006, at 4:04 PM, Werner Smekal wrote: > >> Hi Hazen, >> >> I tried to turn off the svg driver here in Windows with - >> DPLD_svg=ON. Cmake lists the drivers, it gets compiled, but doesn't >> show up in the driver list in the examples. >> >> Any ideas? > > That is a bit puzzling. I used ccmake to enable the svg driver rather > than the command line switch, but I don't think that that should make > any difference. It doesn't have any dependencies so you can't be > missing anything. Did you notice whether it got compiled at the make > stage? > > -Hazen > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel -- Dipl. Ing. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Alan W. I. <ir...@be...> - 2006-11-28 07:11:59
|
On 2006-11-27 22:23-0500 Hazen Babcock wrote: > > On Nov 27, 2006, at 4:04 PM, Werner Smekal wrote: > >> Hi Hazen, >> >> I tried to turn off the svg driver here in Windows with - >> DPLD_svg=ON. Cmake lists the drivers, it gets compiled, but doesn't >> show up in the driver list in the examples. >> >> Any ideas? > > That is a bit puzzling. I used ccmake to enable the svg driver rather > than the command line switch, but I don't think that that should make > any difference. It doesn't have any dependencies so you can't be > missing anything. Did you notice whether it got compiled at the make > stage? While investigating this I have found an error on Linux with svg.c which might not be related, but which should still be fixed first so I can investigate Werner's issue more closely. It struck me that Werner tests on windows where ENABLE_DYNDRIVERS must be set to OFF so I tried that on Debian stable.... cmake -DCMAKE_INSTALL_PREFIX=/home/software/plplot_cvs/installcmake -DCMAKE_VERBOSE_MAKEFILE=ON -DENABLE_java=OFF -DENABLE_DYNDRIVERS=OFF -DPLD_svg=ON ../plplot_cmake All seemed well. I then built with that configuration, and svg.o was built, but an error showed up when linking libplplotd.so.9.2.1 (which necessarily for this case [ENABLE_DYNDRIVERS=OFF] includes all the code for all the device drivers). (note the following is a poorly wrapped error message from a very long linking command for libplplotd.so.9.2.1, but you should get the idea) CMakeFiles/plplotd.dir/home/software/plplot_cvs/HEAD/plplot_cmake/drivers/svg.o( .text+0x7a3): In function proc_str': : multiple definition of proc_str' CMakeFiles/plplotd.dir/home/software/plplot_cvs/HEAD/plplot_cmake/drivers/gcw.o( .text+0x1940): first defined here /usr/bin/ld: Warning: size of symbol proc_str' changed from 2592 in CMakeFiles/ plplotd.dir/home/software/plplot_cvs/HEAD/plplot_cmake/drivers/gcw.o to 1552 in CMakeFiles/plplotd.dir/home/software/plplot_cvs/HEAD/plplot_cmake/drivers/svg.o So gcw.c and svg.c have a name clash that affects the case when gcw.o and svg.o are in the same library. Hazen, can you fix this name clash? I doubt this error will affect either you or Werner since I don't think either of your platforms are currently capable of building -dev gcw (tons of library dependencies), but once this issue is fixed on Linux, I can at least look further to see whether I get the same symptoms as Werner for the ENABLE_DYNDRIVERS=OFF case. Thanks in advance. 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 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...> - 2006-11-28 20:13:32
|
On 2006-11-28 13:50+0100 Werner Smekal wrote: > Hi Hazen, > > I found out what the problem was. Together with the old information > README.drivers and where I found "wxwidgets" in the plplot code I made > changes to include files and the svg driver works now for the > ENABLE_DYNDRIVER off case. Please check if the changes are appropriate. Thanks, Werner, for your efforts. However, they did not fix the name clash I discovered with the gcw device driver. Here is the result for CVS HEAD now. CMakeFiles/plplotd.dir/home/software/plplot_cvs/HEAD/plplot_cmake/drivers/svg.o( .text+0x7a3): In function proc_str': : multiple definition of proc_str' CMakeFiles/plplotd.dir/home/software/plplot_cvs/HEAD/plplot_cmake/drivers/gcw.o( .text+0x1940): first defined here /usr/bin/ld: Warning: size of symbol proc_str' changed from 2592 in CMakeFiles/ plplotd.dir/home/software/plplot_cvs/HEAD/plplot_cmake/drivers/gcw.o to 1552 in CMakeFiles/plplotd.dir/home/software/plplot_cvs/HEAD/plplot_cmake/drivers/svg.o collect2: ld returned 1 exit status make[2]: *** [src/libplplotd.so.9.2.1] Error 1 make[2]: Leaving directory /home/software/plplot_cvs/HEAD/build_dir' make[1]: *** [src/CMakeFiles/plplotd.dir/all] Error 2 make[1]: Leaving directory /home/software/plplot_cvs/HEAD/build_dir' make: *** [all] Error 2 Only svg and gcw clash this way; if I disable one of them all seems to be well. If you look at all the device drivers (not just gcw.c and svg.c) it turns out that proc_str is a common name for a function that is defined differently in each of them. Some device drivers declare proc_str static some do not, and there are other stylistic variations as well. My understanding of C scope is not up to this challenge. Thus, will some C expert here step forward to straighten out these style differences amongst the various device drivers so it is easier to tell what is going on with proc_str? Ideally, this would be a developer with access to a fully loaded Linux box that can build both the svg and gcw device drivers so they can confirm the above error and fix it, but if Hazen or Werner (neither of whom may have access to fully loaded Linux boxes) feel the gcw/svg fix is obvious, please go ahead, and I would be happy to make further tests to see if your fix works. 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 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: Hazen B. <hba...@ma...> - 2006-11-29 03:43:20
|
On Nov 28, 2006, at 3:12 PM, Alan W. Irwin wrote: > > Only svg and gcw clash this way; if I disable one of them all seems > to be > well. > > If you look at all the device drivers (not just gcw.c and svg.c) it > turns > out that proc_str is a common name for a function that is defined > differently in each of them. Some device drivers declare proc_str > static > some do not, and there are other stylistic variations as well. I was able to create the same clash between the aqt driver and svg driver. Thus I believe that the problem is due to the fact that proc_str needs to be "static" in all of these drivers. I've committed this change to the aqt, svg and the gcw drivers. This removed the problem with aqt/svg on OS-X with ENABLE_DYNDRIVER off. Hopefully this will prove out on Linux as well. -Hazen |
From: Alan W. I. <ir...@be...> - 2006-11-29 06:38:27
|
On 2006-11-28 22:41-0500 Hazen Babcock wrote: > > On Nov 28, 2006, at 3:12 PM, Alan W. Irwin wrote: >> >> Only svg and gcw clash this way; if I disable one of them all seems >> to be >> well. >> >> If you look at all the device drivers (not just gcw.c and svg.c) it >> turns >> out that proc_str is a common name for a function that is defined >> differently in each of them. Some device drivers declare proc_str >> static >> some do not, and there are other stylistic variations as well. > > I was able to create the same clash between the aqt driver and svg > driver. Thus I believe that the problem is due to the fact that > proc_str needs to be "static" in all of these drivers. I've committed > this change to the aqt, svg and the gcw drivers. This removed the > problem with aqt/svg on OS-X with ENABLE_DYNDRIVER off. Hopefully > this will prove out on Linux as well. Yes it does. svg/gcw clash problem solved on Linux. Thanks for the quick action. 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 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 __________________________ |