On 2013-10-04 22:56+0100 Andrew Ross wrote:

>
> (Moved to plplot-devel since it is more appropriate).
>
> Post release I've finally got back to looking at this. Closer examination of
> the code shows that handling over the overline / underline (and also backchar)
> escape sequences is a bit of a mess.
>
> Drivers such as xwin which let plplot deal with text plotting work fine, but
> all others which have their own text handling routines seem to have problems.
> Superscript / subscipt has been handled correctly in each case, since the
> examples use these so failings are immediately obvious. The other escape codes
> are not tested.

Hi Andrew:

I am glad you are working on these overline/underline issues. However,
please try the following patch to see the full extent of the
problem we are up against.

Index: examples/c/x26c.c
===================================================================
--- examples/c/x26c.c   (revision 12577)
+++ examples/c/x26c.c   (working copy)
@@ -89,8 +89,10 @@
  };

  static const char *title_labels[] = {
-    "Single Pole Low-Pass Filter",
-    "Однополюсный Низко-Частотный Фильтр",
+  //    "Single Pole Low-Pass Filter",
+  //    "Однополюсный Низко-Частотный Фильтр",
+  "#-aqp#dsubscript#u#-#+bd#usuperscript#d#+",
+  "#-Однополюсный Низко-Частотный 
Фильтрaqp#dsubscript#u#-#+bd#usuperscript#d#+",
      NULL
  };

BTW, to expand on what you said, I feel a mixture of underlining,
overlining, descenders, subscripts, superscripts, and UTF-8 should be
in one of our examples.  However, I hasten to add I don't think it
should be example 25 so the above change should only be done
temporarily to illustrate the points made below. Also, you might want
to add something similar to my suite of short rendering tests in
examples/python.

But sticking with this modified example for the time being, the xwin
and qtwidget -drvopt text_vectorize=1 devices show the underlining
going right through the q and p descenders, a change in vertical
position for an underlined subscript, and similarly for an overlined
superscript. Furthermore, for the xwin device the horizontal extent of
the string is badly calculated whenever the string includes UTF-8
characters as in the second modified page of the example.

BTW, I have no idea why text_vectorize=1 is needed, but I agree it is
necessary to obtain close to reasonable qtwidget results for this
case.

The xcairo device gives really bad results for this modified example.
Both subscripting and overlining seem to be ignored.  Those bugs have
to be fixed before we can see the full extent of problems for the
above example.  But already without those fixes I can see the
underline cutting right through the descenders.

As I recall, we obtain the horizontal extent of a string right now
using cairo and Qt4 library functions, and that works well for both
ascii and UTF-8 strings.  So I suspect we need to do similar library
function calls to obtain the vertical extent (including descenders,
subscripts, and superscripts) and therefore the bounding box of the
string.  Once we have the bounding box of the complete string, then
underlining and overlining is trivial.

For devices that use Hershey fonts for ascii strings we already have a
reliable calculation of the horizontal extent, and I think adding the
vertical extent (including descenders, subscripts and superscripts) to
complete the bounding-box calculation should be straightforward.

The combination of Hershey fonts and UTF-8 strings produce length
calculations that are a mess right now.  IIRC, UTF-8 characters are simply
rendered as blanks for Hershey fonts so what is needed is a simple
routine to calculate the number of UTF-8 characters in the string and
then do the bounding box calculation for that number of Hershey blanks.

In sum, I think that devices that are capable of it should be able to
provide the bounding-box calculation for strings (very similar to how
the length of a string is calculated now with libraries providing the
results if possible, and otherwise a calculation is done by the PLplot
core as a last resort).  Furthermore, the actual
overlining/underlining should be done via plline calls from the PLplot
core based on the results of that bounding-box calculation.

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
__________________________

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
_______________________________________________
Plplot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Reply via email to