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). I think it is important to keep a text rendering capability within the core library (e.g. plhrsh2()). The other concept that I support (and I forgot who mentioned it) is a mid-tier representation of the graphical elements. This mid-tier would be very useful for the plot metafile as well as the OpenGL driver that is being discussed in a different thread. For example, 3D shapes would be represented as a 3D shape rather than a projection in 2D. I believe that this mid-tier representation would cleanup the interface to the drivers. ------------------------------------------------------------------------------ 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
