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

Reply via email to