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

Reply via email to