Darren Dale wrote: > On Thursday 12 July 2007 05:11:31 pm Carl Worth wrote: >> On 2007年7月12日 10:31:19 -1000, Eric Firing wrote: >>> if only cairo would make eps files >> Isn't EPS a trivially change compared to PS? Something like a modified >> header and the addition of bounding-box information? > > The following is listed in the Encapsulated Postscript File Format > Specification, > http://partners.adobe.com/public/developer/en/ps/5002.EPSF_Spec.pdf: > > "There are some PostScript language operators plus statusdict and userdict > operators that are intended for system-level jobs or page descriptions that > are not appropriate in an EPS file. In addition to all operators in statusdict > and the operators in userdict for establishing an imageable area, the > following operators must not be used in an EPS file: > banddevice exitserver initmatrix setshared > clear framedevice quit startjob > cleardictstack grestoreall renderbands > copypage initclip setglobal > erasepage initgraphics setpagedevice Aha! Cairo ps output is full of "initclip" commands, so it can't be converted to eps without substantial reworking. This is a big limitation. To put a figure in a LaTeX document, for example, eps usually is what you need. So until Cairo solves this problem and provides eps, it is locked out of a large domain of graphics use. Eric
On 2007年7月12日 10:31:19 -1000, Eric Firing wrote: > if only cairo would make eps files Isn't EPS a trivially change compared to PS? Something like a modified header and the addition of bounding-box information? It sounds like something that should be really easy to change in cairo. Maybe you could take a cairo-generated .ps file and manually munge it into the .eps that you'd like? If you did that, I'd be glad to write the necessary cairo code to get the same result, (and come up with whatever tiny new API is necessary to instruct cairo to do that). As for the rest of what you say. From my point of view, yes, using cairo and its multi-backend capabilities seems to make a fair amount more sense than inventing a new system with multiple backends. (Not a criticism against the original MPL stuff---cairo 1.0 has only existed since August 2005). But yeah, I also understand that there are licensing concerns. Anything else? Are there cairo performance concerns? If so, I'd love to hear about them so we can fix them. And even if you don't use cairo directly, I will offer the suggestion of its drawing model as being very good, (using source and mask pattern objects and just 5 different drawing operations: stroke, fill, paint, show_text/glyphs, and mask). Whatever you decide to go with, have fun! -Carl
On Thursday 12 July 2007 05:11:31 pm Carl Worth wrote: > On 2007年7月12日 10:31:19 -1000, Eric Firing wrote: > > if only cairo would make eps files > > Isn't EPS a trivially change compared to PS? Something like a modified > header and the addition of bounding-box information? The following is listed in the Encapsulated Postscript File Format=20 Specification, =20 http://partners.adobe.com/public/developer/en/ps/5002.EPSF_Spec.pdf: "There are some PostScript language operators plus statusdict and userdict= =20 operators that are intended for system-level jobs or page descriptions that= =20 are not appropriate in an EPS =EF=AC=81le. In addition to all operators in = statusdict=20 and the operators in userdict for establishing an imageable area, the=20 following operators must not be used in an EPS =EF=AC=81le: banddevice exitserver initmatrix setshared clear framedevice quit startjob cleardictstack grestoreall renderbands copypage initclip setglobal erasepage initgraphics setpagedevice If used properly, the following operators are allowed in an EPS =EF=AC=81le= =2E However,=20 use of any of these must comply with the rules in Appendix I of the=20 PostScript Language Reference Manual, Second Edition. Improper use can caus= e=20 unpredictable results. nulldevice sethalftone setscreen unde=EF=AC=81nef= ont setgstate setmatrix settransfer "
Carl Worth wrote: [...] > But yeah, I also understand that there are licensing concerns. > Anything else? Are there cairo performance concerns? If so, I'd love > to hear about them so we can fix them. Backend cairo.ps took 0.87 minutes to complete Backend ps took 0.66 minutes to complete So the mpl Cairo ps output is also relatively slow. I don't know whether this is inherent in Cairo, or whether it could be optimized away in the mpl Cairo backend. And, it may be caused by a few outliers among the examples; I have not tried to compare times for individual plots. Eric
On Thursday 12 July 2007 5:57:27 pm Eric Firing wrote: > Carl Worth wrote: > [...] > > > But yeah, I also understand that there are licensing concerns. > > Anything else? Are there cairo performance concerns? If so, I'd love > > to hear about them so we can fix them. > > Backend cairo.ps took 0.87 minutes to complete > Backend ps took 0.66 minutes to complete > > So the mpl Cairo ps output is also relatively slow. I don't know > whether this is inherent in Cairo, or whether it could be optimized away > in the mpl Cairo backend. And, it may be caused by a few outliers > among the examples; I have not tried to compare times for individual plots. Probably mpl's cairo backend can be optimized. The PS backend is heavily optimized, making use of the newer API to draw lines and markers (RendererPS.draw_lines and draw_markers).