On 2015-03-20 14:31-0400 Jim Dishaw wrote: > > On Mar 20, 2015, at 2:09 PM, "Alan W. Irwin" <ir...@beluga.phys.uvic.ca> > wrote: > >> On 2015-03-20 08:46-0400 Hazen Babcock wrote: >> >>> 5. Use a library (Freetype?) for rendering text instead of delegating >>> this to the driver? The driver would instead be responsible for the >>> display of the resulting bitmaps. This would finally solve the problem >>> of the text looking slightly different on all the drivers. It would also >>> make writing new drivers easier as text handling is far and away the >>> most difficult thing to implement correctly. Maybe this would not work >>> so well with pdf and postscript drivers, so we'd need to preserve the >>> driver rendered text option? >> >> This text rendering approach is too simplified and not what we want at >> all. Here is why. >
> Having recently dug into the text handling, I think some modest changes would be useful. First, I would cleanup the interface between the core and the drivers for freetype and pango. Second, some code refactoring in plcore.c to cleanup the text handling (in particular the unicode processing has duplicative code). To give you some history there, Hazen implemented that pls->alt_unicode = 1 alternative for unicode text processing and made that the default for the cairo device as a proof of concept that that alternative approach worked. But developers/maintainers of other unicode aware devices did not change to his alternate method so he wanted to tear out that capability again in the interest of simplicity (like you have asked for as well). However, I convinced him otherwise because I thought the lack of change for the other devices was not a reflection on the quality of his work/idea for less unicode text processing code in drivers but simply due to inertia. But at this point that inertia continues. So my opinion is we should take the time to truly evaluate which approach is best, and if that turns out to be Hazen's alternative approach, then start converting all the non-cairo unicode devices to that approach with the goal of simplifying their text handling. But if it turns out to be the original approach, then we indeed should tear out that alternative approach and convert cairo back to the original approach (which is easy to do, but not the right thing to do if the alternative approach is truly the best one). @Jim: You have a valuable fresh perspective on this so if you had to choose one alternative would you prefer the original approach or the alt approach? If we completely dropped the alt approach then that would allow us to remove all the pls->alt_unicode = 1 logic from the core (most notably, the whole alternate_unicode_processing function in plcore.c), and the cairo.c text_begin_cairo, text_char_cairo, text_esc_cairo, and text_end_cairo functions which are currently called when the escape code is PLESC_BEGIN_TEXT, PLESC_TEXT_CHAR, PLESC_CONTROL_CHAR, or PLESC_END_TEXT. On the other hand, if we completely dropped the original approach, that would allow us to remove the (large) proc_str function from cairo.c and the equivalents for the other unicode aware devices but at the (one-time) expense of implementing the equivalent of text_begin_cairo, text_char_cairo, text_esc_cairo, and text_end_cairo for all non-cairo unicode-aware devices. In sum, the technical choice is between the alt approach which requires already implemented code in the core with simpler code in the unicode-aware drivers and the original approach which allows us to drop core code at the expense of more duplicated and more complex text processing code in the unicode-aware drivers. And you can use cairo.c as a prototype to estimate the driver code savings/simplifications that would appear for the non-cairo devices in the alt case. 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 __________________________ ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
