On 2009-11-14 21:22-0500 Hazen Babcock wrote: > This should be fixed in v10591. The problem was with the two different text > rendering paths. The second text rendering path seemed like a good idea at > the time, but now I'm sort of leaning towards reverting it. It doesn't really > make driver text handling that much easier or cleaner to program and as long > as we have two paths we are probably going to keep running into trouble like > this.
Thanks, Hazen. I verify that example 1 -save now produces a PostScript (-dev psc) file with text with -dev xcairo. However, there is one obvious issue in that generated PostScript text that remains; the numbers that should be exponents are not superscripted at all. Also, I didn't understand your explanation of the issue you found so would you be willing to expand it? I assume you are not referring to the Hershey text rendering path (used by -dev xwin and some other device drivers at special option). And you are probably not referring to the "ancient" plfreetype unicode text rendering path used by the gd device driver and still a few others. That leaves the "modern" unicode text rendering path used by the cairo, qt, ps, psttf, and other devices that does not use plfreetype. If I recall correctly you may have added at least one centralized helper function for the modern unicode case which some devices (cairo?) use and others do not (yet). Is that what you are referring to by the two different text rendering paths? If so, and you would like to get rid of one of them, then it would be great to use more centralized unicode text processing for all modern unicode devices instead of the present situation with much duplicated code in the device drivers for processing unicode text. But that should still leave intact the Hershey text rendering and the old plfreetype-based unicode text rendering. 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 __________________________ ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
