Hi Steve: Thanks for your tests of revision 8854.
On 2008-10-05 13:14+0100 Steve Schwartz wrote: > I've been experimenting with the svg driver (using svn 8854). Here are > some observations: > > inkscape will now open the svg generated from x01c, though all the > labels and text show up displaced to the left. But it renders fine in > firefox, konqueror, and virtually everything I've tried > > scribus (v 1.3.3.4) will also open up, but makes a mess of it. This is a > pity, because I'm a big fan of this software, and I may send the svg to > them to see if they have any comments or improvements. > > karbon14 will open it up and it looks pretty good, EXCEPT that the > superscripted text is not superscripted nor sized smaller. But it is > less temperamental than inkscape > > I've looked at a few other svg editors (sketsa, sodipodi, ...) but none > look to be advancing to the point where they are practical. Any other > suggestions would be welcome. I think you have probably looked at everything suggested in http://www.linux.com/feature/148630 and in the comments to that article, but you should double-check that. One of the observations of that review (that the various Linux svg editors didn't even understand each other's brand of svg) means one of two things. (1) Some of them are outputting bad svg. I hope that is not the case since that is so easy to check at http://validator.w3.org. BTW, when you send in bug reports to the svg editor developers, I suggest that you check the PLplot results against http://validator.w3.org using their file upload mechanism and mention that in your bug report. I think that will get a lot more attention for your bug report than saying something equivalent to "your application cannot interpret PLplot svg output". (2) The various svg editors have only implemented a subset (the same subset they output) of the full svg standard for input. IMO, this latter explanation is more likely from your above observations with how the various editors mess up the svg standards-compliant example 1 result. One ray of hope in this mess is the inkscape problems you describe sound awful familiar. That is how all librsvg-based svg viewers (such as the "display" application from ImageMagick) qualitatively mess up as well. I suggest you try "display" on example 1 svg results, and if it is giving you the identical rendering errors as inkscape, then it probably means inkscape is also using librsvg which in turn means we can potentially knock off a lot of these application issues by bringing the problem to the attention of the librsvg developers. Also, I should mention that whenever I tried "display" on any of our examples, the only rendering issue that showed up was the left-displacement one that is illustrated by the example 1 results. So we are probably only dealing with one bug in librsvg as opposed to many. The other ray of hope is Linux application developers are just now becoming svg aware after years of neglecting the standard. (PLplot is a case in point, but KDE is an even larger one where they have migrated all their desktop icons to svg recently [KDE4] for the first time.) The existence of many additional kinds of svg standards-compliant output from ever-increasing varieties of Linux applications is bound to put pressure on svg editors to get their act together to implement the full svg standard for input. What to do in the meanwhile? (1) Identify the svg editor you like for other reasons (from above, it sounds like that would be scribus) and focus on that one. Insist through your bug reports that they fix their import module sufficiently so that at least the standards-compliant figure 1 svg result (and eventually all the svg results from the PLplot standard examples) are imported and interpreted exactly as they are rendered by firefox. (2) I was going to suggest you try -dev svgcairo, but it appears the various editors have a different set of difficulties with that device according to your later e-mail which I will answer separately. > > Also, I'm still having difficulty printing a postscript plot on a page; > it looks fine in ghostscript (with the view set to A4 or Letter paper), > but prints to a ps printer blown up by a factor ~4.8. Passing through > eps2eps, epstopdf, or any other filter generates a file that prints fine > on a page, but I'd be interested in how others print plplot postscript > plots. I work from a home office with no printer so I haven't tested any of our PostScript devices in a long time by actually attempting to print the result. Which PostScript devices have you tested? The choices are ps, psttf, and pscairo. 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
