On 03/20/2015 03:58 PM, Alan W. Irwin wrote: > 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).
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. 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 a Windows text layout engine available? 5) Is a OS-X text layout engine available? 6) Is Freetype available? 7) 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. -Hazen ------------------------------------------------------------------------------ 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
