On 2015-03-20 16:38-0400 Hazen Babcock wrote: > Personally I don't like either unicode pathway as they both lead to heavy > code duplication in the drivers, fiddly driver specific text rendering issues > that are not always that easy to sort out and the sprawl of text rendering > across multiple files.
Some of these are good points, but I would have to disagree with the code duplication part of the above comment for the alt_unicode case. For example, I see almost nothing but extremely specific pango/cairo calls in the alt_unicode processing code in cairo.c. Of course, somone implementing that alt_unicode method for a different unicode device would definitely want to follow in broad outline what is done in cairo.c. In fact, however, there would be little actual code in the cairo alt_unicode case that could be directly duplicated for any device depending on a different library to render unicode text. > > I had forgotten about all the layout issues, etc.., so I agree that Freetype > as the default is a non-starter, so how about this alternative? Unless > specifically requested by a driver, text rendering moves to PLplot core. The > rendering would be handled by looking for the best available text rendering > option, and then falling back through a series of options to the baseline of > the hershey fonts. The options might be something like this: > > 1) Is Pango/Cairo available? Use Pango/Cairo to render all the text. > 2) Is Qt available? Use Qt to render all the text. > 3) Is WxWidgets available? (Though maybe WxWidgets would not work in this > way?) 4) is LibLasi available? 5) is X available? 6) is Tk available? 7) Is a Windows text layout engine available? 8) Is a OS-X text layout engine available? 9) Is Freetype AND fontconfig available? (not implemented yet) 10) Is Freetype available? (I would strongly deprecate or else remove this one once 9 is implemented) 11) Hershey rendering. > I feel that this would make adding a new drivers a lot simpler and it would > also concentrate all of the text rendering logic in a single place. As a > bonus, you would now have nice looking unicode fonts for all of the drivers, > even ones that don't natively support unicode. One problem might be that not > all the drivers support rendering bitmaps. I definitely see the appeal of having one PLplot text engine that does all the text processing, but I also have a number of concerns with that approach. A. The menu items 1 through 8 above have a one-to-one correspondence with particular device drivers, i.e., cairo, qt, wxwidgets, psttf, xwin, tk, wingcc, and aqt. So those are all choices imposed for one device driver and not really a menu item that can be used arbitrarily for any device driver. Furthermore, some of our device drivers (e.g., ps, psttf, pdf, and svg) write to a well-defined file standard where that standard imposes its own rock-hard constraints on text processing. Note that the OpenGL standard very likely also has rock-hard constraints on unicode text processing so the implementers of such a new device would first have to consider how does OpenGL handle unicode text, and then I would recommend that they implement the alt-unicode method following what is done in cairo.c (i.e., _without_ implementing the equivalent of cairo's currently unused proc_str). That said, there are indeed some real menu choices in the above list. For example, the xwin, tk, and ntk devices currently use 11, but once 9 is implemented it should be possible to generalize them to use either 9 or 11 depending on what is available on the platform. (I frankly don't think 10 is worth bothering with for them for the reasons I discussed.) And for the wingcc device there is currently the choice of 10 or 11, but I would like to see that expand to use the Windows text engine unicode rendering if available, but otherwise use 9 (when implemented), 10 (only until 9 is implemented), and 11 depending on external library availability. And of course in this situation 9, 10, and 11 should be implemented in the core as much as possible. I will let you speak to what is possible for -dev aqt. B. This proposed central text processing unit would have to have the joint library dependencies of every single one of our devices (i.e., everything mentioned above simultaneously), and I much prefer the current approach where the appropriate external library dependencies are only associated with the device code and the device-dependent binding (if such exists), but not the central code. C. Instead of centralizing all text processing to remove code duplication, why not instead reduce that duplication by providing core utility functionality which each device driver can use? In fact, that is why the alt_unicode approach appeals to me so that is why I proposed it above as the correct prototype for the implementers of the OpenGL device driver to use for their own unicode text processing. 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
