Alan W. Irwin wrote: > 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.
It looks to me like all of the formatting is somehow removed. I'm still puzzling over how that happens as I don't think the new pathway touches the string created for the old pathway, though I guess it must somehow. > 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. Yes, this is what I was referring to. Does anyone else have an opinion on which path we should keep going forward? On the one hand we have the ubiquitous while loop. On the other we have four different functions, one called at the start of text, one called for new characters, one called for new esc characters and one called at the end of the text. The cairo driver currently has both approaches implemented if anyone is curious to compare the two. Functions called for approach 1: proc_str ucs4_to_pango_markup_format Functions called for approach 2: text_begin_cairo text_char_cairo text_esc_cairo text_end_cairo -Hazen ------------------------------------------------------------------------------ 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
