From: Alan W. I. <ir...@be...> - 2008-09-30 05:39:32
|
I would like to use SVG format to produce a PLplot logo, but the svgcairo device (in fact all cairo devices because this appears to be a libcairo issue or libcairo backend issue) have some issues with antialiasing of filled surfaces that produce some ugly looking artifacts on those surfaces, in e.g., example 8 results. So until those libcairo issues are fixed, svgcairo is ruled out for producing an SVG logo and the svg device driver is the alternative I am currently looking at. Motivated by my desire to make an SVG logo for PLplot and also motivated by the general idea that SVG is a really nice format for us, I (with some help from Hazen) have been fixing the "easy" issues for -dev svg including implementing alpha channel transparency, making the results validate at http://validator.w3.org/, implementing familying, applying a scaling factor to coordinates (which improved both the internal PLplot calculational accuracy for this device used in determining line-hiding for example 18, and also greatly improved the smoothness of the displayed results), and adjusting the vertical text placement. I am now done with these "easy" fixes so I wanted to discover any remaining issues for -dev svg by looking at the ctest -R 'svg$' results (more than 120 different pages) from our 30 standard examples. It turns out you have to be careful of the svg viewer you use for such evaluations. For example, the imagemagick display application has x origin problems for svg text. "display" renders svg by using the librsvg library. I found the librsvg stand-alone viewer called rsvg-view also has exactly the same bug (as expected) so I intend to send in a bug-report about it to kill two birds with one stone. In general, the firefox and konqueror browsers handle svg text positions properly, but one issue to watch out for with them (see below) is how they handle exotic glyphs. I used firefox to evaluate all the standard example pages, and followed up with the svgviewer application (the standalone equivalent of konqueror's method of viewing SVG results) when there was any issue visible and sometimes also with "display" for exotic font issues (see below). In general, our svg results look really good with firefox, and I believe -dev svg produces everything I need to generate a good-looking SVG PLplot logo using PLplot itself, but there are still some outstanding issues that I noticed when looking at the complete set of examples. I mark the ones listed below that I am investigating further using "(AWI)". The one that is caused by an issue in another library is marked by "(Nobody)". Finally, the ones marked "(*)" are too difficult for me so they are up for grabs for some eager volunteer to show off his device driver skills. :-) (*) Example 3: the text does not rotate accurately around this polar plot. For example, the center of the text rotation seems offset from the center of the plot. The first page of Example 28 also appears to show this problem. I assume these issues are caused by some text offset issue that has not been taken care of properly in the svg device driver when doing rotational transformations of text. (AWI) Example 6: some of the horizontal rules are missing. Strangely, the seemingly equivalent horizontal rules in Example 7 are fine. (*) Examples 9 and 21: clipping not implemented yet as illustrated by the first page of these examples. (*) Example 10 (and presumably others) Text does not rotate at all with the -ori option. (You have to run the installed examples to check out the results from that option.) Again, this is some sort of rotation/transformation issue, but it looks like at least in this case the rotational information doesn't get to the text at all. This may well be related to the example 3 issue above. (*) Example 15: cross-hatching not implemented yet as illustrated by both pages. (AWI) Example 20: empty pages 2,5,7,and 10 have an xml screwup that is probably related to the familying logic. (AWI) Example 21: first four figures (out of 6 on the second page) display and then get blanked. The last two figures on the page display and do not get blanked. The third page of this example (and also example 1) seem to have a similar setup (multiple subpages per page), but no such issues. (AWI) Example 23: pages 12-16 have an xml screwup (at least </g> and </svg> are missing at end of file) that is probably related to the familying logic. (Nobody) Example 24: exotic font handling for firefox and konqueror are not nearly as sophisticated as the fontconfig font handling that is used by libcairo. The result is the exotic glyphs of this example are not found (even though installed on the system). Interestingly, despite the X origin problems of the ImageMagick "display" application, it renders all the CTL language glyphs in our Peace flag properly. That's quite a relief since it means our approach of not worrying about any CTL issues and letting the subsequent viewer application worry about it is correct. I assume librsvg (and therefore "display") does all the CTL stuff right by interrogating the font for the information that it needs. Konqueror and firefox may well do the same, but we won't know about that until they start having more sophisticated font handling so that exotic glyphs can be found. I intend to put in a bug report about that issue for both of them. In sum, the current svg device logic already produces superb-looking results for the vast majority of our examples, and I think those superb results will be generated for the logo that I have in mind as well. However, there are a number of minor general issues I am still working on. Also, there is a text rotation bug that needs to be addressed, and clipping and cross-hatching still have to be implemented. If somebody will tackle those three issues, we will end up with an SVG device that produces superb-looking results for all circumstances. 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 __________________________ |
From: Steve S. <s.s...@im...> - 2008-09-30 09:06:16
|
If I could add a few of my own experiences here, formthe view of someone who doesn't know what the interiors of svg look like. I, too, would like to offer to users of our software an svg option, because it is a standard, preserves quality, and, unlike postscript, is better supported in terms of freely available editors such as inkscape. In playing with plplot svg's (I just used Example x01): The cairo svg opens fine in Inkscape, but the text doesn't render properly in firefox The -dev svg opens fine in firefox, but won't open in Inkscape. The labels are displaced when it opens in imagemagick. It is rendered pretty well by gimp (though this loses the vector nature of the plot). It fails to open in kde's konqueror, complaining that a legal svg document requires an <svg> root element. Taking this as a hint, I can edit the -dev svg to get it to open in inkscape and konqueror by deleting the leading <document> tag (and it's close at the end of the file). In inkscape, the y-labels are displaced outward from where they should be. I can conduct some more experiments if desired. Steve On Mon, 2008-09-29 at 22:39 -0700, Alan W. Irwin wrote: > In sum, the current svg device logic already produces superb-looking > results > for the vast majority of our examples, and I think those superb > results will > be generated for the logo that I have in mind as well. However, there > are a > number of minor general issues I am still working on. -- +-------------------------------------------------------------------+ Professor Steven J Schwartz Phone: +44-(0)20-7594-7660 Space and Atmospheric Physics Fax: +44-(0)20-7594-7772 The Blackett Laboratory E-mail: s.s...@im... Imperial College London Office: Huxley 6M70 London SW7 2AZ, U.K. Web: http://www.sp.ph.ic.ac.uk/~sjs +-------------------------------------------------------------------+ |
From: Alan W. I. <ir...@be...> - 2008-09-30 15:03:41
|
On 2008-09-30 10:07+0100 Steve Schwartz wrote: > Taking this as a hint, I can edit the -dev svg to get it to open in > inkscape and konqueror by deleting the leading <document> tag (and it's > close at the end of the file). Hi Steve: I fixed that bug last week when I started my svg effort. So I am very interested in your experiments, but please use the latest version of PLplot from svn trunk to access all the svg bug fixes I have been making. I know you have used svn trunk before so I suspect that you just forgot to do an svn update or else you did not rebuild starting from an empty build tree. That update/rebuild may cure most of the problems you have encountered, but I am very interested in any that persist after that update for example 1. For example, that update will not cure the ImageMagick/librsvg X offset issues I commented on already. I am virtually positive that is a librsvg bug so I plan to make a really simple case, validate it at http://validator.w3.org (to make absolutely sure it is compliant with the svg standard), and send in a bug report to librsvg with screenshots of what you get with librsvg versus other standards compliant viewers. Hopefully, that will get some action. I should mention that figure 1 looks perfect here for firefox. For konqueror everything is fine for Figure 1 except for the circles used to mark points which it replaces by question marks because its ability to find non-standard glyphs amongst the system fonts is so poor. As I mentioned, I will be sending in a konqueror bug report on that issue. You mentioned you liked svg. I like it too because it produces such good-looking results (for good viewers like firefox, konqueror, and hopefully for imagemagic/librsvg soon), and it has the capability of being scaled without getting the artifacts associated with bitmap scaling. On top of that its xml output is really straightforward to understand; that was a big help in sorting out a number of the svg issues that I mentioned, and I am going to rely on being able to humanly parse the results to help me sort out the additional minor xml tag issues I will be working on today (for some figures, but not figure 1.) I have just checked specifically that figure 1 validates so every viewer that is svg 1.1 standards compliant and which has proper access to fonts should render it the same way, i.e., like firefox. 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 __________________________ |
From: Maurice L. <mj...@br...> - 2008-10-01 04:24:51
|
Interestingly, the following article on SVG editors just appeared on linuxtoday.com today. http://www.linux.com/feature/148630 -- Maurice LeBrun |
From: Alan W. I. <ir...@be...> - 2008-10-01 05:36:19
|
On 2008-09-30 23:24-0500 Maurice LeBrun wrote: > Interestingly, the following article on SVG editors just appeared on > linuxtoday.com today. > > http://www.linux.com/feature/148630 Yeah, I just finished reading that 5 minutes before I saw your post. There was one negative point in there that I found disturbing; various Linux svg editors apparently don't talk to each other very well via svg. My additional recent experience is the librsvg-based svg viewers such as the ImageMagick "display" app misinterpret standard svg commands about x positioning of text. (Fortunately, that appears not to be a problem for konqueror and firefox.) Haven't all these svg application developers with svg i/o issues ever heard of following/supporting standards? Of course, our own situation is much simpler because we don't have the input problem where you have to support essentially the whole standard in order to understand everyone else. That simplification allows us to use programming by Hazen to output the SVG file for -dev svg using a tiny subset of the svg-1.1 standard. However, at least I have tested that -dev svg output extensively to make sure the result is compliant with the svg-1.1 validator at http://validator.w3.org. 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 __________________________ |
From: Steve S. <s.s...@im...> - 2008-10-01 08:18:57
|
Hi Alan, On Tue, 2008-09-30 at 08:03 -0700, Alan W. Irwin wrote: > I fixed that bug last week when I started my svg effort. So I am very > interested in your experiments, but please use the latest version of > PLplot > from svn trunk to access all the svg bug fixes I have been making. I > know > you have used svn trunk before so I suspect that you just forgot to do > an > svn update or else you did not rebuild starting from an empty build > tree. OK, I'll confess that I don't download svn updates on a daily basis - I tend to work on a need to know basis. I'll do so when I next get a chance and then comment on svg issues. We will at some point have an alternative svg route for plplot in that we are finishing a Qt plplot driver. The Qt widgets support output in various formats including svg. I don't know the extent to which that will preserve the nice vector properties that make svg attractive. We've delayed this a bit because the interface for Qt4 is quite different from Qt3 and we are in the process of migrating bits of our code to Qt4 along with numerous other improvements (a major one of which is moving to plplot which is nearly complete). Steve -- +-------------------------------------------------------------------+ Professor Steven J Schwartz Phone: +44-(0)20-7594-7660 Space and Atmospheric Physics Fax: +44-(0)20-7594-7772 The Blackett Laboratory E-mail: s.s...@im... Imperial College London Office: Huxley 6M70 London SW7 2AZ, U.K. Web: http://www.sp.ph.ic.ac.uk/~sjs +-------------------------------------------------------------------+ |
From: Alan W. I. <ir...@be...> - 2008-10-01 15:37:09
|
Hi Steve: On 2008-10-01 09:20+0100 Steve Schwartz wrote: > We will at some point have an alternative svg route for plplot in that > we are finishing a Qt plplot driver. The Qt widgets support output in > various formats including svg. I don't know the extent to which that > will preserve the nice vector properties that make svg attractive. We've > delayed this a bit because the interface for Qt4 is quite different from > Qt3 and we are in the process of migrating bits of our code to Qt4 along > with numerous other improvements (a major one of which is moving to > plplot which is nearly complete). My guess is that support for svg should be quite good in libQT4 since the whole KDE4 desktop (which depends on libQT4) uses svg icons. So for that reason and others I am looking forward to trying out your PLplot QT device driver when it is finished. Also, I am glad to hear the migration of QSAS From PGplot to PLplot is nearly complete. I think PLplot already have a lot to offer QSAS (such as good support for high-quality fonts), and the unique QSAS plotting needs are bound to improve PLplot as well (e.g., the consensus we recently achieved on the direction to go to improve the PLplot time handling). 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 __________________________ |
From: Hazen B. <hba...@ma...> - 2008-10-04 02:01:44
Attachments:
debian-firefox-1.5.0.2.png
OS-X-firefox-3.0.3.png
|
On Sep 30, 2008, at 1:39 AM, Alan W. Irwin wrote: > It turns out you have to be careful of the svg viewer you use for such > evaluations. For example, the imagemagick display application has x > origin > problems for svg text. "display" renders svg by using the librsvg > library. > I found the librsvg stand-alone viewer called rsvg-view also has > exactly the > same bug (as expected) so I intend to send in a bug-report about it > to kill > two birds with one stone. In general, the firefox and konqueror > browsers > handle svg text positions properly, but one issue to watch out for > with them > (see below) is how they handle exotic glyphs. > > I used firefox to evaluate all the standard example pages, and > followed up > with the svgviewer application (the standalone equivalent of > konqueror's > method of viewing SVG results) when there was any issue visible and > sometimes also with "display" for exotic font issues (see below). Unfortunately I think that we even need to specify which OS and/or which version of Firefox should be used to get good results. I've attached two quite different, at least in terms of text placement, versions of example1, one from debian w/ Firefox 1.5.02 and the other from OS-X w/ Firefox 3.0.3. Was this the x-displacement issue that you were referring to? -Hazen |
From: Alan W. I. <ir...@be...> - 2008-10-04 04:20:03
|
On 2008-10-03 21:57-0400 Hazen Babcock wrote: > Unfortunately I think that we even need to specify which OS and/or which > version of Firefox should be used to get good results. I've attached two > quite different, at least in terms of text placement, versions of example1, > one from debian w/ Firefox 1.5.02 and the other from OS-X w/ Firefox 3.0.3. > > Was this the x-displacement issue that you were referring to? Almost exactly. In fact, it is so close I am wondering if somehow Firefox 3.0.3 on OS X is also using the buggy librsvg library to render? You have obviously got good results for a very old version of firefox (from Debian oldstable?), and I do as well for the firefox version 2.0.0.14-2 on Debian testing, but I only have the above speculation about what might be going on for OS X, and an extremely recent version of firefox. I hope to get to the bottom of the issue for librsvg which will cover off at least display and rsvg-view. Do you have access to other svg viewers on OS X such as earlier firefox versions? 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 __________________________ |
From: Hazen B. <hba...@ma...> - 2008-10-04 03:32:51
|
On Sep 30, 2008, at 1:39 AM, Alan W. Irwin wrote: > (*) Example 3: the text does not rotate accurately around this > polar plot. > For example, the center of the text rotation seems offset from the > center of > the plot. The first page of Example 28 also appears to show this > problem. I > assume these issues are caused by some text offset issue that has > not been > taken care of properly in the svg device driver when doing rotational > transformations of text. This should be fixed now. > (*) Examples 9 and 21: clipping not implemented yet as illustrated > by the > first page of these examples. I got this to work, but it takes Firefox about 10x longer to render example 9. Thoughts? I'll check it in for now, but we may want to make it optional as we did for the cairo driver. -Hazen |
From: Alan W. I. <ir...@be...> - 2008-10-04 23:43:12
|
On 2008-09-29 22:39-0700 Alan W. Irwin wrote: > In general, our svg results look really good with [Debian testing] firefox, and I believe > -dev svg produces everything I need to generate a good-looking SVG PLplot > logo using PLplot itself, but there are still some outstanding issues that I > noticed when looking at the complete set of examples. I mark the ones > listed below that I am investigating further using "(AWI)". The one that is > caused by an issue in another library is marked by "(Nobody)". Finally, the > ones marked "(*)" are too difficult for me so they are up for grabs for some > eager volunteer to show off his device driver skills. :-) Well that volunteer has stepped forward for quite a few of the issues. Thanks, Hazen. I have also made some progress myself. However, there are still some issues left. I didn't check all the examples this time, but to start I did look at examples 1 and 2, and the vertical spacing still looks good after our recent changes (Revision 8853). > (*) Example 3: the text does not rotate accurately around this polar plot. > For example, the center of the text rotation seems offset from the center of > the plot. The first page of Example 28 also appears to show this problem. I > assume these issues are caused by some text offset issue that has not been > taken care of properly in the svg device driver when doing rotational > transformations of text. (*) The example 3 issue and example 28 page 1 issues are fixed thanks to Hazen's changes. However, a remaining issue (probably completed unrelated) seen for example 28 pages 2 and 3 is that subscripts are being interpreted as superscripts (!). > > (AWI) Example 6: some of the horizontal rules are missing. Strangely, the > seemingly equivalent horizontal rules in Example 7 are fine. (AWI) Not fixed yet. > > (*) Examples 9 and 21: clipping not implemented yet as illustrated by the > first page of these examples. Fixed by Hazen. > > (*) Example 10 (and presumably others) Text does not rotate at all with the > -ori option. (You have to run the installed examples to check out the > results from that option.) Again, this is some sort of > rotation/transformation issue, but it looks like at least in this case the > rotational information doesn't get to the text at all. This may well be > related to the example 3 issue above. (*) Not fixed yet. > > (*) Example 15: cross-hatching not implemented yet as illustrated by both > pages. (*) Not fixed yet. > > (AWI) Example 20: empty pages 2,5,7,and 10 have an xml screwup that is > probably related to the familying logic. The empty pages in Example 20 were caused by extra pladv(0) calls. I got rid of those extra pladv(0) calls to get rid of the empty pages associated with that example. However, generating empty pages should be a valid under PLplot so I started working on an equivalent simple example consisting of repeat pladv(0) calls. For that simple test, I solved the issue by my recent plGetFam change that restores the initial value (AT_BOP) of pls->page_status when plGetFam is called from the driver's plP_bop-* routine after the plP_init call. plP_init changes the page_status to AT_EOP which screws up the page logic for empty pages for the familied case without the restoration of the initial value of pls->page_status. > > (AWI) Example 21: first four figures (out of 6 on the second page) display > and then get blanked. The last two figures on the page display and do not > get blanked. The third page of this example (and also example 1) seem to > have a similar setup (multiple subpages per page), but no such issues. (AWI) not fixed yet. > > (AWI) Example 23: pages 12-16 have an xml screwup (at least </g> and </svg> > are missing at end of file) that is probably related to the familying logic. Fixed by my recent plGetFam change, see above. The issue here was not empty pages, but instead pages consisting entirely of text. Such pages currently do not change page_status (which is why my plGetFam empty page fix also solved this issue). However, just on general principles, I think such pages should change page_status so that issue is being discussed in the separate README.pages list thread. In sum, we have made some good svg device-driver progress as of revision 8853, but I still have two issues I still need to look at (ex. 6 missing lines, and ex. 21, page 2 where 4 of the 6 subplots disappear), and there are three others (ex. 28 subscript/superscript, ex. 10 text rotation, and ex. 15 cross-hatching) that are probably too difficult for me so I hope someone else will take them up. 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 __________________________ |
From: Steve S. <s.s...@im...> - 2008-10-05 12:15:43
|
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. 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. Regards, Steve -- +-------------------------------------------------------------------+ Professor Steven J Schwartz Phone: +44-(0)20-7594-7660 Space and Atmospheric Physics Fax: +44-(0)20-7594-7772 The Blackett Laboratory E-mail: s.s...@im... Imperial College London Office: Huxley 6M70 London SW7 2AZ, U.K. Web: http://www.sp.ph.ic.ac.uk/~sjs +-------------------------------------------------------------------+ |
From: Steve S. <s.s...@im...> - 2008-10-05 14:14:03
|
On Sun, 2008-10-05 at 13:14 +0100, Steve Schwartz wrote: > inkscape will now open the svg generated from x01c, though all the > labels and text show up displaced to the left. And the plot symbols are also shifted! Actually, the plot symbols don't show up in Firefox 2.0, and show up as "?" in konqueror. The Cairo svg driver generates svgs that are MUCH easier to manipulate in inkscape - I guess this has to do with the structure and hierarchy of the objects and drawing elements in the xml code. But the text and graph symbols are corrupted and/or missing. karbon14 likewise opens these without any text or markers. Scribus recognises that it doesn't support all the svg features in the cairo svgs and barely shows anything. Steve -- +-------------------------------------------------------------------+ Professor Steven J Schwartz Phone: +44-(0)20-7594-7660 Space and Atmospheric Physics Fax: +44-(0)20-7594-7772 The Blackett Laboratory E-mail: s.s...@im... Imperial College London Office: Huxley 6M70 London SW7 2AZ, U.K. Web: http://www.sp.ph.ic.ac.uk/~sjs +-------------------------------------------------------------------+ |
From: Alan W. I. <ir...@be...> - 2008-10-05 01:22:24
|
On 2008-10-04 16:38-0700 Alan W. Irwin wrote: > In sum, we have made some good svg device-driver progress as of revision > 8853, but I still have two issues I still need to look at (ex. 6 missing > lines[...] This was an easy one. It was caused by example 6 drawing exactly to the maximum possible X physical device coordinate, and driver scaling causing internal PLplot X coordinate overflow for just that case. (This bug was also recently introduced into gd.c and cairo.c by some scaling changes I made for those device drivers.) The solution is to scale by PIXELS_X-1 rather than PIXELS_X (which has the value 32768 which will overflow signed short integers). Now fixed for gd, cairo, svg (and also wingcc and cgm but not tested for those device drivers). The other devices that use PIXELS_X (e.g., xwin) appear to have alternative logic for solving this issue already. I am still working on one svg issue (4 out of 6 missing subpage plots for page 2 of example 21). 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2008-10-05 02:19:03
|
On 2008-10-04 18:19-0700 Alan W. Irwin wrote: > I am still working on one svg issue (4 out of 6 missing subpage plots for > page 2 of example 21). Two for the price of one! Solving the coordinate overflow issue solved this one as well. I wish they were all this easy. So I am done with the svg issues I volunteered for (as of revision 8854). The remaing three issues which I am aware of (and which are probably too tough for me) are subscripts being misinterpreted as superscripts in example 28 (pages 2 and 3), rotation of text not working for the -ori option for example 10 (and presumably all other examples), and hatching not implemented yet (see example 15). These three issues will not affect my on-going svg PLplot logo work, but it is obviously important to solve them to make -dev svg a complete and outstanding device driver. 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2008-10-05 18:23:44
|
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 __________________________ |
From: Steve S. <s.s...@im...> - 2008-10-05 21:56:23
Attachments:
x02c_svg_magick.png
|
Alan, On Sun, 2008-10-05 at 11:19 -0700, Alan W. Irwin wrote: > I suggest you try "display" on example 1 svg results, Actually, display (imagemagick v6.3) is worse - lettering shifted far to the right and plot symbols absent (see attached screenshot) My svg passes the W3C upload test. > Which PostScript devices have you tested? The choices are ps, psttf, > and pscairo. I haven't built the psttf driver (I think my system is missing something it needs). I've been using the generic ps one. The pscairo one actually works as I had expected it to. But for the software we ship I'd like to stick to a standalone generic ps driver. (and likewise for the svg one) Steve -- +-------------------------------------------------------------------+ Professor Steven J Schwartz Phone: +44-(0)20-7594-7660 Space and Atmospheric Physics Fax: +44-(0)20-7594-7772 The Blackett Laboratory E-mail: s.s...@im... Imperial College London Office: Huxley 6M70 London SW7 2AZ, U.K. Web: http://www.sp.ph.ic.ac.uk/~sjs +-------------------------------------------------------------------+ |
From: Hazen B. <hba...@ma...> - 2008-10-06 02:13:14
|
On Oct 3, 2008, at 11:28 PM, Hazen Babcock wrote: > > On Sep 30, 2008, at 1:39 AM, Alan W. Irwin wrote: >> >> (*) Examples 9 and 21: clipping not implemented yet as illustrated >> by the >> first page of these examples. > > I got this to work, but it takes Firefox about 10x longer to render > example 9. Thoughts? I'll check it in for now, but we may want to > make it optional as we did for the cairo driver. I made text clipping optional as it was really slowing things down for me, you have to turn it on with text_clipping=1. If people prefer we can have the default be on rather than off. -Hazen |
From: Hazen B. <hba...@ma...> - 2008-10-06 02:41:14
|
On Oct 4, 2008, at 10:18 PM, Alan W. Irwin wrote: > On 2008-10-04 18:19-0700 Alan W. Irwin wrote: > >> I am still working on one svg issue (4 out of 6 missing subpage >> plots for >> page 2 of example 21). > > Two for the price of one! Solving the coordinate overflow issue > solved this > one as well. I wish they were all this easy. > > So I am done with the svg issues I volunteered for (as of revision > 8854). > The remaing three issues which I am aware of (and which are > probably too > tough for me) are subscripts being misinterpreted as superscripts > in example > 28 (pages 2 and 3), rotation of text not working for the -ori > option for > example 10 (and presumably all other examples), and hatching not > implemented > yet (see example 15). These three issues will not affect my on- > going svg > PLplot logo work, but it is obviously important to solve them to > make -dev > svg a complete and outstanding device driver. (1) Subscripts were always being misinterpreted as superscripts, but that was just a sign problem and this should be fixed now. (2) The -ori option, or more correctly pls->diorot, was being ignored by the text rendering subroutine and this should also be fixed. (3) The question is, should cross-hatching be implemented? It looks to me like it has something to do with fill patterns. The relevant flag is pls->dev_fill1, grepping for this in the driver directory I get: aqt.c: pls->dev_fill1 = 1; gnome.c: pls->dev_fill1 = 1; /* Handle pattern fills */ mem.c: pls->dev_fill1 = 0; /* Handle pattern fills */ ntk.c: pls->dev_fill1 = 1; /* Dont handle pattern fills */ pbm.c: pls->dev_fill1 = 0; /* Handle pattern fills */ pdf.c: pls->dev_fill1 = 1; plmeta.c: pls->dev_fill1 = 1; /* Handle pattern fills */ svg.c: /* pls->dev_fill1 = 1; */ tek.c: * pls->dev_fill1 if can handle pattern area fill tk.c: pls->dev_fill1 = 1; /* Handle pattern fills */ Clearly there is some confusion about what exactly the flag means, or people were just copying older drivers and forgetting to update the comment :). Anyway, would a "complete and outstanding" driver handle pattern fills or not? To get cross-hatching with the svg driver all we have to do is set pls->dev_fill1 = 0 (or comment that line out). -Hazen |
From: Alan W. I. <ir...@be...> - 2008-10-06 07:16:12
|
On 2008-10-05 22:36-0400 Hazen Babcock wrote: > > On Oct 4, 2008, at 10:18 PM, Alan W. Irwin wrote: > >> These three issues will not affect my on-going svg >> PLplot logo work, but it is obviously important to solve them to make -dev >> svg a complete and outstanding device driver. > > (1) Subscripts were always being misinterpreted as superscripts, but that was > just a sign problem and this should be fixed now. > > (2) The -ori option, or more correctly pls->diorot, was being ignored by the > text rendering subroutine and this should also be fixed. > > (3) The question is, should cross-hatching be implemented? It looks to me > like it has something to do with fill patterns. The relevant flag is > pls->dev_fill1. Thanks, Hazen, for drawing my attention to pls->dev_fill1 (which I believe is properly documented in include/plstrm.h). I also read through the core code to confirm that documentation. The question for both fill0 and fill1 is does the driver have the unique native ability to do solid/pattern fills or do you fall back to the PLplot core software to emulate those? The core emulation of solid fills looks pretty bad so it is fortunate that most drivers have that native ability, but the core emulation of pattern fills looks good so it is no problem that most drivers do not have this special capability. I have set pls->dev_fill1 = 0 as a result of these considerations, and as expected, the cross-hatched result automatically generated by the PLplot core looks fine for example 15 now. So your two changes above, this last pls->dev_fill1 change, and also my change to default text clipping means we have an svg device driver now that produces results for all our standard examples that renders with extremely high quality for the right svg viewer (firefox in my case). Also, spot checks of the results indicate they validate at http://validator.w3.org which is an important consideration when reporting issues for our svg results with other software. Many thanks for having the vision and and energy to put this extremely useful device driver together in the first place. Thanks also for doing such a great job of fixing the subset of bugs revealed by the standard examples that I could not handle myself. AFAIK, there is one obscure issue that I noticed by chance that is still left to fix. If you change example 10 to double the character size "plschr(0., 2.)" then the ends of the string are clipped correctly at the borders of the inner box as expected. However, if you rotate coordinates with the -ori option, the text clipping box does not rotate and clips the rotated enlarged string in the wrong place. (You can also [barely] see the effects of this bug if you do not bother with doubling the text size which is the environment where I spotted it in the first place. But doubling the text size makes the bug completely obvious.) I fiddled with the order of the clipping commands relative to the rotation commands within the resulting svg file, but that seemed to remove all text so I must have been doing something that was not quite correct. If you know a quick fix for this one, that would be great just to get this last known -dev svg issue out of our hair, but I would assign this bug a low priority and put off the fix if you estimate it is going to take a substantial amount of your time to fix. 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2008-10-06 06:30:36
|
On 2008-10-05 22:09-0400 Hazen Babcock wrote: > > On Oct 3, 2008, at 11:28 PM, Hazen Babcock wrote: > >> >> On Sep 30, 2008, at 1:39 AM, Alan W. Irwin wrote: >>> >>> (*) Examples 9 and 21: clipping not implemented yet as illustrated >>> by the >>> first page of these examples. >> >> I got this to work, but it takes Firefox about 10x longer to render >> example 9. Thoughts? I'll check it in for now, but we may want to >> make it optional as we did for the cairo driver. > > I made text clipping optional as it was really slowing things down > for me, you have to turn it on with text_clipping=1. If people prefer > we can have the default be on rather than off. I prefer having the best result as default so I have made the change (revision 8859). Interestingly, at least for my firefox version (iceweasel-2.0.0.14-2 from Debian testing) and also "display" I don't notice any slowdown so efficient SVG clipping must be implemented in both cases. So it appears in this case and also many others we are up against svg viewer software with quite a large range of quality. Hopefully, the situation will rapidly improve as more and more free software graphical applications like ours develop svg generation capabilities, and the developers of such projects start filing bug reports for all other svg-capable free software which has issues dealing properly with our generated results. 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 __________________________ |
From: Arjen M. <arj...@wl...> - 2008-10-06 06:35:33
|
Steve Schwartz wrote: > >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. > > Hi Steve, I have never had much problems with the PostScript output (using the ps device driver), but I use the PostScript filter on our system printers directly. I have had issues with margins, but that is a general problem with printers. Regards, Arjen |
From: Steve S. <s.s...@im...> - 2008-10-06 10:34:14
|
Hi Arjen, My observation is that one ought to be able to send the postscript file directly to a postscript printer (I've tried both HP and Xerox printers). Passing it through a filter (eps2eps, or whatever - most/all of which amount to passing it through ghostscript) risks degrading it through a rendering engine that might, for example, substitute fonts, or draw them rather than embed them. Ultimately it leads to a bit of frustration if used by the innocent user, or sent to someone else who tries to print it and only ends up with the top left portion (despite it looking fine within ghostview) and who might not know other tricks to play. I guess the issue is somewhere in the way the scaling is handled; other drivers (e.g., the pscairo one) and other (e)psf's don't show this problem, so it must be solvable. I originally wondered if it had something to do with the fact that it was an epsf (figure) rather than a ps (page), but again other epsf's print fine natively to a ps printer. Unfortunately, although I speak a couple of languages in addition to English (including C and a bit of French), postscript isn't one of them. Regards, Steve On Mon, 2008-10-06 at 08:32 +0200, Arjen Markus wrote: > Steve Schwartz wrote: > > > > >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. > > > > > Hi Steve, > > I have never had much problems with the PostScript output (using the ps > device driver), > but I use the PostScript filter on our system printers directly. I have > had issues with > margins, but that is a general problem with printers. > > Regards, > > Arjen > -- +-------------------------------------------------------------------+ Professor Steven J Schwartz Phone: +44-(0)20-7594-7660 Space and Atmospheric Physics Fax: +44-(0)20-7594-7772 The Blackett Laboratory E-mail: s.s...@im... Imperial College London Office: Huxley 6M70 London SW7 2AZ, U.K. Web: http://www.sp.ph.ic.ac.uk/~sjs +-------------------------------------------------------------------+ |
From: Arjen M. <arj...@wl...> - 2008-10-06 11:03:33
|
Steve Schwartz wrote: >Hi Arjen, > >My observation is that one ought to be able to send the postscript file >directly to a postscript printer (I've tried both HP and Xerox >printers). Passing it through a filter (eps2eps, or whatever - most/all >of which amount to passing it through ghostscript) risks degrading it >through a rendering engine that might, for example, substitute fonts, or >draw them rather than embed them. Ultimately it leads to a bit of >frustration if used by the innocent user, or sent to someone else who >tries to print it and only ends up with the top left portion (despite it >looking fine within ghostview) and who might not know other tricks to >play. > >I guess the issue is somewhere in the way the scaling is handled; other >drivers (e.g., the pscairo one) and other (e)psf's don't show this >problem, so it must be solvable. I originally wondered if it had >something to do with the fact that it was an epsf (figure) rather than a >ps (page), but again other epsf's print fine natively to a ps printer. > >Unfortunately, although I speak a couple of languages in addition to >English (including C and a bit of French), postscript isn't one of them. > > > Hi Steve, I have expressed myself somewhat inaccurately: the command by which I send the PostScript files to the printer is simply "lp". The printer driver that then gets invoked will do all manner of things to get the file printed, but I do not know what steps are involved - nothing that I need to worry about. Now, I do remember that we had difficulties getting the colours completely correct, but that was an issue under Windows, not under Linux (and something quite apart from PLplot, actually: printers use a colour translation table to get the "best" fit of a colour specified in PS on paper). Regards, Arjen (who speaks a bunch of languages, also including French, but excluding PostScript) |
From: Steve S. <s.s...@im...> - 2008-10-06 12:14:53
Attachments:
x01c_ps.eps
|
Hi Arjen, On Mon, 2008-10-06 at 12:51 +0200, Arjen Markus wrote: > I have expressed myself somewhat inaccurately: the command by which I > send > the PostScript files to the printer is simply "lp". The printer > driver > that then gets > invoked will do all manner of things to get the file printed, but I > do > not know > what steps are involved - nothing that I need to worry about. Yes, that's what I've tried, to an HP laserjet 2100 and a xerox workcenter. I use CUPS and the printer uses the recommended driver (the HP2100 postscript driver). I've also tried with a generic ps driver - same results. And I've tried it on another linux box (running Debian instead of my OpenSuse). All with the same result. It does print ok from gview on a windows pc (using both the GDI printer specification and postscript). I attach the file (from x01) in case you want to try for yourself. Regards, Steve -- +-------------------------------------------------------------------+ Professor Steven J Schwartz Phone: +44-(0)20-7594-7660 Space and Atmospheric Physics Fax: +44-(0)20-7594-7772 The Blackett Laboratory E-mail: s.s...@im... Imperial College London Office: Huxley 6M70 London SW7 2AZ, U.K. Web: http://www.sp.ph.ic.ac.uk/~sjs +-------------------------------------------------------------------+ |