From: Joseph W. <joe...@gm...> - 2013-02-14 08:19:47
|
FYI, I just submitted a patch to the SVG driver on the sourceforge project page. The patch moves some of the transforms into the text element itself and it cuts down the size of the SVG by 50% in some of my test cases. What happens is that the SVG driver uses text to plots out hershey fonts, so you have data heavy plots in which each point is a massive bit of XML. I think that some other improvements may be possible. There are a lot of text attributes that look like they might be shared, but I don't know enough SVG to know how to go about doing that. |
From: Alan W. I. <ir...@be...> - 2013-02-14 20:06:13
|
On 2013-02-14 16:19+0800 Joseph Wang wrote: > FYI, > > I just submitted a patch to the SVG driver on the sourceforge project > page. The patch > moves some of the transforms into the text element itself and it cuts > down the size > of the SVG by 50% in some of my test cases. What happens is that the SVG driver > uses text to plots out hershey fonts, so you have data heavy plots in > which each point > is a massive bit of XML. Hi Joseph: Thanks for your patch, but before looking at it in any detail I would appreciate some clarification of the explanation you made above about the reduction in size of the resulting SVG. I haven't looked at the svg code in a while, but I am virtually positive it does not use Hershey fonts. For example, I just took a quick look at some -dev svg results, and it appears that by default it is using generic fonts, i.e., sans-serif, serif, etc., rather that specific font choices. So specific font choice becomes (by design) the responsibility of the svg viewer, and has nothing to do with PLplot and especially our old-fashioned Hershey fonts. If it turns out I am wrong, and there are cases where it is possible for -dev svg to use Hershey fonts, I think that is a bug that should be fixed. If I am right, then there must be some other explanation of why you have been able to achieve reductions in svg result sizes by a factor of two in some cases with your patch. That's obviously an outstanding result that I think we should incorporate, but it would be good to get a clear explanation as to why your patch reduces result size so much. 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); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); 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: Joseph W. <joe...@gm...> - 2013-02-15 08:30:57
|
The SVG driver does not use hershey fonts directly and correctly uses the plplot infrastructure to convert hershey symbols to unicode. Unfortunately, the SVG driver code turns out to be extremely verbose at generating unicode text. At the bottom, I've included a "before" and "after" for the SVG that gets generated if you request a graph with sample points that use hershey symbols. The request that goes to plplot is to draw a point using a hershey symbol for point at x, y. As you can see the driver correctly converts the request into unicode. Unfortunately each point contains independent transform and clipping information. If you imagine a plot with say 10000 points, the SVG files that get generated are huge (i.e. several megabytes). BEFORE PATCH <clipPath id="text-clipping0" > <polygon points="0.000000,0.000000 0.000000,3240.000000 2700.000000,3240.000000 \ 2700.000000,0.000000" /> </clipPath> <g clip-path="url(#text-clipping0)" > <g transform="matrix(1.000000 0.000000 0.000000 -1.000000 540.000000 1985.\ 449219)" > <g transform="matrix(1.0 0.0 0.0 1.0 0.0 7.865117)" > <text dominant-baseline="no-change" fill="#000000" fill-opacity="1.000000" xml:space="preserve" font-size="20" text-anchor="middle" x="0.000000" y="0" ><tspan font-family="sans-serif" font-style="normal" font-weight="normal">-\ ;-66</tspan></text> </g> </g> </g> AFTER PATCH <g clip-path="url(#text-clipping0)" > <text dominant-baseline="no-change" fill="#000000" fill-opacity="1.000000" xml:space="preserve" font-size="20" transform="matrix(1.000000 0.000000 0.000000 -1.000000 540.000000 1985.\ 449219)" text-anchor="middle" x="0.000000" y="7.865117" ><tspan font-family="sans-serif" font-style="normal" font-weight="normal">-\ ;-66</tspan></text> </g> On Fri, Feb 15, 2013 at 4:06 AM, Alan W. Irwin <ir...@be...> wrote: > On 2013-02-14 16:19+0800 Joseph Wang wrote: > >> FYI, >> >> I just submitted a patch to the SVG driver on the sourceforge project >> page. The patch >> moves some of the transforms into the text element itself and it cuts >> down the size >> of the SVG by 50% in some of my test cases. What happens is that the SVG >> driver >> uses text to plots out hershey fonts, so you have data heavy plots in >> which each point >> is a massive bit of XML. > > > Hi Joseph: > > Thanks for your patch, but before looking at it in any detail I would > appreciate some clarification of the explanation you made above > about the reduction in size of the resulting SVG. > > I haven't looked at the svg code in a while, but I am virtually > positive it does not use Hershey fonts. For example, I just took a > quick look at some -dev svg results, and it appears that by default it > is using generic fonts, i.e., sans-serif, serif, etc., rather that > specific font choices. So specific font choice becomes (by design) > the responsibility of the svg viewer, and has nothing to do with > PLplot and especially our old-fashioned Hershey fonts. > > If it turns out I am wrong, and there are cases where it is possible > for -dev svg to use Hershey fonts, I think that is a bug that should > be fixed. > > If I am right, then there must be some other explanation of why you > have been able to achieve reductions in svg result sizes by a factor > of two in some cases with your patch. That's obviously an outstanding > result that I think we should incorporate, but it would be good to > get a clear explanation as to why your patch reduces result size so > much. > > 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); the Time > Ephemerides project (timeephem.sf.net); PLplot scientific plotting > software package (plplot.sf.net); 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...> - 2013-02-16 18:59:38
|
Hi Joseph: I applied your patch, used our styling script to automatically bring the resulting svg.c file into conformance with our preferred C style, and tested that result using the test_c_svg target. There were no obvious build or run-time errors, and visual comparison of old and new results showed no rendering differences with the new results always the same size or smaller. Therefore, I committed (revision 12292) the revised svg.c file to svn trunk which will be the basis of our next release of PLplot. Thanks for your help with PLplot! Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); 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 __________________________ |